From nobody Fri Apr 1 18:13: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 8850312D51B for ; Fri, 1 Apr 2016 18:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=4c7qY8CQ; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=Uzp3yro0 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 WErZaE0EIrcK for ; Fri, 1 Apr 2016 18:13:50 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DBB312D50F for ; Fri, 1 Apr 2016 18:13:50 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id DA1DB20792 for ; Fri, 1 Apr 2016 21:13:49 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 01 Apr 2016 21:13:49 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=xhJ7M /7IL6dIlWNkTPbBjmx7Nis=; b=4c7qY8CQJE2g8xl1IJIlGk0tn83IPQ1ZREHIe Gg7etvNLg4PL5lkHRIz0lRQLlxn0PkOjqhAq6wVI0fOC6csDu+ORdLeuWN5gGkxE nm69556sKq2M7zgj7rPJfVzlg1tBYdPGN3ikgA+c2GRQ5Oz+/c0neIa+xaTFP0+o xycK3M= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=xhJ7M/7IL6dIlWNkTPbBjmx7Nis=; b=Uzp3y ro0DBQVyLz5jLGZFoGOS/KGFod4ee2Og0K5U54TJ++sESozNL4yNmxw4oft8PeBw SeFfek8IBYPt5c4K8dVWuZD2gwfnnhWjl/Q1VYUsBqHhEkX9OjSlNiC3qMmguO/0 PuQGSuX2/qQhM3lTKVDqm66RQVpiesj/fFlTvE= X-Sasl-enc: iLgXwLoVerhU8SVKXCGY9EdYjk7GlYpF3xm7Wrlj1J98 1459559629 Received: from [192.168.11.140] (ip-64-134-25-43.public.wayport.net [64.134.25.43]) by mail.messagingengine.com (Postfix) with ESMTPA id 54E19C00016; Fri, 1 Apr 2016 21:13:49 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9D75D0A5-63F8-4B1F-B2A8-BB0C3975BF7C" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: Date: Fri, 1 Apr 2016 20:13:48 -0500 Message-Id: References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: Ted Hardie X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.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, 02 Apr 2016 01:13:55 -0000 --Apple-Mail=_9D75D0A5-63F8-4B1F-B2A8-BB0C3975BF7C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 22, 2016, at 6:10 PM, Ted Hardie wrote: >=20 > Speaking as an individual, rather than chair: >=20 > On Tue, Mar 22, 2016 at 3:31 AM, Drage, Keith (Nokia - GB) = > wrote: > The header of this document says "standards track". >=20 > The title of the document says "recommendations" which would equate to = a normative document of SHOULD strength >=20 > The abstract says "best practices" >=20 > Throughout the document I detected lots of lower case usage of RFC = 2119 terms but did not see any upper case usage (but may have missed = it). >=20 > All of which leaves me confused. >=20 > Would the chairs like to clarify the intent of this document in terms = of document type? >=20 > Regards >=20 > Keith Drage >=20 >=20 > I don't think this document describes any new protocol mechanisms, so = the lack of upper case RFC 2119 terms seems to me personally fairly = natural. What it does instead is lay out the results of doing IP = address handling in specific modes, along with a recommendation on which = would make a reasonable default.=20 >=20 > Clearly it could have been part of JSEP, which would have made it part = of a standards track doc. The value to me of it being separate is that = the advice can be revised independently of the core protocol = specification. To that extent, it is somewhere between "Applicability = statement" and "BCP" in our formal terminology, with a thumb very = slightly on the scale toward BCP. Ultimately, though, I am willing to be = guided by our ADs or the community about the exact status.=20 I could see an argument for either standards track or BCP and don=E2=80=99= t have a strong feeling either way. In either case some adjustments = would be necessary to make clear the normativity or non-normativity of = the guidance. Alissa > The high order bits are the advice and its decomposability. >=20 > regards, >=20 > Ted=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_9D75D0A5-63F8-4B1F-B2A8-BB0C3975BF7C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Mar 22, 2016, at 6:10 PM, Ted Hardie <ted.ietf@gmail.com> = wrote:

Speaking as an individual, rather than chair:

On Tue, Mar 22, 2016 at 3:31 AM, Drage, Keith = (Nokia - GB) <keith.drage@nokia.com> wrote:
The = header of this document says "standards track".

The title of the document says "recommendations" which would equate to a = normative document of SHOULD strength

The abstract says "best practices"

Throughout the document I detected lots of lower case usage of RFC 2119 = terms but did not see any upper case usage (but may have missed it).

All of which leaves me confused.

Would the chairs like to clarify the intent of this document in terms of = document type?

Regards

Keith Drage


I don't think this document describes any new = protocol mechanisms, so the lack of upper case RFC 2119 terms seems to = me personally fairly natural.  What it does instead is lay out the = results of doing IP address handling in specific modes, along with a = recommendation on which would make a reasonable default.

Clearly it could have been part of JSEP, which = would have made it part of a standards track doc.  The value to me = of it being separate is that the advice can be revised independently of = the core protocol specification.  To that extent, it is somewhere = between "Applicability statement" and "BCP" in our formal terminology, = with a thumb very slightly on the scale toward BCP. Ultimately, though, = I am willing to be guided by our ADs or the community about the exact = status. 

I could see an argument for either standards track = or BCP and don=E2=80=99t have a strong feeling either way. In either = case some adjustments would be necessary to make clear the normativity = or non-normativity of the guidance.

Alissa

The high order bits are the advice and its = decomposability.

regards,

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

= --Apple-Mail=_9D75D0A5-63F8-4B1F-B2A8-BB0C3975BF7C-- From nobody Sat Apr 2 15:52:11 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 1CC7912D522 for ; Sat, 2 Apr 2016 15:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5Og13hVKxke for ; Sat, 2 Apr 2016 15:52:08 -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 D808D12D11B for ; Sat, 2 Apr 2016 15:52:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id EE6EB7C7B99 for ; Sun, 3 Apr 2016 00:52:05 +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 uOgvcluw_xeA for ; Sun, 3 Apr 2016 00:52:05 +0200 (CEST) Received: from [IPv6:2001:67c:370:136:456b:e2c7:b74:4c84] (unknown [IPv6:2001:67c:370:136:456b:e2c7:b74:4c84]) by mork.alvestrand.no (Postfix) with ESMTPSA id A47917C7B98 for ; Sun, 3 Apr 2016 00:52:04 +0200 (CEST) To: "rtcweb@ietf.org" From: Harald Alvestrand Message-ID: <57004D0F.70300@alvestrand.no> Date: Sun, 3 Apr 2016 00:51:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [rtcweb] Positioning draft-ietf-rtcweb-ip-address as a standards-track document 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, 02 Apr 2016 22:52:10 -0000 I've read through draft-ietf-rtcweb-ip-address again, with an eye to seeing how it would read as a standards-track document. As such, it seems to me to provide rather tentative language in a few places, which could be strengthened by use of the CAPITALIZED WORDS. I think this is a Good Thing; if this is standards-track, with imperative, normative language, an implementation can claim support for RFC XXXX and expect the statement to be understood. (Remember - there is no protocol police. Nothing forces people to support RFC XXXX.) Changes needed: - Add the RFC 2119 incantation, including Stefan's addition ("lowercase words mean what they usually do") - Replace all occurences of "We recommend that..." with "an implementation MUST". - In section 3, end of first paragraph: " Specifically, WebRTC should:" -> "Implementations of this specification will:" - In section 4: "We recommend Mode 1 ... " -> "Mode 1 and mode 2 MUST be supported. Mode 1 SHOULD be the default when the user has not granted access to camera / microphone. Mode 2 SHOULD be the default when the user has granted access to camera / microphone. The implementation MAY provide means of letting the user or administrator select between modes. These means MUST NOT be placed under the control of WebRTC applications."= I think this would make the spec a more useful tool for specifying what an application does. --=20 Surveillance is pervasive. Go Dark. From nobody Sun Apr 3 09:10: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 AF4FB12D55B; Sun, 3 Apr 2016 06:19:01 -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 UMgFUC1HIyvu; Sun, 3 Apr 2016 06:18:58 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52BD112D0BA; Sun, 3 Apr 2016 06:18:58 -0700 (PDT) Received: by mail-qg0-x232.google.com with SMTP id f52so34094512qga.3; Sun, 03 Apr 2016 06:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=FkfW/cNL6xZUOOKupjKwv9VnooIzsuTlDUBGB+TiTkU=; b=Wrnyc5W1nrSicck8VvCWjM/ZKmACwwrq2ZikcFGT8rHSeIETPXFpuF0qbtt0mDQpn0 NS85UkfOBv5JEdyRPZmBsGSssOCJhNpMmOCFSfXfemziX2Hti6UbVnBs10ZcQIHtAAtp rcMHMPNN8+OJvCKqZguLbMeTOYITOqCsJxwh6lPbyvihotRjR/OF1DesNUunH9S6mIf9 kRI00VYwqpoKQo/d0tV6ZYVGEME3cHB7bV20XM529JPZkhEjttfRZ/daZTkyH5gzASJC Dz/xpu1qTFN9zkSnAVX7K+FPksg5pm0otUi98OH7eHDdpUdnTKfIcyaGfMyJOsFpDbzj qgRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=FkfW/cNL6xZUOOKupjKwv9VnooIzsuTlDUBGB+TiTkU=; b=PxjUJLn5mdTYnnBQc1yMPks2J019pv3Y7ofteITqJ60w1tvOFTqKIw8mdF6IV1ZkyI MPCacdaragh5Q/GKf3q8vbYaFONR3r4UvuNmbZ0ipVoDGUdRN7ncmHz5fVFUYjHWY3nN DUXUyNxUZQydlU93jLZwnQg0FeZONUDCLop2dUMJKqA0bWtDAc7TBm9FKpzpQ5atbXck Tfjwx/DM7JdTmcVbStor+lVdZwEG2P3xzzLYgcoXzX17TLXfI40BIVx0Zk28ZH27D1Gs rHJYYfum76QZhGyB179TE3B5yApbF8oHBc4V7grRdHvJHi+pUv+sB5BnQXYi1NOhmlLk Z7Gw== X-Gm-Message-State: AD7BkJLFLqhB/85qT05MamWXkEsw/dnP1BOwKg9W8xrybeyVAoMpUUtaQLjbH3pDpJm/dQV1wE9sjGvWNfD2zQ== MIME-Version: 1.0 X-Received: by 10.140.169.4 with SMTP id p4mr36605517qhp.71.1459689537477; Sun, 03 Apr 2016 06:18:57 -0700 (PDT) Received: by 10.140.43.131 with HTTP; Sun, 3 Apr 2016 06:18:57 -0700 (PDT) In-Reply-To: <56F98CD1.10706@gmail.com> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> <56F98CD1.10706@gmail.com> Date: Sun, 3 Apr 2016 15:18:57 +0200 Message-ID: From: Abdussalam Baryun To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a113b4cc45d2419052f9474e2 Archived-At: X-Mailman-Approved-At: Sun, 03 Apr 2016 09:10:29 -0700 Cc: IETF discussion list , "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IESG , Barry Leiba , "Scott O. Bradner" Subject: Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words] 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, 03 Apr 2016 13:19:01 -0000 --001a113b4cc45d2419052f9474e2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The confusion if occured between English authors may mean that we can get confusions among non-English authors as well, I recommend if a guidance draft is written we will need many non-Enlish native speekers involved. AB On Mon, Mar 28, 2016 at 9:58 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > There are times when I think RFC2119 was a really bad idea, despite it > having > become probably the most frequently cited RFC (inside and outside the > IETF). > It seems to create as much confusion as it avoids. > > There are four words whose RFC2119 meaning is different from the dictiona= ry > meaning: should, recommended, may and optional. Having special typography > for them is useful, because it signals the RFC2119 meanings. But if a spe= c > uses, for example, a mixture of SHOULD and should, who knows what the > authors > intended? To that extent, the proposed clarification is helpful. > > The other words (must, shall, required, not) mean what they always mean. > The only argument for upper-casing them is aesthetic symmetry. If a spec > uses alternatives like mandatory, necessary or forbidden, they are just a= s > powerful. > > So > > these definitions are only meaningful if the words are capitalized > can be applied to should, recommended, may and optional if we want, > but strictly doesn't apply to must, shall, required, not, mandatory, > necessary, forbidden, need, or any other such words. > > Where we can get into real trouble is if a spec contains should, > recommended, > may and optional *plus* other non-categorical (fuzzy) words like ought, > encourage, suggest, can, might, allowed, permit (and I did not pull those > words out of the air, but out of draft-hansen-nonkeywords-non2119). What = do > they mean? It can be very unclear. If a node receives a message containin= g > an element covered in the spec by "allowed" instead of "OPTIONAL", is the > receiver supposed to interoperate or to reject the message? > > If we are issuing guidance, it should probably include a specific warning > to use any such fuzzy words with extreme care. > > Brian > On 29/03/2016 03:13, Scott O. Bradner wrote: > > one minor tweak > > > >> On Mar 28, 2016, at 10:09 AM, Barry Leiba > wrote: > >> > >>> The wishy washy descriptive rather than proscriptive language in the > abstract was because I, > >>> the IESG and the community were not of one mind to say that the use o= f > such capitalized > >>> terms should be mandatory - quite a few people felt that the english > language was at > >>> least good enough to convey the writer=E2=80=99s intent without havi= ng to > aggrandize specific words. > >>> Thus the abstract basically was saying: if you want to use capitalize= d > words here is a standard > >>> way to say what they mean > >> > >> Ah. Then perhaps the clarification needs to go a little further and > >> make this clear: > >> - We're defining specific terms that specifications can use. > >> - These terms are always capitalized when these definitions are used. > > > > these definitions are only meaningful if the words are capitalized > > > >> - You don't have to use them. If you do, they're capitalized and > >> their meanings are as specified here. > >> - There are similar-looking English words that are not capitalized, > >> and they have their normal English meanings; this document has nothing > >> to do with them. > >> > >> ...and I'd like to add one more, because so many people think that > >> text isn't normative unless it has 2119 key words in all caps in it: > >> > >> - Normative text doesn't require the use of these key words. They're > >> used for clarity and consistency when you want that, but lots of > >> normative text doesn't need to use them, and doesn't use them. > >> > >> Barry > > > > > > --001a113b4cc45d2419052f9474e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The confusion if occured between English authors may = mean that we can get confusions among non-English authors as well, I recomm= end if a guidance draft is written we will need many non-Enlish native spee= kers involved.


AB

On Mon, Mar 28, 2016 at 9:58 PM, Brian E= Carpenter <brian.e.carpenter@gmail.com> wrote:
There are times when I think RFC2119 was a = really bad idea, despite it having
become probably the most frequently cited RFC (inside and outside the IETF)= .
It seems to create as much confusion as it avoids.

There are four words whose RFC2119 meaning is different from the dictionary=
meaning: should, recommended, may and optional. Having special typography for them is useful, because it signals the RFC2119 meanings. But if a spec<= br> uses, for example, a mixture of SHOULD and should, who knows what the autho= rs
intended? To that extent, the proposed clarification is helpful.

The other words (must, shall, required, not) mean what they always mean. The only argument for upper-casing them is aesthetic symmetry. If a spec uses alternatives like mandatory, necessary or forbidden, they are just as<= br> powerful.

So
> these definitions are only meaningful if the words are capitalized
can be applied to should, recommended, may and optional if we want,
but strictly doesn't apply to must, shall, required, not, mandatory, necessary, forbidden, need, or any other such words.

Where we can get into real trouble is if a spec contains should, recommende= d,
may and optional *plus* other non-categorical (fuzzy) words like ought,
encourage, suggest, can, might, allowed, permit (and I did not pull those words out of the air, but out of draft-hansen-nonkeywords-non2119). What do=
they mean? It can be very unclear. If a node receives a message containing<= br> an element covered in the spec by "allowed" instead of "OPTI= ONAL", is the
receiver supposed to interoperate or to reject the message?

If we are issuing guidance, it should probably include a specific warning to use any such fuzzy words with extreme care.

=C2=A0 =C2=A0Brian
On 29/03/2016 03:13, Scott O. Bradner wrote:
> one minor tweak
>
>> On Mar 28, 2016, at 10:09 AM, Barry Leiba <barryleiba@computer.org> wrote:
>>
>>> The wishy washy descriptive rather than proscriptive language = in the abstract was because I,
>>> the IESG and the community were not of one mind to say that th= e use of such capitalized
>>> terms should be mandatory - quite a few people felt that the e= nglish language was at
>>> least good enough to convey=C2=A0 the writer=E2=80=99s intent = without having to aggrandize specific words.
>>> Thus the abstract basically was saying: if you want to use cap= italized words here is a standard
>>> way to say what they mean
>>
>> Ah.=C2=A0 Then perhaps the clarification needs to go a little furt= her and
>> make this clear:
>> - We're defining specific terms that specifications can use. >> - These terms are always capitalized when these definitions are us= ed.
>
> these definitions are only meaningful if the words are capitalized
>
>> - You don't have to use them.=C2=A0 If you do, they're cap= italized and
>> their meanings are as specified here.
>> - There are similar-looking English words that are not capitalized= ,
>> and they have their normal English meanings; this document has not= hing
>> to do with them.
>>
>> ...and I'd like to add one more, because so many people think = that
>> text isn't normative unless it has 2119 key words in all caps = in it:
>>
>> - Normative text doesn't require the use of these key words.= =C2=A0 They're
>> used for clarity and consistency when you want that, but lots of >> normative text doesn't need to use them, and doesn't use t= hem.
>>
>> Barry
>
>


--001a113b4cc45d2419052f9474e2-- From nobody Mon Apr 4 06:11: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 5494512D0CA for ; Mon, 4 Apr 2016 06:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 aXCpfAMe38sY for ; Mon, 4 Apr 2016 06:11:49 -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 F00E012D585 for ; Mon, 4 Apr 2016 06:11:26 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id t10so62762844ywa.0 for ; Mon, 04 Apr 2016 06:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=K25cjbPJD7voUokwgTt20qR4GCS/HD5TOGCE4qO3myQ=; b=DoQa5CfOQdUyLZBEYdxW+3F6uQc2fFAwU5DEd0evFWLtg6EvU93JaPE84/Tfkm6vVB iZ9dmHfcRN7tgEStWucrdKrTNDgFDXmOjQb7ZWC462xJInxw11izeWdcLIIYxeJh5BHZ Ez8NSMlK1Td6/b9XCVYn310TD/wd7gn9g9vKRjcpsQGDCOlK3pY0IaqXMGv4ToCckmFT THblUT+ppBYymnT+HVDHPQdgH4m5y5HKY8kH5rF3IbtzdedhPALk8LQH0kCujUDtDLD3 c0Ezz3w8YWlOy7IkVU7aSVOR3c76wI763I8FGv8O6yNeLWUehuwfxgY7bbZasJ8IhnRt vW7g== 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=K25cjbPJD7voUokwgTt20qR4GCS/HD5TOGCE4qO3myQ=; b=SI/iJxlNHM1pC3fzjzUsgIHS6wHGH8AweMHMM7wknMrpuJSuTHsu/b+duBsaYSrG48 C4DgW4v0eoEV1yyvpNPjT0wcBtmW7JVLJtDouU6hdUcZ3xuojwRizajy5nGBEIPHUXdF WFwmtGoIDUt8xo1hU2Vs7rdTkiklgkGOHF1amxC24cj6XE+qCxRWGozOJ62rFcTR/w0V ld57ui3LGgJaGTboDhctW062a4h6f39Dv7+ARqT7NJwjzIcozhROBkVmf7hVPikQccF7 SgX4MiOWotJu6ZVjncI6KycbbDRRb4sEkAjc91dt47FNkPqmjfgpz6gblSGsRUXT0lsD /tHQ== X-Gm-Message-State: AD7BkJKjXXfyqykiCAVM/0FUdHfxBYVujnLMI4UbHtGuWz6BGJJO86DuitZiCQoJMzsnOm0ViAfExaWRmqiHkg== X-Received: by 10.13.193.4 with SMTP id c4mr5386834ywd.192.1459775486196; Mon, 04 Apr 2016 06:11:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Mon, 4 Apr 2016 06:10:46 -0700 (PDT) From: Eric Rescorla Date: Mon, 4 Apr 2016 10:10:46 -0300 Message-ID: To: mmusic WG , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a114caa9e4eaa62052fa87745 Archived-At: Subject: [rtcweb] Tunnelling DTLS in SDP 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, 04 Apr 2016 13:11:51 -0000 --001a114caa9e4eaa62052fa87745 Content-Type: text/plain; charset=UTF-8 Hi folks, I wanted to call your attention to a draft I just published with a possibly stupid idea. https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 A nontrivial fraction of call setup time in WebRTC is the DTLS handshake. This document describes how to piggyback the first few handshake messages in the SDP offer/answer exchange, thus reducing latency. Comments welcome. -Ekr --001a114caa9e4eaa62052fa87745 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi folks,

I wanted to call your attenti= on to a draft I just published with a possibly stupid
idea.
=



Comments welcome.

-Ekr



--001a114caa9e4eaa62052fa87745-- From nobody Mon Apr 4 08:39: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 EBAFE12D5A7 for ; Mon, 4 Apr 2016 08:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Qr4gF1hsJtd for ; Mon, 4 Apr 2016 08:39:09 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BBAA12D5A0 for ; Mon, 4 Apr 2016 08:39:09 -0700 (PDT) Received: (qmail 54293 invoked from network); 4 Apr 2016 15:39:07 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 9605 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 4 Apr 2016 15:39:07 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id 0884D18A05A7; Mon, 4 Apr 2016 16:39:04 +0100 (BST) Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id EE56C18A06CD; Mon, 4 Apr 2016 16:39:03 +0100 (BST) Received: from [192.67.4.155] (unknown [192.67.4.155]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id C66F018A05A7; Mon, 4 Apr 2016 16:39:03 +0100 (BST) Content-Type: multipart/alternative; boundary="Apple-Mail=_C9F1BDF5-1050-464A-9585-99CC41E96A78" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: pfh In-Reply-To: Date: Mon, 4 Apr 2016 16:39:03 +0100 Message-Id: References: To: Eric Rescorla X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [rtcweb] Tunnelling DTLS in SDP 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, 04 Apr 2016 15:39:12 -0000 --Apple-Mail=_C9F1BDF5-1050-464A-9585-99CC41E96A78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 4 Apr 2016, at 14:10, Eric Rescorla wrote: >=20 > Hi folks, >=20 > I wanted to call your attention to a draft I just published with a = possibly stupid > idea. >=20 > https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 = >=20 > A nontrivial fraction of call setup time in WebRTC is the DTLS = handshake. > This document describes how to piggyback the first few handshake = messages > in the SDP offer/answer exchange, thus reducing latency. It strikes me we could get the same reduced latency benefits by = piggybacking on ICE rather than SDP, e.g. embedding the DTLS packet as data in a new STUN = attribute type. The downside of piggybacking on the SDP is that you are increasing the = trust you have to place in the signalling server undermining the elegant decoupling we have at the = moment between signalling and=20 media. (The SDES issues of logging keys in the web servers apply to the = public certs as well). It also significantly clutters the SDP (even more) ! As you point out, it weakens the usefulness of longer term certs, which would be a major nuisance IMHO. Tim. --Apple-Mail=_C9F1BDF5-1050-464A-9585-99CC41E96A78 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 4 Apr 2016, at 14:10, Eric Rescorla <ekr@rtfm.com> = wrote:

Hi folks,

I wanted to call your attention to a draft I just published = with a possibly stupid
idea.
https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00

A = nontrivial fraction of call setup time in WebRTC is the DTLS = handshake.
This document describes how to piggyback = the first few handshake messages
in the SDP = offer/answer exchange, thus reducing = latency.

It = strikes me we could get the same reduced latency benefits by = piggybacking on ICE
rather than SDP, e.g. embedding the DTLS = packet as data in a new STUN attribute type.

The downside of piggybacking on the SDP is that = you are increasing the trust you have to place in = the
signalling server undermining the elegant decoupling we = have at the moment between signalling and 
media. (The = SDES issues of logging keys in the web servers apply to the public certs = as well).

It also significantly = clutters the SDP (even more) !

As = you point out, it weakens the usefulness of longer term certs, = which
would be a major nuisance IMHO.

Tim.

= --Apple-Mail=_C9F1BDF5-1050-464A-9585-99CC41E96A78-- From nobody Mon Apr 4 08:53: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 9ADAE12D70C for ; Mon, 4 Apr 2016 08:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-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 duCWk7bDCoAR for ; Mon, 4 Apr 2016 08:53:27 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::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 40AED12D724 for ; Mon, 4 Apr 2016 08:53:27 -0700 (PDT) Received: by mail-ig0-x229.google.com with SMTP id f1so77538617igr.1 for ; Mon, 04 Apr 2016 08:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=nwfe2jg/zA+WfPnuTDI9eM5g4s0IxSFBLbPK0VkIMXc=; b=LuWLSecE0A0bPEgMO4FkPp4KA8nENrerMTiPKxfSZb7MGihfA6mlgo4VRcbt2R7Y96 XoySA4U25zAxMMGEmFSIvgtGYjttgNg118opR92B7ZNDesUBLDKJ540barxeAQIGS+bW ghy9IZU9L5O5JKzZ+9b4kcOApKZBYunytDinnUuISWQeO+QIXx6MAf+8vL3sE0a03p7Q OG++kccIgCb4B4aPJxtNuNUhj55YLIaX4oIYKt/BRFVpJlQ1wp08QUFJGbCrQL6jVexk +ZTcbtVpWT2uuXU+hzf7aarNVOuwkumaJpATn3VHkRVyk04lePFEK21txC2kCUXj7Bg7 rzcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=nwfe2jg/zA+WfPnuTDI9eM5g4s0IxSFBLbPK0VkIMXc=; b=HzAlynYl8QncUTwBJx/dR7BACj+7GDfv2LFbd7Mzvg3pwbreY6nrBiyhKgYAEhEgRK klIYo3g0EpmMWGvOHhQi60zXkB3CwibCZboWn3rQ42VYYMZ9AIRAAQCM18uDKFOg1oqP 5gIR5BSawqyAbPjve/WgAqbVjPoIML7EUP3C5uaeYBcerHQnCt2wVSRCj1YTqAKh2GmD SO9xAgXeYwUi1Yv8f/Iv8U4u6JVDYBdoCUKKep/+hCVNvwGm/G569hrGtO23Jh2pt3L8 Eh546oWKGoi0JGsH6Zuoe5lwiNCqxj/JvOqA+lyjNATtGUZwEm1b7C96sMi4U9u6bwh8 wWPw== X-Gm-Message-State: AD7BkJLlzD0FzYeJlSGFbrgiyCHZbpb2jbsDUvDlkJY7OYQ3zf3ZLQSJ9sJzziXYR7sRnQ== X-Received: by 10.107.137.72 with SMTP id l69mr8111840iod.177.1459785185417; Mon, 04 Apr 2016 08:53:05 -0700 (PDT) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com. [209.85.213.180]) by smtp.gmail.com with ESMTPSA id p1sm11850566iop.12.2016.04.04.08.53.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2016 08:53:05 -0700 (PDT) Received: by mail-ig0-f180.google.com with SMTP id gy3so35129605igb.1; Mon, 04 Apr 2016 08:53:05 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.30.71 with SMTP id e68mr8044333ioe.145.1459785168790; Mon, 04 Apr 2016 08:52:48 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Mon, 4 Apr 2016 08:52:48 -0700 (PDT) In-Reply-To: References: Date: Mon, 4 Apr 2016 11:52:48 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1140d71e6f72a6052faab865 Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [rtcweb] Tunnelling DTLS in SDP 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, 04 Apr 2016 15:53:28 -0000 --001a1140d71e6f72a6052faab865 Content-Type: text/plain; charset=UTF-8 The proposal makes sense to me. 1. Why do you need to send both fingerprints and certificates in answer? If certificate is sent, fingerprint can be calculated from it and will be completely redundant. 2. Can you show where and how the DTLS-SRTP keys are going to be sent? I assume they will be transmitted together with ChangeCipherSpec. I think sending certificate in the answer instead of data path does not compromise security since if signaling path is compromised, data traffic can be redirected to MITM agent which can collect exactly the same data. This has the benefit over sending DTLS handshake using ICE/STUN messages that it does not need to deal with packet fragmentation and reassembly. Regards, _____________ Roman Shpount On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla wrote: > Hi folks, > > I wanted to call your attention to a draft I just published with a > possibly stupid > idea. > > https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 > > A nontrivial fraction of call setup time in WebRTC is the DTLS handshake. > This document describes how to piggyback the first few handshake messages > in the SDP offer/answer exchange, thus reducing latency. > > Comments welcome. > > -Ekr > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a1140d71e6f72a6052faab865 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The proposal makes sense to me.

1= . Why do you need to send both fingerprints and certificates in answer? If = certificate is sent, fingerprint can be calculated from it and will be comp= letely redundant.

2. Can you show where and how the DTLS= -SRTP keys are going to be sent? I assume they will be transmitted together= with=C2=A0ChangeCiphe= rSpec.

I think sending certificate in the answer instead = of data path does not compromise security since if signaling path is compro= mised, data traffic can be redirected to MITM agent which can collect exact= ly the same data.

This has the benefit over sending = DTLS handshake using ICE/STUN messages that it does not need to deal with p= acket fragmentation and reassembly.

<= font color=3D"#000000">Regards,<= /font>
______= _______
Roman Shpount

On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorl= a <e= kr@rtfm.com> wrote:
Hi f= olks,

I wanted to call your attention to a draft I just = published with a possibly stupid
idea.

<= a href=3D"https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00" target= =3D"_blank">https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00

A nontrivial fraction of call setup time in Web= RTC is the DTLS handshake.
This document describes how to piggyba= ck the first few handshake messages
in the SDP offer/answer excha= nge, thus reducing latency.

Comments welcome.

-Ekr




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


--001a1140d71e6f72a6052faab865-- From nobody Mon Apr 4 09:15: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 A3C2912D0E7 for ; Mon, 4 Apr 2016 09:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nd09p9nRi5bg for ; Mon, 4 Apr 2016 09:15:05 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DFD412D18B for ; Mon, 4 Apr 2016 09:15:04 -0700 (PDT) Received: (qmail 14689 invoked from network); 4 Apr 2016 16:15:02 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 10215 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 4 Apr 2016 16:15:02 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id A27FF18A06B9; Mon, 4 Apr 2016 17:14:56 +0100 (BST) Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id 9450F18A06CD; Mon, 4 Apr 2016 17:14:56 +0100 (BST) Received: from [192.67.4.155] (unknown [192.67.4.155]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 7207018A06B9; Mon, 4 Apr 2016 17:14:56 +0100 (BST) Content-Type: multipart/alternative; boundary="Apple-Mail=_CBA730B1-49D0-4F83-ADCE-6D47B641E939" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: pfh In-Reply-To: Date: Mon, 4 Apr 2016 17:14:56 +0100 Message-Id: <87A18530-F6C8-4960-A5B8-215B677E5913@phonefromhere.com> References: To: Roman Shpount X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Tunnelling DTLS in SDP 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, 04 Apr 2016 16:15:06 -0000 --Apple-Mail=_CBA730B1-49D0-4F83-ADCE-6D47B641E939 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 4 Apr 2016, at 16:52, Roman Shpount wrote: >=20 >=20 > I think sending certificate in the answer instead of data path does = not compromise security since if signaling path is compromised, data = traffic can be redirected to MITM agent which can collect exactly the = same data. That isn=E2=80=99t quite the same, currently in a MITM=E2=80=99d = scenario you have the option of not completing the DTLS handshake = (assuming you had a way to verify the fingerprints.). With this change you=E2=80=99ll have all = the certs logged in a web server somewhere. >=20 > This has the benefit over sending DTLS handshake using ICE/STUN = messages that it does not need to deal with packet fragmentation and = reassembly. DTLS does have support for packet assembly/disassembly. I=E2=80=99d be = surprised if the DTLS handshake packets exceeded a reasonable MTU, unless you are sending a full chain of certificates or stuffing a logo = into the x509 :-)=20 Stepping back from the detail, (D)TLS implementations are brittle enough = as it is, we should avoid introducing a whole new level of complexity if we can. Implementing this piggybacking in ICE at least = keeps it in the media path, rather than spreading it through the signalling and web servers too. T. >=20 > Regards, > _____________ > Roman Shpount >=20 > On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla > wrote: > Hi folks, >=20 > I wanted to call your attention to a draft I just published with a = possibly stupid > idea. >=20 > https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 = >=20 > A nontrivial fraction of call setup time in WebRTC is the DTLS = handshake. > This document describes how to piggyback the first few handshake = messages > in the SDP offer/answer exchange, thus reducing latency. >=20 > Comments welcome. >=20 > -Ekr >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_CBA730B1-49D0-4F83-ADCE-6D47B641E939 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 4 Apr 2016, at 16:52, Roman Shpount <roman@telurix.com> = wrote:


I think sending certificate in the answer instead of data = path does not compromise security since if signaling path is = compromised, data traffic can be redirected to MITM agent which can = collect exactly the same = data.

That isn=E2=80=99t quite the same, currently in a = MITM=E2=80=99d scenario you have the option of not completing the DTLS = handshake (assuming you had a way
to verify the = fingerprints.). With this change you=E2=80=99ll have all the certs = logged in a web server somewhere.


This has the = benefit over sending DTLS handshake using ICE/STUN messages that it does = not need to deal with packet fragmentation and = reassembly.

DTLS does have support for packet = assembly/disassembly. I=E2=80=99d be surprised if the DTLS handshake = packets exceeded a reasonable MTU,
unless you are sending a = full chain of certificates or stuffing a logo into the x509 = :-) 

Stepping back from the = detail, (D)TLS implementations are brittle enough as it is, we should = avoid introducing a whole new level
of complexity if we can. = Implementing this piggybacking in ICE at least keeps it in the media = path, rather than spreading it through the
signalling and web = servers too.

T.



Regards,
_____________
Roman = Shpount

On Mon, Apr 4, 2016 at 9:10 = AM, Eric Rescorla <ekr@rtfm.com> wrote:
Hi folks,

I wanted to call your = attention to a draft I just published with a possibly stupid
idea.

https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00

A = nontrivial fraction of call setup time in WebRTC is the DTLS = handshake.
This document describes how to piggyback = the first few handshake messages
in the SDP = offer/answer exchange, thus reducing latency.

Comments welcome.

-Ekr




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

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

= --Apple-Mail=_CBA730B1-49D0-4F83-ADCE-6D47B641E939-- From nobody Mon Apr 4 09:47: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 27D4612D0E2 for ; Mon, 4 Apr 2016 09:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=telurix-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 kMk9rvZGgM8o for ; Mon, 4 Apr 2016 09:47:29 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::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 77F2012D119 for ; Mon, 4 Apr 2016 09:47:28 -0700 (PDT) Received: by mail-ig0-x229.google.com with SMTP id g8so37947220igr.0 for ; Mon, 04 Apr 2016 09:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=91mUTEh72TwhEGiMU8iFIfbnHKuIfKM9m8ffc/oqI64=; b=sPPnexc5y7/41tNxPoFbCDMWhO52TzT98oekz747UwESXu3qlhD4tzvMy0ciNmkZDu ublCdd87yaJp/rQZPA96o83r9yD1YzUZCAhjzB6QD8v7nsnFOurE3FO1e9UxE44FTxoa 1UfpVQ5X7UeLFoU7Yo/KCT0bAU2K71FnBXvwY+Z5lvhrOral9swIcRoaJseIlwvDCbKV tOS+Jg7jhG5niaXJfIPwHG+vE0rESqStq5gp6WrM4GJcUCBYfy/VfmNpZesF1hxj0M+6 /42tWh0Bj4XSv36e02LA/RKaq0BekPnnIdgKorAbB+yac4c2agcfXk81u9+buUNMU8vq kkcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=91mUTEh72TwhEGiMU8iFIfbnHKuIfKM9m8ffc/oqI64=; b=NwTfmWMC3hzKltt9A4xfb84PiWjuFxoC8BhxuamTy0UFhEbSmnX5FBFjVp+oDGgcwl riICVWUzDGAwFlN1LGXfQFEjAy7ztLecXXxyFSLYHwDhavev5vTaE6ZRtg+bK5TVGC2T oBtCXuYWWj0cDNoMYmqzD4wiOn456tUWYnp4bYBJz/iNFLl24snls1ZvnFFTUTkPXVx7 Gp/TOIIBloJ74A4aWYHGfGV4yfQjXk6488aJ7HGpblaENwo2zAcNz5P6gNNAW8y/FZfz AcCn+yTLbqqBxyWi3Wdmf30nAodpFqgbC0hkSDuAB60DjP9IEqUZpTdz79poro+nN3++ pEOg== X-Gm-Message-State: AD7BkJLNt/JaG5IUrTwctT5lGpeTXtERFQD5FTa/uUgc/4dZy9ibYpvJiIuRqNQA/5Rcsg== X-Received: by 10.50.40.101 with SMTP id w5mr12152187igk.17.1459788447517; Mon, 04 Apr 2016 09:47:27 -0700 (PDT) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com. [209.85.213.179]) by smtp.gmail.com with ESMTPSA id 99sm11961903ior.16.2016.04.04.09.47.27 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2016 09:47:27 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id f1so79803582igr.1 for ; Mon, 04 Apr 2016 09:47:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.30.71 with SMTP id e68mr8309382ioe.145.1459788446309; Mon, 04 Apr 2016 09:47:26 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Mon, 4 Apr 2016 09:47:26 -0700 (PDT) In-Reply-To: <87A18530-F6C8-4960-A5B8-215B677E5913@phonefromhere.com> References: <87A18530-F6C8-4960-A5B8-215B677E5913@phonefromhere.com> Date: Mon, 4 Apr 2016 12:47:26 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: pfh Content-Type: multipart/alternative; boundary=001a1140d71eca2468052fab7bd4 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Tunnelling DTLS in SDP 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, 04 Apr 2016 16:47:32 -0000 --001a1140d71eca2468052fab7bd4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Apr 4, 2016 at 12:14 PM, pfh wrote: > > On 4 Apr 2016, at 16:52, Roman Shpount wrote: > > > I think sending certificate in the answer instead of data path does not > compromise security since if signaling path is compromised, data traffic > can be redirected to MITM agent which can collect exactly the same data. > > > That isn=E2=80=99t quite the same, currently in a MITM=E2=80=99d scenario= you have the > option of not completing the DTLS handshake (assuming you had a way > to verify the fingerprints.). With this change you=E2=80=99ll have all th= e certs > logged in a web server somewhere. > In the scenario I had in mind MTIM will not modify fingerprints, it will modify the transport addresses or put itself on the media path using a compromised router so that it can log the DTLS handshake (and subsequent media). This will provide exactly the same security risk as logging signaling exchange when certificate is sent in the signaling path. In order to compromise media, attacker needs access to the media path. Once it gets access to the media path, it gets access to DTLS handshake and certificates. If one of those certificates is sent over signaling channel, it does not make the whole flow any less secure. Actually you might argue it makes it more secure, since now attacker needs to compromise both media and signaling paths in order to decode. _____________ Roman Shpount --001a1140d71eca2468052fab7bd4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 4, 2016 at 12:14 PM, pfh <tim@phonefromhere.com&g= t; wrote:

On 4 Apr 2016, at 16:52, Roman Shpount <roman@telurix.com> wrote:<= /div>

I think sending certificate in the answer instead of data= path does not compromise security since if signaling path is compromised, = data traffic can be redirected to MITM agent which can collect exactly the = same data.

That isn=E2=80=99t quite the same, currently in a MITM=E2=80=99d sce= nario you have the option of not completing the DTLS handshake (assuming yo= u had a way
to verify the fingerprints.). With this change you=E2= =80=99ll have all the certs logged in a web server somewhere.

In the scenario= I had in mind MTIM will not modify fingerprints, it will modify the transp= ort addresses or put itself on the media path using a compromised router so= that it can log the DTLS handshake (and subsequent media). This will provi= de exactly the same security risk as logging signaling exchange when certif= icate is sent in the signaling path. In order to compromise media, attacker= needs access to the media path. Once it gets access to the media path, it = gets access to DTLS handshake and certificates. If one of those certificate= s is sent over signaling channel, it does not make the whole flow any less = secure. Actually you might argue it makes it more secure, since now attacke= r needs to compromise both media and signaling paths in order to decode.
_________= ____
Roman Shpount

--001a1140d71eca2468052fab7bd4-- From nobody Mon Apr 4 10:34:32 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 BE0C812D60F; Mon, 4 Apr 2016 10:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 UCkB8yPx8Xwz; Mon, 4 Apr 2016 10:34:30 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::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 5094712D12E; Mon, 4 Apr 2016 10:34:30 -0700 (PDT) Received: by mail-ig0-x231.google.com with SMTP id g8so40346015igr.0; Mon, 04 Apr 2016 10:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=TokuKdW0ADzGH3lJNCaQsMCzI3ZR9tsLGNUolC2Woa0=; b=HQcfMMvhN+lyb38nFTYVYsy39FEJKpZvLwmNIb7sbsUl7LgmDmNZe4CN8haJw90nBH PVeWP+lLZv5ZoHhR3JOTuR8VmBwc479iPV4ODYbVcVsCjWPA0wZSuDy6V9tCOJWPoDeP VVBpHZ8fSDaAEX/+oSNh7N2U016TdtZWRCZ6MIdRxxk4FScDD0NLmjDG3Lo38tEGfw+V Tarn43tqILQq8mqWyKvq4Y9ErVKsIxI6mJWEXmcws2k1AK68k08aagBA6kgjc7jkSLT1 dLyUdv07bor35y5CFd7LMwtajwnUtTmCPkLQD5QUHy+peEu4rx8s+u/CAAFv8EnWCUJX djgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=TokuKdW0ADzGH3lJNCaQsMCzI3ZR9tsLGNUolC2Woa0=; b=ljTdjwvZ2sHpQP5zr1C/HYrfttj4JNMLNz0QAUK0Ut2nElql+kAtGU+/1oN1QdVAgg ZL+06ffMb2W6vmBe48VUDtuynXxpQct1hJVfVEAj9RlBGcrMIiVY+p7bMVKoWzhDSysn +QZdlUSuKWz6gYQtFJeiwYA9DyRvM+PXVREFcUZjALWq5mMAyOALrgTD8mH7quBN8Voi DaQo8qJitMN78Wk89WA/Wh4t2MuIw1Jv/r8fKFOkgVIs1f7lCogdWata5Z3R/pNXDugy dpS7FzILHRkXvJycUIaBi7WQNdTx0gCErTKOa0lSCi0XxpvBxtpnlX1yP3iyjvu2dwjf dlTA== X-Gm-Message-State: AD7BkJJ4AC3lUxZPPkp5aGPydsdQSVcuBJZKe98x220ZfYSakl/BzASc+IxQ2JIwmMzcL5kkeEXqRE3B6jQGjw== MIME-Version: 1.0 X-Received: by 10.50.221.67 with SMTP id qc3mr12769650igc.77.1459791269598; Mon, 04 Apr 2016 10:34:29 -0700 (PDT) Received: by 10.36.43.5 with HTTP; Mon, 4 Apr 2016 10:34:29 -0700 (PDT) In-Reply-To: References: Date: Mon, 4 Apr 2016 14:34:29 -0300 Message-ID: From: Martin Thomson To: pfh Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [rtcweb] Tunnelling DTLS in SDP 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, 04 Apr 2016 17:34:31 -0000 On 4 April 2016 at 12:39, pfh wrote: > It strikes me we could get the same reduced latency benefits by piggybacking > on ICE > rather than SDP, e.g. embedding the DTLS packet as data in a new STUN > attribute type. One of the goals for connectivity checks is to keep them small. Cramming DTLS in is not compatible with this. From nobody Mon Apr 4 10:35: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 9589712D118 for ; Mon, 4 Apr 2016 10:34:58 -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 8z_w8V9Cg7C9 for ; Mon, 4 Apr 2016 10:34:53 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001: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 B083E12D12E for ; Mon, 4 Apr 2016 10:34:53 -0700 (PDT) Received: by mail-ig0-x234.google.com with SMTP id f1so81829299igr.1 for ; Mon, 04 Apr 2016 10:34:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=eHA3/WeKY1xCytUOWhLGWnnnJB+4Viotgjk7MB/n7xg=; b=gNNcqtt9zRxVMh+4HGnwyPTjj6kU+nux7WUenwu3y0FOOLgf7F5/g/v03EatFog7IP EO3BpvNhWhvBDajdhCc1RykehJJK9ASUaP6xydk2G/nEUJnoyBxSTXhZNQ4clso7ZbkM tO5t71Q9RaXh8yQH+IoeEU6b20Je2u7WqYLXzk5AJNA4Qvd75jEvEzOLb/i7XLx2b37Q bASjxz2Ijy6lRkwSvefsTHJAwrJImrNt9Qzm9ejuDntwJKGkVcTEPsV8B87Xc2XrcS8v qUJIo8PLozq1veD6+ErLRWy5O7snlR25hzeLgRSe/u1fCVRwAx04UUlH19UdoaBUFSxA q70g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=eHA3/WeKY1xCytUOWhLGWnnnJB+4Viotgjk7MB/n7xg=; b=a01fYRaulG7WfK99WwfWjNuMKl+Q8JnrHuF8ubaWguytBaOQnW3qbPZjhCvQhBCflg RAPEZSaBNMVNm+70UZirhuXyTmeBOItjzZ0o+sEKyw47FGG36Z03XoAhDgIzTE8xc8oT TMXn4Um8fy7Ipl3dzuMR/h/lg6LVpk4hoMRZB0tH2WoYLnUPxxQvQhqzffGzG9hryZZy S0cs16+NiX2zXeG42TeQIJIQJiN5FkL5qvbVJn6ya/nQwEI9Kv0PJZrvKiClFH1/Pej3 MEXUi1Fuh1VkOFo3F+YLpBPq5Esh9DA3dyejej6risD670mrZMHzBcbiTDW6obDTJNGh QHoA== X-Gm-Message-State: AD7BkJIiik8duwW60MiD2QBKLRIa3ddeyJmXiMtqNk2R5wq9iIeVnuslQDXlDmbRTq2p9ilFYW9hbspBB/s/cA== MIME-Version: 1.0 X-Received: by 10.107.166.72 with SMTP id p69mr7315439ioe.100.1459791291359; Mon, 04 Apr 2016 10:34:51 -0700 (PDT) Received: by 10.36.43.5 with HTTP; Mon, 4 Apr 2016 10:34:51 -0700 (PDT) In-Reply-To: <87A18530-F6C8-4960-A5B8-215B677E5913@phonefromhere.com> References: <87A18530-F6C8-4960-A5B8-215B677E5913@phonefromhere.com> Date: Mon, 4 Apr 2016 14:34:51 -0300 Message-ID: From: Martin Thomson To: pfh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Tunnelling DTLS in SDP 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, 04 Apr 2016 17:34:59 -0000 On 4 April 2016 at 13:14, pfh wrote: > I=E2=80=99d be surprised if the DTLS handshake packets exceeded a reasona= ble MTU, > unless you are sending a full chain of certificates or stuffing a logo in= to > the x509 :-) Fragmentation is common. From nobody Mon Apr 4 11:02:40 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 7815412D0B9; Mon, 4 Apr 2016 11:02:37 -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 3lcJ1lA5APsH; Mon, 4 Apr 2016 11:02:35 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928F612D0B0; Mon, 4 Apr 2016 11:02:34 -0700 (PDT) X-AuditID: c1b4fb25-f79f86d00000400a-0e-5702ac38ca98 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B7.E9.16394.83CA2075; Mon, 4 Apr 2016 20:02:32 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0248.002; Mon, 4 Apr 2016 20:02:32 +0200 From: Christer Holmberg To: Eric Rescorla , mmusic WG , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Tunnelling DTLS in SDP Thread-Index: AQHRjnOQTXAAgUuNbU6Yumm3JEpBMZ953U5w Date: Mon, 4 Apr 2016 18:02:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F218C3@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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37F218C3ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM2K7iq7FGqZwg/eL9S1WvD7HbjF1+WMW i7X/2tkdmD2WLPnJ5DH5cRtzAFMUl01Kak5mWWqRvl0CV8bR1/dZCy45V5zZ9JaxgfGBYxcj J4eEgInE9gV/mCFsMYkL99azdTFycQgJHGGUWDv3MpSziFFi95rt7F2MHBxsAhYS3f+0QRpE BFIkeo6dZASxhQV0JA4t2sgEEdeV2HdxNzuEbSRxb8sjsDiLgIrE41U/2UDG8Ar4Slx6VwgS FhIIkLjx8B/YGE6BQIkju5+A3cMIdM/3U2vAWpkFxCVuPZnPBHGngMSSPeehbhaVePn4HyuE rSTRuOQJK8h4ZoF8iRdXTEHCvAKCEidnPmGZwCgyC8mkWQhVs5BUQYQ1Jdbv0oeoVpSY0v2Q HcLWkGidM5cdWXwBI/sqRtHi1OKk3HQjY73Uoszk4uL8PL281JJNjMDIOrjlt+oOxstvHA8x CnAwKvHwLjjFGC7EmlhWXJl7iFGCg1lJhLdlJVO4EG9KYmVValF+fFFpTmrxIUZpDhYlcd7s yH9hQgLpiSWp2ampBalFMFkmDk6pBkbXmvWbrmX8CNn+0EHLa1dA2cTqHbH/uEKuBimHijyM l3DLZ5t7O0eizlbh4YMut4S38QtnnuDg2nDpz7WvXhv6f6Yc23b0tg9z2o2qz19ePmW2CK5r bxBIyJ/P78amsmWHvuWB359WW6+pm7eRS8r22Od3qqyGBs9jXt1guaLrt/V2T9zb/+xKLMUZ iYZazEXFiQAlEwhmqAIAAA== Archived-At: Subject: Re: [rtcweb] Tunnelling DTLS in SDP 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, 04 Apr 2016 18:02:37 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37F218C3ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClJlZ2FyZGluZyBmb3JraW5nLCB5b3UgY2Fubm90IGFzc3VtZSB0aGF0IGZvcmtpbmcg ZW50aXRpZXMgd2lsbCByZW1vdmUgdGhlIFNEUCBhdHRyaWJ1dGUuIFVubGVzcyB0aGV5IHN1cHBv cnQgdGhlIGF0dHJpYnV0ZSwgdGhleSB3aWxsIG1vc3QgbGlrZWx5IGp1c3QgZm9yd2FyZCBpdC4g VGhlIG9mZmVyZXIgd2lsbCBmaW5kIG91dCBpZiBmb3JraW5nIGhhcyBvY2N1cnJlZCwgYnV0IGhl IGFuc3dlcmVyKHMpIHdpbGwgbm90IGtub3cuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZy b206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg RXJpYyBSZXNjb3JsYQ0KU2VudDogMDQgQXByaWwgMjAxNiAxNjoxMQ0KVG86IG1tdXNpYyBXRyA8 bW11c2ljQGlldGYub3JnPjsgcnRjd2ViQGlldGYub3JnDQpTdWJqZWN0OiBbcnRjd2ViXSBUdW5u ZWxsaW5nIERUTFMgaW4gU0RQDQoNCkhpIGZvbGtzLA0KDQpJIHdhbnRlZCB0byBjYWxsIHlvdXIg YXR0ZW50aW9uIHRvIGEgZHJhZnQgSSBqdXN0IHB1Ymxpc2hlZCB3aXRoIGEgcG9zc2libHkgc3R1 cGlkDQppZGVhLg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmVzY29ybGEt ZHRscy1pbi1zZHAtMDANCg0KQSBub250cml2aWFsIGZyYWN0aW9uIG9mIGNhbGwgc2V0dXAgdGlt ZSBpbiBXZWJSVEMgaXMgdGhlIERUTFMgaGFuZHNoYWtlLg0KVGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgaG93IHRvIHBpZ2d5YmFjayB0aGUgZmlyc3QgZmV3IGhhbmRzaGFrZSBtZXNzYWdlcw0KaW4g dGhlIFNEUCBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UsIHRodXMgcmVkdWNpbmcgbGF0ZW5jeS4NCg0K Q29tbWVudHMgd2VsY29tZS4NCg0KLUVrcg0KDQoNCg0K --_000_7594FB04B1934943A5C02806D1A2204B37F218C3ESESSMB209erics_ 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 b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIu MHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkaW5nIGZv cmtpbmcsIHlvdSBjYW5ub3QgYXNzdW1lIHRoYXQgZm9ya2luZyBlbnRpdGllcyB3aWxsIHJlbW92 ZSB0aGUgU0RQIGF0dHJpYnV0ZS4gVW5sZXNzIHRoZXkgc3VwcG9ydCB0aGUgYXR0cmlidXRlLCB0 aGV5IHdpbGwNCiBtb3N0IGxpa2VseSBqdXN0IGZvcndhcmQgaXQuIFRoZSBvZmZlcmVyIHdpbGwg ZmluZCBvdXQgaWYgZm9ya2luZyBoYXMgb2NjdXJyZWQsIGJ1dCBoZSBhbnN3ZXJlcihzKSB3aWxs IG5vdCBrbm93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxh IG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5j ZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5T ZW50OjwvYj4gMDQgQXByaWwgMjAxNiAxNjoxMTxicj4NCjxiPlRvOjwvYj4gbW11c2ljIFdHICZs dDttbXVzaWNAaWV0Zi5vcmcmZ3Q7OyBydGN3ZWJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gW3J0Y3dlYl0gVHVubmVsbGluZyBEVExTIGluIFNEUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhpIGZvbGtzLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSB3YW50ZWQgdG8gY2FsbCB5b3VyIGF0dGVudGlvbiB0byBhIGRyYWZ0 IEkganVzdCBwdWJsaXNoZWQgd2l0aCBhIHBvc3NpYmx5IHN0dXBpZDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aWRlYS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlc2NvcmxhLWR0bHMtaW4tc2RwLTAwIj5odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmVzY29ybGEtZHRscy1pbi1zZHAtMDA8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgbm9u dHJpdmlhbCBmcmFjdGlvbiBvZiBjYWxsIHNldHVwIHRpbWUgaW4gV2ViUlRDIGlzIHRoZSBEVExT IGhhbmRzaGFrZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyB0byBwaWdneWJhY2sgdGhlIGZpcnN0 IGZldyBoYW5kc2hha2UgbWVzc2FnZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmluIHRoZSBTRFAgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlLCB0aHVz IHJlZHVjaW5nIGxhdGVuY3kuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkNvbW1lbnRzIHdlbGNvbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B37F218C3ESESSMB209erics_-- From nobody Mon Apr 4 13:42:18 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 C302812D895 for ; Mon, 4 Apr 2016 13:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVOXHpPva17R for ; Mon, 4 Apr 2016 13:42:14 -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 5284912D815 for ; Mon, 4 Apr 2016 13:42:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id BD3397C7BD2 for ; Mon, 4 Apr 2016 22:42:12 +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 AQZq2p2mwgAA for ; Mon, 4 Apr 2016 22:42:11 +0200 (CEST) Received: from [IPv6:2001:67c:370:136:2154:8066:f6ed:c7f7] (unknown [IPv6:2001:67c:370:136:2154:8066:f6ed:c7f7]) by mork.alvestrand.no (Postfix) with ESMTPSA id 2CBDB7C7BC2 for ; Mon, 4 Apr 2016 22:42:10 +0200 (CEST) To: rtcweb@ietf.org References: From: Harald Alvestrand Message-ID: <5702D19F.9030305@alvestrand.no> Date: Mon, 4 Apr 2016 22:42:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040307010908010001010300" Archived-At: Subject: Re: [rtcweb] Tunnelling DTLS in SDP 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, 04 Apr 2016 20:42:18 -0000 This is a multi-part message in MIME format. --------------040307010908010001010300 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 04/04/2016 05:39 PM, pfh wrote: > >> On 4 Apr 2016, at 14:10, Eric Rescorla > > wrote: >> >> Hi folks, >> >> I wanted to call your attention to a draft I just published with a >> possibly stupid >> idea. >> >> https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 >> >> A nontrivial fraction of call setup time in WebRTC is the DTLS handshake. >> This document describes how to piggyback the first few handshake messages >> in the SDP offer/answer exchange, thus reducing latency. > > It strikes me we could get the same reduced latency benefits by > piggybacking on ICE > rather than SDP, e.g. embedding the DTLS packet as data in a new STUN > attribute type. Piggybacking in ICE means that you have to repeat it in every probe packet, since you don't know which is going to make it through. And you can't start ICE probing until the handshake has completed. --------------040307010908010001010300 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 04/04/2016 05:39 PM, pfh wrote:

On 4 Apr 2016, at 14:10, Eric Rescorla <ekr@rtfm.com> wrote:

Hi folks,

I wanted to call your attention to a draft I just published with a possibly stupid
idea.


A nontrivial fraction of call setup time in WebRTC is the DTLS handshake.
This document describes how to piggyback the first few handshake messages
in the SDP offer/answer exchange, thus reducing latency.

It strikes me we could get the same reduced latency benefits by piggybacking on ICE
rather than SDP, e.g. embedding the DTLS packet as data in a new STUN attribute type.

Piggybacking in ICE means that you have to repeat it in every probe packet, since you don't know which is going to make it through.

And you can't start ICE probing until the handshake has completed.

--------------040307010908010001010300-- From nobody Mon Apr 4 19:07:18 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 5F3A512D60A for ; Mon, 4 Apr 2016 19:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhOCXf_BvXQr for ; Mon, 4 Apr 2016 19:07:12 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 925D212D5B3 for ; Mon, 4 Apr 2016 19:07:11 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id n3so2355119wmn.0 for ; Mon, 04 Apr 2016 19:07:11 -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=xyEz6gUQBQ+N4cC4fJPTd6mk1X/SkDxtCgtsYYLLJt8=; b=pp2XiFi0qojdr7/hNDY6aQUy0R6xcIMmgsOF9xUaJ4jG3EbEFTzTSM+E5SQWLlWMkh wKOL+i4PuHysmeSaGG5HicLoWHsd1mBQzGsteltZq2p4D6qRNudBR4QfiDeYW/vH4H90 b3mbn3aK0zIMVUILE0XxYb3+ZPHMPs7fIMDrlEDwSjv5TvILXHsY2pY8LF5n3M4Dh3wi FAgQ+RBmsLUsCMJBOxbHjW9F4sPzR6MoA9+21LqK+AZquNuhFGGazsc7W8/FmdwLh1JF 4aZQ4Obd93xDVI4CubJ0m9Efpgp26i8+xqvCzz3lX500PbrEh10frplGj/bT6okxmN24 brjw== 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=xyEz6gUQBQ+N4cC4fJPTd6mk1X/SkDxtCgtsYYLLJt8=; b=F8MBskjkkYWN/vwi3DTILANaMvJmRiFPAB5DhJfqtbG0CRfhy86KW46wRovivwrcHS lqf1InpPXpt8t4xdPRwuyB0x3QPgJnfeU5VL3evgO4um3AC4OxdVWhOMN0ru5LGXxJHR nTRS2c9MQLAh0lJMI2FjPY+2sQOhwpdl+0cqYpeU4d9cn+ieMy4O624VgPFGPOCBV7E6 pfh5gGhk9gD9hCowe9FbJsaxvAh3waNHuyBV3+KfbRFAkhm/F6vGKdb8umDk7H7XJkJu WgcuXRgDjtmo/by8OPYw4Zz6eXmpoTX1oyNBOcjJF8hQXGhsT/4LdHyhT47pyY5VlpKK t3fw== X-Gm-Message-State: AD7BkJKoMHCBtqw26iEi8HH2SUf/yMNGHw18uGEy6pizy/h94kJ8MgcuvkL7yKTM92fSlI8QRNzSNhbH5MY9Dmjy X-Received: by 10.194.184.234 with SMTP id ex10mr20203229wjc.8.1459822029993; Mon, 04 Apr 2016 19:07:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.148.79 with HTTP; Mon, 4 Apr 2016 19:06:50 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Mon, 4 Apr 2016 19:06:50 -0700 Message-ID: To: pfh Content-Type: multipart/alternative; boundary=047d7b86cc1e88d08e052fb34d33 Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [rtcweb] Tunnelling DTLS in SDP 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, 05 Apr 2016 02:07:15 -0000 --047d7b86cc1e88d08e052fb34d33 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 4, 2016 at 8:39 AM, pfh wrote: > > On 4 Apr 2016, at 14:10, Eric Rescorla wrote: > > Hi folks, > > I wanted to call your attention to a draft I just published with a > possibly stupid > idea. > > https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 > > A nontrivial fraction of call setup time in WebRTC is the DTLS handshake. > This document describes how to piggyback the first few handshake messages > in the SDP offer/answer exchange, thus reducing latency. > > > It strikes me we could get the same reduced latency benefits by > piggybacking on ICE > rather than SDP, e.g. embedding the DTLS packet as data in a new STUN > attribute type. > > The downside of piggybacking on the SDP is that you are increasing the > trust you have to place in the > signalling server undermining the elegant decoupling we have at the moment > between signalling and > media. (The SDES issues of logging keys in the web servers apply to the > public certs as well). > I don't think the logging issue applies here. Only the public key would be logged, and it's already transmitted in cleartext during a normal DTLS handshake (it's a public key, after all). > > It also significantly clutters the SDP (even more) ! > Please see Jonathan Lennox's comment about garbage piles. I think the only truly unattractive part here is the fact that the messages will need to be base64ed, resulting in minor blowup. But that seems like a reasonable downside for 1+ RTT upside. > As you point out, it weakens the usefulness of longer term certs, which > would be a major nuisance IMHO. > > Tim. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b86cc1e88d08e052fb34d33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 4, 2016 at 8:39 AM, pfh <tim@phonefromhere.com>= wrote:

On 4 Apr= 2016, at 14:10, Eric Rescorla <ekr@rtfm.com> wrote:

Hi f= olks,

I wanted to call your attention to a draft I just = published with a possibly stupid
idea.

<= a href=3D"https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00" target= =3D"_blank">https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00

A nontrivial fraction of call setup time in Web= RTC is the DTLS handshake.
This document describes how to piggyba= ck the first few handshake messages
in the SDP offer/answer excha= nge, thus reducing latency.

It strikes me we could get the same reduced latency benefits by p= iggybacking on ICE
rather than SDP, e.g. embedding the DTLS packe= t as data in a new STUN attribute type.

The downsi= de of piggybacking on the SDP is that you are increasing the trust you have= to place in the
signalling server undermining the elegant decoup= ling we have at the moment between signalling and=C2=A0
media. (T= he SDES issues of logging keys in the web servers apply to the public certs= as well).

I don't th= ink the logging issue applies here. Only the public key would be logged, an= d it's already transmitted in cleartext during a normal DTLS handshake = (it's a public key, after all).=C2=A0

It also sig= nificantly clutters the SDP (even more) !

Please see Jonathan Lennox's comment about garbage pil= es. I think the only truly unattractive part here is the fact that the mess= ages will need to be base64ed, resulting in minor blowup. But that seems li= ke a reasonable downside for 1+ RTT upside.


As you point out, it weakens the usefulness of longer term certs, whi= ch
would be a major nuisance IMHO.

Tim.<= /div>


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


--047d7b86cc1e88d08e052fb34d33-- From nobody Mon Apr 4 19:09:01 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 15EB012D5B3 for ; Mon, 4 Apr 2016 19:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 7d3-Lzn8mk_8 for ; Mon, 4 Apr 2016 19:08:58 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F39AA12D60A for ; Mon, 4 Apr 2016 19:08:52 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id 127so8766344wmu.1 for ; Mon, 04 Apr 2016 19:08:52 -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=A/UAkNVOhlf027c6k1WFheSBY2oifb3PGnH2ttKGfkg=; b=TZVFgTzNKXa/G8wCbFmsv7QJz3gdsa/FCoBFYOQlRNaFD4lI/barUbkr0ajqQat77i 5NqG2ydVPoWudzu4ckKbSVAgMeUfQ8gfxkSQukdiuKEWq9C3RcOiDUL134c0Ya3TBbmF EVt752gVh0HR6lpBISV4wv1fEnlgC44lHoMKlXTXj0daIJvKxBHM3JxMxkn8UvIzyxEl HlePjQcJ8rJTY2zVDKup9t4n8BuIdatAoJxZwto2I2Tnlsd93O2hRcJkN19Dxw6ZTRgI yl2ATdwwsSdtiop2vFt/fs8pz2BS1WHZixaAcc4+sv44GhLC9taijDb3FP5dXnNuB6in o/aw== 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=A/UAkNVOhlf027c6k1WFheSBY2oifb3PGnH2ttKGfkg=; b=EKUTVJwlFUhhyjC2LKM/Bw32d8qVzekkp00mLtcOnN2N8M1xXx/LvtJIkP4bJhd6Qy rV5VL3tWJok1F5sr+O8NJn0DFUTmBjQ06lZw1cZDHBFM4x5LAzR5EnmZ8fKyqRgt25Uq 8btAqa0ExRoFqUoPJqqWVsfLqS48N50GCgQwN56DvQtFLq3DfQhY2Ys0ihxTvZS9a9CW yyUs8Qs8FTh8/c2/Imm6v8tODpMa0KnFrNr2P0JNnKepBofrKrg1/VoddQrAO8jn2NPH FJ31CN+B5KItIB5ZXbZ0jWAotLeVpNgYfIl8WlDCZS+mWNSMSfU8F837iHrOU4vrtZ5s GTzg== X-Gm-Message-State: AD7BkJIFNE80vItuZOFOocYEHlrUO+omkAZgdiCSgorPEOhVlyqnqjdRvR6RX8pCEaGVOYGUUkZ+9cGWYuqTMPni X-Received: by 10.194.78.129 with SMTP id b1mr20738813wjx.60.1459822131443; Mon, 04 Apr 2016 19:08:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.148.79 with HTTP; Mon, 4 Apr 2016 19:08:31 -0700 (PDT) In-Reply-To: <57004D0F.70300@alvestrand.no> References: <57004D0F.70300@alvestrand.no> From: Justin Uberti Date: Mon, 4 Apr 2016 19:08:31 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=047d7bd9172494d042052fb35319 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Positioning draft-ietf-rtcweb-ip-address as a standards-track document 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, 05 Apr 2016 02:09:00 -0000 --047d7bd9172494d042052fb35319 Content-Type: text/plain; charset=UTF-8 Thanks for the concrete feedback. I agree with the proposed direction. On Sat, Apr 2, 2016 at 3:51 PM, Harald Alvestrand wrote: > I've read through draft-ietf-rtcweb-ip-address again, with an eye to > seeing how it would read as a standards-track document. > > As such, it seems to me to provide rather tentative language in a few > places, which could be strengthened by use of the CAPITALIZED WORDS. > I think this is a Good Thing; if this is standards-track, with > imperative, normative language, an implementation can claim support for > RFC XXXX and expect the statement to be understood. > (Remember - there is no protocol police. Nothing forces people to > support RFC XXXX.) > > Changes needed: > > - Add the RFC 2119 incantation, including Stefan's addition ("lowercase > words mean what they usually do") > > - Replace all occurences of "We recommend that..." with "an > implementation MUST". > > - In section 3, end of first paragraph: " Specifically, WebRTC > should:" -> "Implementations of this specification will:" > > - In section 4: "We recommend Mode 1 ... " -> "Mode 1 and mode 2 MUST be > supported. Mode 1 SHOULD be the default when the user has not granted > access to camera / microphone. Mode 2 SHOULD be the default when the > user has granted access to camera / microphone. The implementation MAY > provide means of letting the user or administrator select between modes. > These means MUST NOT be placed under the control of WebRTC applications." > > I think this would make the spec a more useful tool for specifying what > an application does. > > > > -- > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7bd9172494d042052fb35319 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the concrete feedback. I agree with the propose= d direction.

On Sat, Apr 2, 2016 at 3:51 PM, Harald Alvestrand <harald@alvestrand.n= o> wrote:
I've read thr= ough draft-ietf-rtcweb-ip-address again, with an eye to
seeing how it would read as a standards-track document.

As such, it seems to me to provide rather tentative language in a few
places, which could be strengthened by use of the CAPITALIZED WORDS.
I think this is a Good Thing; if this is standards-track, with
imperative, normative language, an implementation can claim support for
RFC XXXX and expect the statement to be understood.
(Remember - there is no protocol police. Nothing forces people to
support RFC XXXX.)

Changes needed:

- Add the RFC 2119 incantation, including Stefan's addition ("lowe= rcase
words mean what they usually do")

- Replace all occurences of "We recommend that..." with "an<= br> implementation MUST".

- In section 3, end of first paragraph: "=C2=A0 =C2=A0Specifically, We= bRTC
should:" -> "Implementations of this specification will:"=

- In section 4: "We recommend Mode 1 ... " -> "Mode 1 and= mode 2 MUST be
supported. Mode 1 SHOULD be the default when the user has not granted
access to camera / microphone. Mode 2 SHOULD be the default when the
user has granted access to camera / microphone. The implementation MAY
provide means of letting the user or administrator select between modes. These means MUST NOT be placed under the control of WebRTC applications.&qu= ot;

I think this would make the spec a more useful tool for specifying what
an application does.



--
Surveillance is pervasive. Go Dark.


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

--047d7bd9172494d042052fb35319-- From nobody Mon Apr 4 20:41: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 6DB5612D0FD; Mon, 4 Apr 2016 20:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTC7yeCSWQUQ; Mon, 4 Apr 2016 20:41:43 -0700 (PDT) Received: from mail.eeph.com (mail.eeph.com [192.135.198.155]) by ietfa.amsl.com (Postfix) with ESMTP id 31EAB12D648; Mon, 4 Apr 2016 20:34:42 -0700 (PDT) Received: from [10.10.155.209] (unknown [10.10.155.209]) (Authenticated sender: matthew@eeph.com) by mail.eeph.com (Postfix) with ESMTPSA id 185DE5C73E8; Mon, 4 Apr 2016 20:34:42 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-3EBB4CF7-A937-4D7B-B1B4-9F27D17AEBAA Mime-Version: 1.0 (1.0) From: Matthew Kaufman X-Mailer: iPhone Mail (13E234) In-Reply-To: Date: Mon, 4 Apr 2016 20:34:41 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: pfh Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [rtcweb] [MMUSIC] Tunnelling DTLS in SDP 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, 05 Apr 2016 03:41:44 -0000 --Apple-Mail-3EBB4CF7-A937-4D7B-B1B4-9F27D17AEBAA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable As someone who designed a protocol that overlaps NAT traversal / consent and= key agreement, I agree that putting it in the ICE exchange would be benefic= ial. Matthew Kaufman (Sent from my iPhone) > On Apr 4, 2016, at 8:39 AM, pfh wrote: >=20 >=20 >> On 4 Apr 2016, at 14:10, Eric Rescorla wrote: >>=20 >> Hi folks, >>=20 >> I wanted to call your attention to a draft I just published with a possib= ly stupid >> idea. >>=20 >> https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 >>=20 >> A nontrivial fraction of call setup time in WebRTC is the DTLS handshake.= >> This document describes how to piggyback the first few handshake messages= >> in the SDP offer/answer exchange, thus reducing latency. >=20 > It strikes me we could get the same reduced latency benefits by piggybacki= ng on ICE > rather than SDP, e.g. embedding the DTLS packet as data in a new STUN attr= ibute type. >=20 > The downside of piggybacking on the SDP is that you are increasing the tru= st you have to place in the > signalling server undermining the elegant decoupling we have at the moment= between signalling and=20 > media. (The SDES issues of logging keys in the web servers apply to the pu= blic certs as well). >=20 > It also significantly clutters the SDP (even more) ! >=20 > As you point out, it weakens the usefulness of longer term certs, which > would be a major nuisance IMHO. >=20 > Tim. >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --Apple-Mail-3EBB4CF7-A937-4D7B-B1B4-9F27D17AEBAA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
As someone who designed a protocol tha= t overlaps NAT traversal / consent and key agreement, I agree that putting i= t in the ICE exchange would be beneficial.

Matthew Kaufman

(S= ent from my iPhone)

On Apr 4, 2016, at 8:39 AM, pfh <= tim@phonefromhere.com> wrote= :


On 4 Apr 2016, at 14:10, Eric Resc= orla <ekr@rtfm.com> wro= te:

Hi folks,

I wanted to call your attention to a draft I just published with a possib= ly stupid
idea.

https://tools.ietf.org/html/draft-rescorla-dtls-in-s= dp-00

A nontrivial fraction of call setup time in WebRTC is the DTLS handsh= ake.
This document describes how to piggyback the first= few handshake messages
in the SDP offer/answer exchang= e, thus reducing latency.

=
It strikes me we could get the same reduced latency benefits by p= iggybacking on ICE
rather than SDP, e.g. embedding the DTLS packet= as data in a new STUN attribute type.

T= he downside of piggybacking on the SDP is that you are increasing the trust y= ou have to place in the
signalling server undermining the elegant d= ecoupling we have at the moment between signalling and 
media= . (The SDES issues of logging keys in the web servers apply to the public ce= rts as well).

It also significantly clut= ters the SDP (even more) !

As you point o= ut, it weakens the usefulness of longer term certs, which
would be= a major nuisance IMHO.

Tim.
=
_____= __________________________________________
mmusic mailing li= st
mmusic@ietf.org
https= ://www.ietf.org/mailman/listinfo/mmusic
= --Apple-Mail-3EBB4CF7-A937-4D7B-B1B4-9F27D17AEBAA-- From nobody Tue Apr 5 02:52:18 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 4052D12D10B for ; Tue, 5 Apr 2016 02:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKqJDZM2bR_F for ; Tue, 5 Apr 2016 02:52:12 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1267D12D0A5 for ; Tue, 5 Apr 2016 02:52:11 -0700 (PDT) Received: (qmail 54324 invoked from network); 5 Apr 2016 09:52:10 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 3177 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 5 Apr 2016 09:52:10 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id 014B418A00F5; Tue, 5 Apr 2016 10:52:10 +0100 (BST) Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id E464A18A0727; Tue, 5 Apr 2016 10:52:09 +0100 (BST) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id BE15518A00F5; Tue, 5 Apr 2016 10:52:09 +0100 (BST) Content-Type: multipart/alternative; boundary="Apple-Mail=_73971B90-CF02-43F3-83D4-3475486FCF6D" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Tim Panton In-Reply-To: Date: Tue, 5 Apr 2016 10:52:09 +0100 Message-Id: References: To: Justin Uberti X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [rtcweb] Tunnelling DTLS in SDP 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, 05 Apr 2016 09:52:15 -0000 --Apple-Mail=_73971B90-CF02-43F3-83D4-3475486FCF6D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 5 Apr 2016, at 03:06, Justin Uberti wrote: >=20 >=20 >=20 > On Mon, Apr 4, 2016 at 8:39 AM, pfh > wrote: >=20 >> On 4 Apr 2016, at 14:10, Eric Rescorla > wrote: >>=20 >> Hi folks, >>=20 >> I wanted to call your attention to a draft I just published with a = possibly stupid >> idea. >>=20 >> https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 = >>=20 >> A nontrivial fraction of call setup time in WebRTC is the DTLS = handshake. >> This document describes how to piggyback the first few handshake = messages >> in the SDP offer/answer exchange, thus reducing latency. >=20 > It strikes me we could get the same reduced latency benefits by = piggybacking on ICE > rather than SDP, e.g. embedding the DTLS packet as data in a new STUN = attribute type. >=20 > The downside of piggybacking on the SDP is that you are increasing the = trust you have to place in the > signalling server undermining the elegant decoupling we have at the = moment between signalling and=20 > media. (The SDES issues of logging keys in the web servers apply to = the public certs as well). >=20 > I don't think the logging issue applies here. Only the public key = would be logged, and it's already transmitted in cleartext during a = normal DTLS handshake (it's a public key, after all).=20 True, but over a different path.=20 >=20 > It also significantly clutters the SDP (even more) ! >=20 > Please see Jonathan Lennox's comment about garbage piles. I think the = only truly unattractive part here is the fact that the messages will = need to be base64ed, resulting in minor blowup. But that seems like a = reasonable downside for 1+ RTT upside. Just when the WebRTC NG was freeing us from Offer/Answer and SDP=E2=80=A6.= Sigh. >=20 >=20 > As you point out, it weakens the usefulness of longer term certs, = which > would be a major nuisance IMHO. >=20 > Tim. >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = >=20 >=20 --Apple-Mail=_73971B90-CF02-43F3-83D4-3475486FCF6D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 5 Apr 2016, at 03:06, Justin Uberti <juberti@google.com> = wrote:



On Mon, Apr 4, 2016 at 8:39 AM, = pfh <tim@phonefromhere.com> wrote:

On 4 Apr 2016, at 14:10, Eric Rescorla <ekr@rtfm.com> wrote:

Hi folks,

I wanted to call your attention to a = draft I just published with a possibly stupid
idea.

https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00

A = nontrivial fraction of call setup time in WebRTC is the DTLS = handshake.
This document describes how to piggyback = the first few handshake messages
in the SDP = offer/answer exchange, thus reducing = latency.

It strikes me we could get the = same reduced latency benefits by piggybacking on ICE
rather than SDP, e.g. embedding the DTLS packet as data in a = new STUN attribute type.

The downside of piggybacking on the SDP is that you are = increasing the trust you have to place in the
signalling server undermining the elegant decoupling we have = at the moment between signalling and 
media. = (The SDES issues of logging keys in the web servers apply to the public = certs as well).

I don't think the logging issue applies = here. Only the public key would be logged, and it's already transmitted = in cleartext during a normal DTLS handshake (it's a public key, after = all). 

True, but over a different path. 


It also significantly = clutters the SDP (even more) !

Please see Jonathan = Lennox's comment about garbage piles. I think the only truly = unattractive part here is the fact that the messages will need to be = base64ed, resulting in minor blowup. But that seems like a reasonable = downside for 1+ RTT = upside.

Just when the WebRTC NG was freeing us from = Offer/Answer and SDP=E2=80=A6.

Sigh.




As you point out, it weakens the usefulness of longer term = certs, which
would be a major nuisance = IMHO.

Tim.


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


= --Apple-Mail=_73971B90-CF02-43F3-83D4-3475486FCF6D-- From nobody Tue Apr 5 02:54:11 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 6B49912D140 for ; Tue, 5 Apr 2016 02:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7BYXRuPP9BX for ; Tue, 5 Apr 2016 02:54:06 -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 721A512D17F for ; Tue, 5 Apr 2016 02:54:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id B3E627C7C0B for ; Tue, 5 Apr 2016 11:54:04 +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 RGVX8vbnH0Zp for ; Tue, 5 Apr 2016 11:54:03 +0200 (CEST) Received: from [IPv6:2001:67c:370:136:2154:8066:f6ed:c7f7] (unknown [IPv6:2001:67c:370:136:2154:8066:f6ed:c7f7]) by mork.alvestrand.no (Postfix) with ESMTPSA id 23A1A7C7C03 for ; Tue, 5 Apr 2016 11:54:02 +0200 (CEST) To: rtcweb@ietf.org References: From: Harald Alvestrand Message-ID: <57038B35.8040102@alvestrand.no> Date: Tue, 5 Apr 2016 11:53:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000008020101080200000803" Archived-At: Subject: Re: [rtcweb] Tunnelling DTLS in SDP 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, 05 Apr 2016 09:54:09 -0000 This is a multi-part message in MIME format. --------------000008020101080200000803 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On first read, this makes sense to me. I wonder if it could/should be made into a general concept, to fit with the tendency in WebRTC:NG to separate signalling format even more from operation? We could call it "out of band DTLS setup", say that in general, a DTLS session can be started in one medium (SDP signalling, in this case), and continued in another medium (the DTLS-protected media channel), and have a section describing the details of carrying DTLS-over-SDP. When viewing it in this way, using the same technique with Jabber or proprietary signalling becomes a reasonably obvious exercise. There are some other twists that seem obvious too - for instance, one could continue the setup over the SDP channel in subsequent offer/answers if the first exchange failed to set up a media channel. I'm not sure that makes sense, though. One SDP twist: If forking happens, it could be treated like any other attempt to generate multiple answers to a ClientHello, I think. I'm sure it's well defined how to respond to that - it's an obvious attack. Only one leg of the fork would ever succeed, I assume. On 04/04/2016 03:10 PM, Eric Rescorla wrote: > Hi folks, > > I wanted to call your attention to a draft I just published with a > possibly stupid > idea. > > https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 > > A nontrivial fraction of call setup time in WebRTC is the DTLS handshak= e. > This document describes how to piggyback the first few handshake messag= es > in the SDP offer/answer exchange, thus reducing latency. > > Comments welcome. > > -Ekr > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Surveillance is pervasive. Go Dark. --------------000008020101080200000803 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On first read, this makes sense to me.

I wonder if it could/should be made into a general concept, to fit with the tendency in WebRTC:NG to separate signalling format even more from operation?

We could call it "out of band DTLS setup", say that in general, a DTLS session can be started in one medium (SDP signalling, in this case), and continued in another medium (the DTLS-protected media channel), and have a section describing the details of carrying DTLS-over-SDP.

When viewing it in this way, using the same technique with Jabber or proprietary signalling becomes a reasonably obvious exercise. There are some other twists that seem obvious too - for instance, one could continue the setup over the SDP channel in subsequent offer/answers if the first exchange failed to set up a media channel. I'm not sure that makes sense, though.

One SDP twist: If forking happens, it could be treated like any other attempt to generate multiple answers to a ClientHello, I think. I'm sure it's well defined how to respond to that - it's an obvious attack. Only one leg of the fork would ever succeed, I assume.


On 04/04/2016 03:10 PM, Eric Rescorla wrote:
Hi folks,

I wanted to call your attention to a draft I just published with a possibly stupid
idea.


A nontrivial fraction of call setup time in WebRTC is the DTLS handshake.
This document describes how to piggyback the first few handshake messages
in the SDP offer/answer exchange, thus reducing latency.

Comments welcome.

-Ekr





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



-- 
Surveillance is pervasive. Go Dark.
--------------000008020101080200000803-- From nobody Tue Apr 5 02:58: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 04F3712D1A0 for ; Tue, 5 Apr 2016 02:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 2uOUOzdONV1D for ; Tue, 5 Apr 2016 02:58:27 -0700 (PDT) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4CA12D0B9 for ; Tue, 5 Apr 2016 02:58:26 -0700 (PDT) Received: (qmail 62245 invoked from network); 5 Apr 2016 09:58:25 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 3303 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 5 Apr 2016 09:58:25 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id EFE1018A0666; Tue, 5 Apr 2016 10:58:24 +0100 (BST) Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id E281218A046D; Tue, 5 Apr 2016 10:58:24 +0100 (BST) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id C528218A046C; Tue, 5 Apr 2016 10:58:24 +0100 (BST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Tim Panton In-Reply-To: Date: Tue, 5 Apr 2016 10:58:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <82A90D4E-4793-4A21-BB7D-CE3594D55AF6@phonefromhere.com> References: To: Martin Thomson X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [rtcweb] Tunnelling DTLS in SDP 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, 05 Apr 2016 09:58:29 -0000 > On 4 Apr 2016, at 18:34, Martin Thomson = wrote: >=20 > On 4 April 2016 at 12:39, pfh wrote: >> It strikes me we could get the same reduced latency benefits by = piggybacking >> on ICE >> rather than SDP, e.g. embedding the DTLS packet as data in a new STUN >> attribute type. >=20 > One of the goals for connectivity checks is to keep them small. > Cramming DTLS in is not compatible with this. It wouldn=E2=80=99t be in every ICE packet, just in ones with (say) = USE-CANDIDATE set. T. From nobody Tue Apr 5 03:04:28 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 8349412D147 for ; Tue, 5 Apr 2016 03:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 hud_UFk6Wtq9 for ; Tue, 5 Apr 2016 03:04:23 -0700 (PDT) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E830612D10B for ; Tue, 5 Apr 2016 03:04:22 -0700 (PDT) Received: (qmail 67736 invoked from network); 5 Apr 2016 10:04:21 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 3463 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 5 Apr 2016 10:04:21 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id 443EC18A046C; Tue, 5 Apr 2016 11:04:21 +0100 (BST) Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id 3335618A0666; Tue, 5 Apr 2016 11:04:21 +0100 (BST) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 1B04218A046C; Tue, 5 Apr 2016 11:04:21 +0100 (BST) Content-Type: multipart/alternative; boundary="Apple-Mail=_1E03C29F-4D8E-4510-BB0D-F2090A025C05" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Tim Panton In-Reply-To: <57038B35.8040102@alvestrand.no> Date: Tue, 5 Apr 2016 11:04:20 +0100 Message-Id: References: <57038B35.8040102@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.2104) Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Tunnelling DTLS in SDP 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, 05 Apr 2016 10:04:26 -0000 --Apple-Mail=_1E03C29F-4D8E-4510-BB0D-F2090A025C05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On 5 Apr 2016, at 10:53, Harald Alvestrand > wrote: >=20 > On first read, this makes sense to me. >=20 > I wonder if it could/should be made into a general concept, to fit = with the tendency in WebRTC:NG to separate signalling format even more = from operation? >=20 > We could call it "out of band DTLS setup", say that in general, a DTLS = session can be started in one medium (SDP signalling, in this case), and = continued in another medium (the DTLS-protected media channel), and have = a section describing the details of carrying DTLS-over-SDP. >=20 > When viewing it in this way, using the same technique with Jabber or = proprietary signalling becomes a reasonably obvious exercise. There are = some other twists that seem obvious too - for instance, one could = continue the setup over the SDP channel in subsequent offer/answers if = the first exchange failed to set up a media channel. I'm not sure that = makes sense, though. >=20 > One SDP twist: If forking happens, it could be treated like any other = attempt to generate multiple answers to a ClientHello, I think. I'm sure = it's well defined how to respond to that - it's an obvious attack. Only = one leg of the fork would ever succeed, I assume. Doesn=92t passing the DTLS Hellos through javascript open us to a whole = pile of bid-down attacks where the lists of supported crypto suites and extensions are manipulated in = the js ? E.G It might allow the javascript to insert=20 the magic extension that says "this isn=92t being recorded=94 without = the browser actually being in that mode.=20 Or is there a way that DTLS can detect this ? T. >=20 >=20 > On 04/04/2016 03:10 PM, Eric Rescorla wrote: >> Hi folks, >>=20 >> I wanted to call your attention to a draft I just published with a = possibly stupid >> idea. >>=20 >> https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 = >>=20 >> A nontrivial fraction of call setup time in WebRTC is the DTLS = handshake. >> This document describes how to piggyback the first few handshake = messages >> in the SDP offer/answer exchange, thus reducing latency. >>=20 >> Comments welcome. >>=20 >> -Ekr >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb = >=20 >=20 > --=20 > Surveillance is pervasive. Go Dark. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk --Apple-Mail=_1E03C29F-4D8E-4510-BB0D-F2090A025C05 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 5 Apr = 2016, at 10:53, Harald Alvestrand <harald@alvestrand.no> wrote:

=20 =20
On first read, this makes sense to = me.

I wonder if it could/should be made into a general concept, to fit with the tendency in WebRTC:NG to separate signalling format even more from operation?

We could call it "out of band DTLS setup", say that in general, a DTLS session can be started in one medium (SDP signalling, in this case), and continued in another medium (the DTLS-protected media channel), and have a section describing the details of carrying DTLS-over-SDP.

When viewing it in this way, using the same technique with Jabber or proprietary signalling becomes a reasonably obvious exercise. There are some other twists that seem obvious too - for instance, one could continue the setup over the SDP channel in subsequent offer/answers if the first exchange failed to set up a media channel. I'm not sure that makes sense, though.

One SDP twist: If forking happens, it could be treated like any other attempt to generate multiple answers to a ClientHello, I think. I'm sure it's well defined how to respond to that - it's an obvious attack. Only one leg of the fork would ever succeed, I assume.

Doesn=92t passing the = DTLS Hellos through javascript open us to a whole pile of bid-down = attacks where
the lists of supported crypto suites = and extensions are manipulated in the js ? E.G It  might allow the = javascript to insert 
the magic extension that = says "this isn=92t being recorded=94  without the browser actually = being in that mode. 
Or is there a way that = DTLS can detect this ?

T.





On 04/04/2016 03:10 PM, Eric Rescorla wrote:
Hi folks,

I wanted to call your attention to a draft I = just published with a possibly stupid
idea.

https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00

A nontrivial fraction of call setup time in = WebRTC is the DTLS handshake.
This document describes how to piggyback the = first few handshake messages
in the SDP offer/answer exchange, thus reducing = latency.

Comments welcome.

-Ekr





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



--=20
Surveillance is pervasive. Go Dark.
_______________________________________________
rtcweb = mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

Tim Panton - = Web/VoIP consultant and implementor
www.westhawk.co.uk



= --Apple-Mail=_1E03C29F-4D8E-4510-BB0D-F2090A025C05-- From nobody Tue Apr 5 03:18: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 E9C1A12D651 for ; Tue, 5 Apr 2016 03:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPI5t8bsQR4g for ; Tue, 5 Apr 2016 03:18:29 -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 4916412D5B9 for ; Tue, 5 Apr 2016 03:18:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id C9B097C7C0B; Tue, 5 Apr 2016 12:18:27 +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 fBfu8yJ13JmQ; Tue, 5 Apr 2016 12:18:26 +0200 (CEST) Received: from [IPv6:2001:67c:370:136:2154:8066:f6ed:c7f7] (unknown [IPv6:2001:67c:370:136:2154:8066:f6ed:c7f7]) by mork.alvestrand.no (Postfix) with ESMTPSA id 0AFB07C76C8; Tue, 5 Apr 2016 12:18:24 +0200 (CEST) To: Tim Panton References: <57038B35.8040102@alvestrand.no> From: Harald Alvestrand Message-ID: <570390ED.8080109@alvestrand.no> Date: Tue, 5 Apr 2016 12:18:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------030401020809000303050907" Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Tunnelling DTLS in SDP 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, 05 Apr 2016 10:18:32 -0000 This is a multi-part message in MIME format. --------------030401020809000303050907 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 04/05/2016 12:04 PM, Tim Panton wrote: > >> On 5 Apr 2016, at 10:53, Harald Alvestrand > > wrote: >> >> On first read, this makes sense to me. >> >> I wonder if it could/should be made into a general concept, to fit >> with the tendency in WebRTC:NG to separate signalling format even >> more from operation? >> >> We could call it "out of band DTLS setup", say that in general, a >> DTLS session can be started in one medium (SDP signalling, in this >> case), and continued in another medium (the DTLS-protected media >> channel), and have a section describing the details of carrying >> DTLS-over-SDP. >> >> When viewing it in this way, using the same technique with Jabber or >> proprietary signalling becomes a reasonably obvious exercise. There >> are some other twists that seem obvious too - for instance, one could >> continue the setup over the SDP channel in subsequent offer/answers >> if the first exchange failed to set up a media channel. I'm not sure >> that makes sense, though. >> >> One SDP twist: If forking happens, it could be treated like any other >> attempt to generate multiple answers to a ClientHello, I think. I'm >> sure it's well defined how to respond to that - it's an obvious >> attack. Only one leg of the fork would ever succeed, I assume. > > Doesn’t passing the DTLS Hellos through javascript open us to a whole > pile of bid-down attacks where > the lists of supported crypto suites and extensions are manipulated in > the js ? E.G It might allow the javascript to insert > the magic extension that says "this isn’t being recorded” without the > browser actually being in that mode. > Or is there a way that DTLS can detect this ? It certainly reduces the setup security from one where only network on-path attackers can do MITM attacks on the handshake to one where everyone with access to the Javascript can do MITM attacks on the handshake. Given that DTLS is supposed to be a reasonable option when you have on-path attackers on the network path, I certainly hope the defenses are adequate in this case too, but I don't know DTLS well enough to be able to say what those defenses are. > > T. > > > >> >> >> On 04/04/2016 03:10 PM, Eric Rescorla wrote: >>> Hi folks, >>> >>> I wanted to call your attention to a draft I just published with a >>> possibly stupid >>> idea. >>> >>> https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 >>> >>> A nontrivial fraction of call setup time in WebRTC is the DTLS >>> handshake. >>> This document describes how to piggyback the first few handshake >>> messages >>> in the SDP offer/answer exchange, thus reducing latency. >>> >>> Comments welcome. >>> >>> -Ekr >>> >>> >>> >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> -- >> Surveillance is pervasive. Go Dark. >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > Tim Panton - Web/VoIP consultant and implementor > www.westhawk.co.uk > > > -- Surveillance is pervasive. Go Dark. --------------030401020809000303050907 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 04/05/2016 12:04 PM, Tim Panton wrote:

On 5 Apr 2016, at 10:53, Harald Alvestrand <harald@alvestrand.no> wrote:

On first read, this makes sense to me.

I wonder if it could/should be made into a general concept, to fit with the tendency in WebRTC:NG to separate signalling format even more from operation?

We could call it "out of band DTLS setup", say that in general, a DTLS session can be started in one medium (SDP signalling, in this case), and continued in another medium (the DTLS-protected media channel), and have a section describing the details of carrying DTLS-over-SDP.

When viewing it in this way, using the same technique with Jabber or proprietary signalling becomes a reasonably obvious exercise. There are some other twists that seem obvious too - for instance, one could continue the setup over the SDP channel in subsequent offer/answers if the first exchange failed to set up a media channel. I'm not sure that makes sense, though.

One SDP twist: If forking happens, it could be treated like any other attempt to generate multiple answers to a ClientHello, I think. I'm sure it's well defined how to respond to that - it's an obvious attack. Only one leg of the fork would ever succeed, I assume.

Doesn’t passing the DTLS Hellos through javascript open us to a whole pile of bid-down attacks where
the lists of supported crypto suites and extensions are manipulated in the js ? E.G It  might allow the javascript to insert 
the magic extension that says "this isn’t being recorded”  without the browser actually being in that mode. 
Or is there a way that DTLS can detect this ?

It certainly reduces the setup security from one where only network on-path attackers can do MITM attacks on the handshake to one where everyone with access to the Javascript can do MITM attacks on the handshake.

Given that DTLS is supposed to be a reasonable option when you have on-path attackers on the network path, I certainly hope the defenses are adequate in this case too, but I don't know DTLS well enough to be able to say what those defenses are.


T.





On 04/04/2016 03:10 PM, Eric Rescorla wrote:
Hi folks,

I wanted to call your attention to a draft I just published with a possibly stupid
idea.


A nontrivial fraction of call setup time in WebRTC is the DTLS handshake.
This document describes how to piggyback the first few handshake messages
in the SDP offer/answer exchange, thus reducing latency.

Comments welcome.

-Ekr





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



-- 
Surveillance is pervasive. Go Dark.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

Tim Panton - Web/VoIP consultant and implementor





-- 
Surveillance is pervasive. Go Dark.
--------------030401020809000303050907-- From nobody Tue Apr 5 05:32: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 3992012D16B for ; Tue, 5 Apr 2016 05:32:46 -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 WwBn6JkkaFDC for ; Tue, 5 Apr 2016 05:32:44 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2C712D096 for ; Tue, 5 Apr 2016 05:32:44 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id q128so16690226iof.3 for ; Tue, 05 Apr 2016 05:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=87O0hTLtfXVSDfCn+rLTs0PC0A49yCYA/+XaZK+MyHQ=; b=sZu8K+ooPQpY+WuiRFmaIyt0WIgxJJX+bR1gXr5f/W3SY3t9TFmoAVx8XwrnqpzbrQ TA+X6ciyXlttX/mbXUxx8SBbYObk1m4pstEps0QpN3ry/Apc4dL6UPrVQqOiU8+wSrOE UMYaJAUiuCL4X6352ZV3IiBX49m8aESbu07LQr2DpGjZlfyUSke93T+w4DCae6u0aiGS Azz6zouGk3pfTjpb1c4Oz5s5xf8exw4WLcluzdaiiZ/k3VbMlNllexqfrMpYBOhoM4b8 xXcTF+BeevPWHCNlwYm/gSJDoisrUqHINlfj3aYKHblyToeVPG4+qHe1JBCpmViI1wFe aU+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=87O0hTLtfXVSDfCn+rLTs0PC0A49yCYA/+XaZK+MyHQ=; b=SUiWcLhCv+DTNlOCkGCrQFmtASO4OeEyqlqA+xFvk3TKfTRNKiXqJzWbrMxTkfjNCf ftTP5YvYQzFMPDejZTOuqk3gFD34zPPslwQVNwieoRw/0UBHXqxvZdZlDIEkEmf8y5oa d8Yp5Y59BI+u1ObFuzeYYe1txcCrQd5yVxXAeNF8t6nxL+sVp2bucHiq0ZiT9MBo9V4j 5s5QNKgGZj+X2wLIrtlct3D86qswhCs8iwbMAPeMa9Dib1ZaemmNgc/8DxmBGfpUqtT5 wXHZOcqDFaVlw+2Frcp8ic4nriEB/OC2/f92DjRDUcXl3JELs7tZiwEaqB2+w7Paxrxc vodA== X-Gm-Message-State: AD7BkJI7HddttaKW8pIUDqZ07Hzg3WUDUm9SyqHkTzsnjrcXP/0q12EEg8qub8gbuxI1nMxsUg4Mexiy5yD7gw== MIME-Version: 1.0 X-Received: by 10.107.39.139 with SMTP id n133mr23042307ion.57.1459859563523; Tue, 05 Apr 2016 05:32:43 -0700 (PDT) Received: by 10.79.126.207 with HTTP; Tue, 5 Apr 2016 05:32:43 -0700 (PDT) In-Reply-To: References: <57004D0F.70300@alvestrand.no> Date: Tue, 5 Apr 2016 14:32:43 +0200 Message-ID: From: Victor Pascual Avila To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Positioning draft-ietf-rtcweb-ip-address as a standards-track document 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, 05 Apr 2016 12:32:46 -0000 +1 On Tue, Apr 5, 2016 at 4:08 AM, Justin Uberti wrote: > Thanks for the concrete feedback. I agree with the proposed direction. > > On Sat, Apr 2, 2016 at 3:51 PM, Harald Alvestrand > wrote: >> >> I've read through draft-ietf-rtcweb-ip-address again, with an eye to >> seeing how it would read as a standards-track document. >> >> As such, it seems to me to provide rather tentative language in a few >> places, which could be strengthened by use of the CAPITALIZED WORDS. >> I think this is a Good Thing; if this is standards-track, with >> imperative, normative language, an implementation can claim support for >> RFC XXXX and expect the statement to be understood. >> (Remember - there is no protocol police. Nothing forces people to >> support RFC XXXX.) >> >> Changes needed: >> >> - Add the RFC 2119 incantation, including Stefan's addition ("lowercase >> words mean what they usually do") >> >> - Replace all occurences of "We recommend that..." with "an >> implementation MUST". >> >> - In section 3, end of first paragraph: " Specifically, WebRTC >> should:" -> "Implementations of this specification will:" >> >> - In section 4: "We recommend Mode 1 ... " -> "Mode 1 and mode 2 MUST be >> supported. Mode 1 SHOULD be the default when the user has not granted >> access to camera / microphone. Mode 2 SHOULD be the default when the >> user has granted access to camera / microphone. The implementation MAY >> provide means of letting the user or administrator select between modes. >> These means MUST NOT be placed under the control of WebRTC applications.= " >> >> I think this would make the spec a more useful tool for specifying what >> an application does. >> >> >> >> -- >> Surveillance is pervasive. Go Dark. >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --=20 Victor Pascual =C3=81vila From nobody Tue Apr 5 05:40: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 864C512D59D for ; Tue, 5 Apr 2016 05:40:19 -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 8pQkSO9FXWnJ for ; Tue, 5 Apr 2016 05:40:17 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C94F12D622 for ; Tue, 5 Apr 2016 05:40:17 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id i84so8230711ywc.2 for ; Tue, 05 Apr 2016 05:40:17 -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=q5hJyywT5DTFRjP8N79fAvnQ7ZcRoyAcLMtYlbAf0Vk=; b=bKXZR/G//3N8jB02T8Xb5sysOqVMbF7ZOv7wDR4bEErhF2sgETEavG+5x7HNGCncjK YLJNVEF3obv+e/yoS0MaA6UkEQt02JAnTBGR4lvfshpk2N6NGbz+CNGJo9Wf4sxxOibW VC54Q3ZQKHB/Dl08D+q1wrJ8QENzq2Xf5XS6uUZwN4mTDim2PwKVyOiMbx/RDpe8pxRw f6nlMufpPdRb/Bks4Fpi/8cinui9FRWOi8dAMW2nT5Ews/augQoIoM0Vc1wIOnwkyvHj QhVDEpEYBFaSYIDEVGffFro/renzPO7TS82riJ+NcEs4NPmpDKPHO+RVuxquUQqSYPl3 42ng== 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=q5hJyywT5DTFRjP8N79fAvnQ7ZcRoyAcLMtYlbAf0Vk=; b=Wg0FRCAO4E/1jGwhn0+ADFOtA6vFggAF4OjuUxFhrBErih9GrURCoEZ84jM7ex9tBd Eafz3iYX0Vez40xHNR3pqecqG9BVsyZk89tV07vlHJeqyJpLGWkfL0KCFCRtKjegrOkA zbKcH9YGN8nA6xYix2HyMlt3rvW3YyhhOkLpE8GSFMEhxDcjcc+DKPbI3sSTlWqvyUFh ZCjZ5YKUhJG5DyA4ap3YUjUoCdDW7WV8s1neiOuMwwUo0GcUO5vXtQ3ccAt9xcs0/qqN dqMUiQxqNKUGrpJEArmsOJ6sccMM2pzMsrwQ7vp8uQvHW/se4Eds20jARRSWCzDoYaC0 zTzg== X-Gm-Message-State: AD7BkJJTL8l6E16fNNuy2mdHRuREr27jf591nRO++KbK6DVmAo9ZON8tDVthg/1N6jPODv7onkd2xodnPYT61w== X-Received: by 10.37.231.9 with SMTP id e9mr3747816ybh.57.1459860016366; Tue, 05 Apr 2016 05:40:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Tue, 5 Apr 2016 05:39:36 -0700 (PDT) In-Reply-To: <570390ED.8080109@alvestrand.no> References: <57038B35.8040102@alvestrand.no> <570390ED.8080109@alvestrand.no> From: Eric Rescorla Date: Tue, 5 Apr 2016 09:39:36 -0300 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=94eb2c0b14bcb2bd59052fbc2553 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Tunnelling DTLS in SDP 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, 05 Apr 2016 12:40:19 -0000 --94eb2c0b14bcb2bd59052fbc2553 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 5, 2016 at 7:18 AM, Harald Alvestrand wrote: > On 04/05/2016 12:04 PM, Tim Panton wrote: > > > On 5 Apr 2016, at 10:53, Harald Alvestrand < > harald@alvestrand.no> wrote: > > On first read, this makes sense to me. > > I wonder if it could/should be made into a general concept, to fit with > the tendency in WebRTC:NG to separate signalling format even more from > operation? > > We could call it "out of band DTLS setup", say that in general, a DTLS > session can be started in one medium (SDP signalling, in this case), and > continued in another medium (the DTLS-protected media channel), and have = a > section describing the details of carrying DTLS-over-SDP. > > When viewing it in this way, using the same technique with Jabber or > proprietary signalling becomes a reasonably obvious exercise. There are > some other twists that seem obvious too - for instance, one could continu= e > the setup over the SDP channel in subsequent offer/answers if the first > exchange failed to set up a media channel. I'm not sure that makes sense, > though. > > One SDP twist: If forking happens, it could be treated like any other > attempt to generate multiple answers to a ClientHello, I think. I'm sure > it's well defined how to respond to that - it's an obvious attack. Only o= ne > leg of the fork would ever succeed, I assume. > > > Doesn=E2=80=99t passing the DTLS Hellos through javascript open us to a w= hole pile > of bid-down attacks where > the lists of supported crypto suites and extensions are manipulated in th= e > js ? E.G It might allow the javascript to insert > the magic extension that says "this isn=E2=80=99t being recorded=E2=80=9D= without the > browser actually being in that mode. > Or is there a way that DTLS can detect this ? > > > It certainly reduces the setup security from one where only network > on-path attackers can do MITM attacks on the handshake to one where > everyone with access to the Javascript can do MITM attacks on the handsha= ke. > Well, attackers who control the signaling can put themselves on the network by manipulating the ICE parameters. > > Given that DTLS is supposed to be a reasonable option when you have > on-path attackers on the network path, I certainly hope the defenses are > adequate in this case too, but I don't know DTLS well enough to be able t= o > say what those defenses are. > However the messages are sent, the handshake is tied to the endpoint keys. -Ekr > > T. > > > > > > On 04/04/2016 03:10 PM, Eric Rescorla wrote: > > Hi folks, > > I wanted to call your attention to a draft I just published with a > possibly stupid > idea. > > https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 > > A nontrivial fraction of call setup time in WebRTC is the DTLS handshake. > This document describes how to piggyback the first few handshake messages > in the SDP offer/answer exchange, thus reducing latency. > > Comments welcome. > > -Ekr > > > > > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/r= tcweb > > > > -- > Surveillance is pervasive. Go Dark. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > Tim Panton - Web/VoIP consultant and implementor > www.westhawk.co.uk > > > > > > -- > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --94eb2c0b14bcb2bd59052fbc2553 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 5, 2016 at 7:18 AM, Harald Alvestrand <= ;harald@alvestran= d.no> wrote:
=20 =20 =20
On 04/05/2016 12:04 PM, Tim Panton wrote:
=20 =20
On 5 Apr 2016, at 10:53, Harald Alvestrand <harald@alvestrand.no> wrote:

=20
On first read, this makes sense to me.

I wonder if it could/should be made into a general concept, to fit with the tendency in WebRTC:NG to separate signalling format even more from operation?

We could call it "out of band DTLS setup", say th= at in general, a DTLS session can be started in one medium (SDP signalling, in this case), and continued in another medium (the DTLS-protected media channel), and have a section describing the details of carrying DTLS-over-SDP.

When viewing it in this way, using the same technique with Jabber or proprietary signalling becomes a reasonably obvious exercise. There are some other twists that seem obvious too - for instance, one could continue the setup over the SDP channel in subsequent offer/answers if the first exchange failed to set up a media channel. I'm not sure that makes sense, though.
One SDP twist: If forking happens, it could be treated like any other attempt to generate multiple answers to a ClientHello, I think. I'm sure it's well defined ho= w to respond to that - it's an obvious attack. Only one leg of the fork would ever succeed, I assume.

Doesn=E2=80=99t passing the DTLS Hellos through javascript open us to a whole pile of bid-down attacks where
the lists of supported crypto suites and extensions are manipulated in the js ? E.G It =C2=A0might allow t= he javascript to insert=C2=A0
the magic extension that says "this isn=E2=80=99t being recorded=E2=80=9D =C2=A0without the browser actually being in tha= t mode.=C2=A0
Or is there a way that DTLS can detect this ?

 It certainly reduces the setup security from one where only network on-path attackers can do MITM attacks on the handshake to one where everyone with access to the Javascript can do MITM attacks on the handshake.

Well, attackers wh= o control the signaling can put themselves on the network by manipulating t= he
ICE parameters.
=C2=A0

Given that DTLS is supposed to be a reasonable option when you have on-path attackers on the network path, I certainly hope the defenses are adequate in this case too, but I don't know DTLS well enough to be able to say what those defenses are.

However the messages are sent, the handshake is tied to the endpoint= keys.

-Ekr



T.





On 04/04/2016 03:10 PM, Eric Rescorla wrote:
Hi folks,

I wanted to call your attention to a draft I just published with a possibly stupid
idea.


A nontrivial fraction of call setup time in WebRTC is the DTLS handshake.
This document describes how to piggyback the first few handshake messages
in the SDP offer/answer exchange, thus reducing latency.

Comments welcome.

-Ekr





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



--=20
Surveillance is pervasive. Go Dark.
_______________________________________________
rtcweb mailing list
rtcweb@iet= f.org
https://www.ietf.org/mailman/listinfo/rtcweb

Tim Panton - Web/VoIP consultant and implementor





--=20
Surveillance is pervasive. Go Dark.

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


--94eb2c0b14bcb2bd59052fbc2553-- From nobody Tue Apr 5 06:21:32 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 0178312D940 for ; Tue, 5 Apr 2016 06:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=telurix-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 GntAAO3Y6ttN for ; Tue, 5 Apr 2016 06:21:28 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1BDB12D936 for ; Tue, 5 Apr 2016 06:21:18 -0700 (PDT) Received: by mail-ig0-x22b.google.com with SMTP id ui10so13637896igc.1 for ; Tue, 05 Apr 2016 06:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=sSJrIQR8TOK8t4Fy60ZUywkBkaEELPwmtwo5KZL3Wdw=; b=AsTnYLMPZKROf5W8c6VtbpchNHWGh37JqHPc8H+2PZb45P4EgkP4XVbOPL5JVYARg3 fJEDIsBpTxiovc3GMNBe3xgNO0UT9UMJhbRD8EQ/TUjMW4gJCTtgFYFykRpIOi73eaOz ER4qe+/16VDT0OKnzCGXtTJGQsujzyxcrLuxwi0q1GkZhpEHOlX8DbAuxKGz/qX7xn0V i4Ce06Ozi4ifVRfQpnKOLGNqgMgWaS5g/yvU4tAhffYJmw1u6mXv81W+oMMjPZ7fdk5e 1jhkdy4Zg0xo6UiCDr/s9CGPjsdhpWFXxtdU7txA6TdFEjJmqrzVr/gNC7U9Tb0vEsfc LPCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=sSJrIQR8TOK8t4Fy60ZUywkBkaEELPwmtwo5KZL3Wdw=; b=jYuhURLfOmGby2DhkesYxINZo1AJ6MAHrOpRDGPhlIJtFaBa1dHz0V55Kb615ttmIs S77S1XhlQZ0bgF4yIy8wh4W7QvpbmKpkFtO65ZwPqHkHGjjMz4GJ7z1VSE3FUUmKHzM7 LGIYjws5I/s+vKAQT5dBwWrrZVxUTtJRuJpvg4i4zcm8DhfvhhNLNSOlddflQVbqVpI2 n2fysmeRm/D9YRNyjtsR5sX7eRQuSjBK9ylOnI3XJGpUGsOetPsavqk+nKIw+YcnL0qx 1smXmrC20RW4CDew/5HxwInHpf9OU4hakmlW/K/mc2gfZMUa4lKhNZeIeGqbez/zggZ5 JOoA== X-Gm-Message-State: AD7BkJI/zZnq2TwyPkHtpqCpTofsyI0t0lMYJ9wFqLKWXioZL5fZZvBSwqZu0dETGhy0/A== X-Received: by 10.50.118.4 with SMTP id ki4mr17833636igb.53.1459862477936; Tue, 05 Apr 2016 06:21:17 -0700 (PDT) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com. [209.85.213.173]) by smtp.gmail.com with ESMTPSA id au6sm7594417igc.0.2016.04.05.06.21.17 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2016 06:21:17 -0700 (PDT) Received: by mail-ig0-f173.google.com with SMTP id g8so13625119igr.0 for ; Tue, 05 Apr 2016 06:21:17 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.18.113 with SMTP id v17mr17340113igd.2.1459862476639; Tue, 05 Apr 2016 06:21:16 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Tue, 5 Apr 2016 06:21:16 -0700 (PDT) In-Reply-To: <57038B35.8040102@alvestrand.no> References: <57038B35.8040102@alvestrand.no> Date: Tue, 5 Apr 2016 09:21:16 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=089e01494ff2575a7c052fbcb88d Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Tunnelling DTLS in SDP 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, 05 Apr 2016 13:21:31 -0000 --089e01494ff2575a7c052fbcb88d Content-Type: text/plain; charset=UTF-8 On Tue, Apr 5, 2016 at 5:53 AM, Harald Alvestrand wrote: > > One SDP twist: If forking happens, it could be treated like any other > attempt to generate multiple answers to a ClientHello, I think. I'm sure > it's well defined how to respond to that - it's an obvious attack. Only one > leg of the fork would ever succeed, I assume. > The biggest issue with reusing ClientHello in case of forking would be reusing client random across multiple connections. Unless I am missing something, this should be generally safe. Another issue is what will happen if two DTLS association are established for a single m= line (i.e. RTCP bundle is not used). Does this mean the same ClientHello is used for both connection? Regards, _____________ Roman Shpount --089e01494ff2575a7c052fbcb88d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 5, 2016 at 5:53 AM, Harald Alvestrand &l= t;harald@alvestra= nd.no> wrote:
=20 =20 =20

One SDP twist: If forking happens, it could be treated like any other attempt to generate multiple answers to a ClientHello, I think. I'm sure it's well defined how to respond to that - it= 's an obvious attack. Only one leg of the fork would ever succeed, I assume.

The biggest issue= with reusing ClientHello in case of forking would be reusing client random= across multiple connections. Unless I am missing something, this should be= generally safe.

Another issue is what will happen= if two DTLS association are established for a single m=3D line (i.e. RTCP = bundle is not used). Does this mean the same ClientHello is used for both c= onnection?=C2=A0

Regards,
_____________
Roman Shpount
=
--089e01494ff2575a7c052fbcb88d-- From nobody Tue Apr 5 06:41:11 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 E548E12D923 for ; Tue, 5 Apr 2016 06:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 o2D2DWbVLJuU for ; Tue, 5 Apr 2016 06:41:06 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 B422912D974 for ; Tue, 5 Apr 2016 06:41:00 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 938FE87740B7E; Tue, 5 Apr 2016 13:40:56 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u35DewMm026677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Apr 2016 13:40:58 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u35DeQEj016428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Apr 2016 15:40:55 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.185]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 5 Apr 2016 15:40:28 +0200 From: "Drage, Keith (Nokia - GB)" To: EXT Eric Rescorla , Harald Alvestrand Thread-Topic: [rtcweb] Tunnelling DTLS in SDP Thread-Index: AQHRjyEi+HMv00YPtEqMC9MTX85SZJ97BUEAgAAD6oCAACd3AIAAMiDQ Date: Tue, 5 Apr 2016 13:40:27 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADEB9E7D@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <57038B35.8040102@alvestrand.no> <570390ED.8080109@alvestrand.no> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADEB9E7DFR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Tunnelling DTLS in SDP 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, 05 Apr 2016 13:41:10 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADEB9E7DFR712WXCHMBA11z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdCB0byBub3RlIHRoYXQgd2hlbiBJIGZpcnN0IHNhdyB0aGUgZHJhZnQsIEkgd2VudCBsb29r aW5nIGluIGl0IGZvciBhIGRpc2N1c3Npb24gb2YgdGhpcyBhc3BlY3QsIGFuZCBmYWlsZWQgdG8g ZmluZCBpdC4NCg0KTWF5YmUgd2UgY291bGQgaGF2ZSBhbiB1cGRhdGUgdGhhdCBhdCBsZWFzdCBw dXRzIHRoYXQgaXNzdWUgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLg0KDQpSZWdhcmRz DQoNCktlaXRoDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgRVhUIEVyaWMgUmVzY29ybGENClNlbnQ6IDA1IEFwcmlsIDIwMTYgMTM6 NDANClRvOiBIYXJhbGQgQWx2ZXN0cmFuZA0KQ2M6IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtydGN3ZWJdIFR1bm5lbGxpbmcgRFRMUyBpbiBTRFANCg0KDQoNCk9uIFR1ZSwgQXByIDUs IDIwMTYgYXQgNzoxOCBBTSwgSGFyYWxkIEFsdmVzdHJhbmQgPGhhcmFsZEBhbHZlc3RyYW5kLm5v PG1haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubz4+IHdyb3RlOg0KT24gMDQvMDUvMjAxNiAxMjow NCBQTSwgVGltIFBhbnRvbiB3cm90ZToNCg0KT24gNSBBcHIgMjAxNiwgYXQgMTA6NTMsIEhhcmFs ZCBBbHZlc3RyYW5kIDxoYXJhbGRAYWx2ZXN0cmFuZC5ubzxtYWlsdG86aGFyYWxkQGFsdmVzdHJh bmQubm8+PiB3cm90ZToNCg0KT24gZmlyc3QgcmVhZCwgdGhpcyBtYWtlcyBzZW5zZSB0byBtZS4N Cg0KSSB3b25kZXIgaWYgaXQgY291bGQvc2hvdWxkIGJlIG1hZGUgaW50byBhIGdlbmVyYWwgY29u Y2VwdCwgdG8gZml0IHdpdGggdGhlIHRlbmRlbmN5IGluIFdlYlJUQzpORyB0byBzZXBhcmF0ZSBz aWduYWxsaW5nIGZvcm1hdCBldmVuIG1vcmUgZnJvbSBvcGVyYXRpb24/DQoNCldlIGNvdWxkIGNh bGwgaXQgIm91dCBvZiBiYW5kIERUTFMgc2V0dXAiLCBzYXkgdGhhdCBpbiBnZW5lcmFsLCBhIERU TFMgc2Vzc2lvbiBjYW4gYmUgc3RhcnRlZCBpbiBvbmUgbWVkaXVtIChTRFAgc2lnbmFsbGluZywg aW4gdGhpcyBjYXNlKSwgYW5kIGNvbnRpbnVlZCBpbiBhbm90aGVyIG1lZGl1bSAodGhlIERUTFMt cHJvdGVjdGVkIG1lZGlhIGNoYW5uZWwpLCBhbmQgaGF2ZSBhIHNlY3Rpb24gZGVzY3JpYmluZyB0 aGUgZGV0YWlscyBvZiBjYXJyeWluZyBEVExTLW92ZXItU0RQLg0KDQpXaGVuIHZpZXdpbmcgaXQg aW4gdGhpcyB3YXksIHVzaW5nIHRoZSBzYW1lIHRlY2huaXF1ZSB3aXRoIEphYmJlciBvciBwcm9w cmlldGFyeSBzaWduYWxsaW5nIGJlY29tZXMgYSByZWFzb25hYmx5IG9idmlvdXMgZXhlcmNpc2Uu IFRoZXJlIGFyZSBzb21lIG90aGVyIHR3aXN0cyB0aGF0IHNlZW0gb2J2aW91cyB0b28gLSBmb3Ig aW5zdGFuY2UsIG9uZSBjb3VsZCBjb250aW51ZSB0aGUgc2V0dXAgb3ZlciB0aGUgU0RQIGNoYW5u ZWwgaW4gc3Vic2VxdWVudCBvZmZlci9hbnN3ZXJzIGlmIHRoZSBmaXJzdCBleGNoYW5nZSBmYWls ZWQgdG8gc2V0IHVwIGEgbWVkaWEgY2hhbm5lbC4gSSdtIG5vdCBzdXJlIHRoYXQgbWFrZXMgc2Vu c2UsIHRob3VnaC4NCg0KT25lIFNEUCB0d2lzdDogSWYgZm9ya2luZyBoYXBwZW5zLCBpdCBjb3Vs ZCBiZSB0cmVhdGVkIGxpa2UgYW55IG90aGVyIGF0dGVtcHQgdG8gZ2VuZXJhdGUgbXVsdGlwbGUg YW5zd2VycyB0byBhIENsaWVudEhlbGxvLCBJIHRoaW5rLiBJJ20gc3VyZSBpdCdzIHdlbGwgZGVm aW5lZCBob3cgdG8gcmVzcG9uZCB0byB0aGF0IC0gaXQncyBhbiBvYnZpb3VzIGF0dGFjay4gT25s eSBvbmUgbGVnIG9mIHRoZSBmb3JrIHdvdWxkIGV2ZXIgc3VjY2VlZCwgSSBhc3N1bWUuDQoNCkRv ZXNu4oCZdCBwYXNzaW5nIHRoZSBEVExTIEhlbGxvcyB0aHJvdWdoIGphdmFzY3JpcHQgb3BlbiB1 cyB0byBhIHdob2xlIHBpbGUgb2YgYmlkLWRvd24gYXR0YWNrcyB3aGVyZQ0KdGhlIGxpc3RzIG9m IHN1cHBvcnRlZCBjcnlwdG8gc3VpdGVzIGFuZCBleHRlbnNpb25zIGFyZSBtYW5pcHVsYXRlZCBp biB0aGUganMgPyBFLkcgSXQgIG1pZ2h0IGFsbG93IHRoZSBqYXZhc2NyaXB0IHRvIGluc2VydA0K dGhlIG1hZ2ljIGV4dGVuc2lvbiB0aGF0IHNheXMgInRoaXMgaXNu4oCZdCBiZWluZyByZWNvcmRl ZOKAnSAgd2l0aG91dCB0aGUgYnJvd3NlciBhY3R1YWxseSBiZWluZyBpbiB0aGF0IG1vZGUuDQpP ciBpcyB0aGVyZSBhIHdheSB0aGF0IERUTFMgY2FuIGRldGVjdCB0aGlzID8NCg0KSXQgY2VydGFp bmx5IHJlZHVjZXMgdGhlIHNldHVwIHNlY3VyaXR5IGZyb20gb25lIHdoZXJlIG9ubHkgbmV0d29y ayBvbi1wYXRoIGF0dGFja2VycyBjYW4gZG8gTUlUTSBhdHRhY2tzIG9uIHRoZSBoYW5kc2hha2Ug dG8gb25lIHdoZXJlIGV2ZXJ5b25lIHdpdGggYWNjZXNzIHRvIHRoZSBKYXZhc2NyaXB0IGNhbiBk byBNSVRNIGF0dGFja3Mgb24gdGhlIGhhbmRzaGFrZS4NCg0KV2VsbCwgYXR0YWNrZXJzIHdobyBj b250cm9sIHRoZSBzaWduYWxpbmcgY2FuIHB1dCB0aGVtc2VsdmVzIG9uIHRoZSBuZXR3b3JrIGJ5 IG1hbmlwdWxhdGluZyB0aGUNCklDRSBwYXJhbWV0ZXJzLg0KDQoNCkdpdmVuIHRoYXQgRFRMUyBp cyBzdXBwb3NlZCB0byBiZSBhIHJlYXNvbmFibGUgb3B0aW9uIHdoZW4geW91IGhhdmUgb24tcGF0 aCBhdHRhY2tlcnMgb24gdGhlIG5ldHdvcmsgcGF0aCwgSSBjZXJ0YWlubHkgaG9wZSB0aGUgZGVm ZW5zZXMgYXJlIGFkZXF1YXRlIGluIHRoaXMgY2FzZSB0b28sIGJ1dCBJIGRvbid0IGtub3cgRFRM UyB3ZWxsIGVub3VnaCB0byBiZSBhYmxlIHRvIHNheSB3aGF0IHRob3NlIGRlZmVuc2VzIGFyZS4N Cg0KSG93ZXZlciB0aGUgbWVzc2FnZXMgYXJlIHNlbnQsIHRoZSBoYW5kc2hha2UgaXMgdGllZCB0 byB0aGUgZW5kcG9pbnQga2V5cy4NCg0KLUVrcg0KDQoNCg0KDQpULg0KDQoNCg0KDQoNCg0KT24g MDQvMDQvMjAxNiAwMzoxMCBQTSwgRXJpYyBSZXNjb3JsYSB3cm90ZToNCkhpIGZvbGtzLA0KDQpJ IHdhbnRlZCB0byBjYWxsIHlvdXIgYXR0ZW50aW9uIHRvIGEgZHJhZnQgSSBqdXN0IHB1Ymxpc2hl ZCB3aXRoIGEgcG9zc2libHkgc3R1cGlkDQppZGVhLg0KDQpodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtcmVzY29ybGEtZHRscy1pbi1zZHAtMDANCg0KQSBub250cml2aWFsIGZyYWN0 aW9uIG9mIGNhbGwgc2V0dXAgdGltZSBpbiBXZWJSVEMgaXMgdGhlIERUTFMgaGFuZHNoYWtlLg0K VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IHRvIHBpZ2d5YmFjayB0aGUgZmlyc3QgZmV3IGhh bmRzaGFrZSBtZXNzYWdlcw0KaW4gdGhlIFNEUCBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UsIHRodXMg cmVkdWNpbmcgbGF0ZW5jeS4NCg0KQ29tbWVudHMgd2VsY29tZS4NCg0KLUVrcg0KDQoNCg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCnJ0Y3dl YiBtYWlsaW5nIGxpc3QNCg0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+ DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg0KDQoN Ci0tDQoNClN1cnZlaWxsYW5jZSBpcyBwZXJ2YXNpdmUuIEdvIERhcmsuDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0K cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQpUaW0gUGFudG9uIC0gV2ViL1ZvSVAgY29u c3VsdGFudCBhbmQgaW1wbGVtZW50b3INCnd3dy53ZXN0aGF3ay5jby51azxodHRwOi8vd3d3Lndl c3RoYXdrLmNvLnVrPg0KDQoNCg0KDQoNCg0KDQotLQ0KDQpTdXJ2ZWlsbGFuY2UgaXMgcGVydmFz aXZlLiBHbyBEYXJrLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3 ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dl Yg0KDQo= --_000_949EF20990823C4C85C18D59AA11AD8BADEB9E7DFR712WXCHMBA11z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SnVzdCB0byBub3RlIHRoYXQg d2hlbiBJIGZpcnN0IHNhdyB0aGUgZHJhZnQsIEkgd2VudCBsb29raW5nIGluIGl0IGZvciBhIGRp c2N1c3Npb24gb2YgdGhpcyBhc3BlY3QsIGFuZCBmYWlsZWQgdG8gZmluZCBpdC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pk1heWJlIHdlIGNvdWxkIGhhdmUgYW4gdXBkYXRlIHRoYXQgYXQgbGVhc3QgcHV0cyB0aGF0IGlz c3VlIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPktlaXRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0Bp ZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RVhUIEVyaWMgUmVzY29ybGE8YnI+DQo8Yj5T ZW50OjwvYj4gMDUgQXByaWwgMjAxNiAxMzo0MDxicj4NCjxiPlRvOjwvYj4gSGFyYWxkIEFsdmVz dHJhbmQ8YnI+DQo8Yj5DYzo8L2I+IHJ0Y3dlYkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW3J0Y3dlYl0gVHVubmVsbGluZyBEVExTIGluIFNEUDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gVHVlLCBBcHIgNSwgMjAxNiBhdCA3OjE4IEFNLCBIYXJhbGQgQWx2 ZXN0cmFuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhcmFsZEBhbHZlc3RyYW5kLm5vIiB0YXJnZXQ9 Il9ibGFuayI+aGFyYWxkQGFsdmVzdHJhbmQubm88L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMDQvMDUvMjAxNiAxMjow NCBQTSwgVGltIFBhbnRvbiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiA1IEFwciAyMDE2LCBhdCAxMDo1MywgSGFyYWxkIEFsdmVzdHJh bmQgJmx0OzxhIGhyZWY9Im1haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubyIgdGFyZ2V0PSJfYmxh bmsiPmhhcmFsZEBhbHZlc3RyYW5kLm5vPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gZmlyc3QgcmVhZCwgdGhpcyBt YWtlcyBzZW5zZSB0byBtZS48YnI+DQo8YnI+DQpJIHdvbmRlciBpZiBpdCBjb3VsZC9zaG91bGQg YmUgbWFkZSBpbnRvIGEgZ2VuZXJhbCBjb25jZXB0LCB0byBmaXQgd2l0aCB0aGUgdGVuZGVuY3kg aW4gV2ViUlRDOk5HIHRvIHNlcGFyYXRlIHNpZ25hbGxpbmcgZm9ybWF0IGV2ZW4gbW9yZSBmcm9t IG9wZXJhdGlvbj88YnI+DQo8YnI+DQpXZSBjb3VsZCBjYWxsIGl0ICZxdW90O291dCBvZiBiYW5k IERUTFMgc2V0dXAmcXVvdDssIHNheSB0aGF0IGluIGdlbmVyYWwsIGEgRFRMUyBzZXNzaW9uIGNh biBiZSBzdGFydGVkIGluIG9uZSBtZWRpdW0gKFNEUCBzaWduYWxsaW5nLCBpbiB0aGlzIGNhc2Up LCBhbmQgY29udGludWVkIGluIGFub3RoZXIgbWVkaXVtICh0aGUgRFRMUy1wcm90ZWN0ZWQgbWVk aWEgY2hhbm5lbCksIGFuZCBoYXZlIGEgc2VjdGlvbiBkZXNjcmliaW5nIHRoZSBkZXRhaWxzIG9m IGNhcnJ5aW5nDQogRFRMUy1vdmVyLVNEUC48YnI+DQo8YnI+DQpXaGVuIHZpZXdpbmcgaXQgaW4g dGhpcyB3YXksIHVzaW5nIHRoZSBzYW1lIHRlY2huaXF1ZSB3aXRoIEphYmJlciBvciBwcm9wcmll dGFyeSBzaWduYWxsaW5nIGJlY29tZXMgYSByZWFzb25hYmx5IG9idmlvdXMgZXhlcmNpc2UuIFRo ZXJlIGFyZSBzb21lIG90aGVyIHR3aXN0cyB0aGF0IHNlZW0gb2J2aW91cyB0b28gLSBmb3IgaW5z dGFuY2UsIG9uZSBjb3VsZCBjb250aW51ZSB0aGUgc2V0dXAgb3ZlciB0aGUgU0RQIGNoYW5uZWwg aW4gc3Vic2VxdWVudA0KIG9mZmVyL2Fuc3dlcnMgaWYgdGhlIGZpcnN0IGV4Y2hhbmdlIGZhaWxl ZCB0byBzZXQgdXAgYSBtZWRpYSBjaGFubmVsLiBJJ20gbm90IHN1cmUgdGhhdCBtYWtlcyBzZW5z ZSwgdGhvdWdoLjxicj4NCjxicj4NCk9uZSBTRFAgdHdpc3Q6IElmIGZvcmtpbmcgaGFwcGVucywg aXQgY291bGQgYmUgdHJlYXRlZCBsaWtlIGFueSBvdGhlciBhdHRlbXB0IHRvIGdlbmVyYXRlIG11 bHRpcGxlIGFuc3dlcnMgdG8gYSBDbGllbnRIZWxsbywgSSB0aGluay4gSSdtIHN1cmUgaXQncyB3 ZWxsIGRlZmluZWQgaG93IHRvIHJlc3BvbmQgdG8gdGhhdCAtIGl0J3MgYW4gb2J2aW91cyBhdHRh Y2suIE9ubHkgb25lIGxlZyBvZiB0aGUgZm9yayB3b3VsZCBldmVyIHN1Y2NlZWQsIEkNCiBhc3N1 bWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb2VzbuKAmXQgcGFzc2luZyB0aGUgRFRM UyBIZWxsb3MgdGhyb3VnaCBqYXZhc2NyaXB0IG9wZW4gdXMgdG8gYSB3aG9sZSBwaWxlIG9mIGJp ZC1kb3duIGF0dGFja3Mgd2hlcmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnRoZSBsaXN0cyBvZiBzdXBwb3J0ZWQgY3J5cHRvIHN1aXRlcyBhbmQg ZXh0ZW5zaW9ucyBhcmUgbWFuaXB1bGF0ZWQgaW4gdGhlIGpzID8gRS5HIEl0ICZuYnNwO21pZ2h0 IGFsbG93IHRoZSBqYXZhc2NyaXB0IHRvIGluc2VydCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlIG1hZ2ljIGV4dGVuc2lvbiB0aGF0 IHNheXMgJnF1b3Q7dGhpcyBpc27igJl0IGJlaW5nIHJlY29yZGVk4oCdICZuYnNwO3dpdGhvdXQg dGhlIGJyb3dzZXIgYWN0dWFsbHkgYmVpbmcgaW4gdGhhdCBtb2RlLiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T3IgaXMgdGhlcmUgYSB3 YXkgdGhhdCBEVExTIGNhbiBkZXRlY3QgdGhpcyA/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSXQgY2VydGFp bmx5IHJlZHVjZXMgdGhlIHNldHVwIHNlY3VyaXR5IGZyb20gb25lIHdoZXJlIG9ubHkgbmV0d29y ayBvbi1wYXRoIGF0dGFja2VycyBjYW4gZG8gTUlUTSBhdHRhY2tzIG9uIHRoZSBoYW5kc2hha2Ug dG8gb25lIHdoZXJlIGV2ZXJ5b25lIHdpdGggYWNjZXNzIHRvIHRoZSBKYXZhc2NyaXB0IGNhbiBk byBNSVRNIGF0dGFja3Mgb24gdGhlIGhhbmRzaGFrZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2VsbCwgYXR0YWNrZXJzIHdobyBjb250cm9s IHRoZSBzaWduYWxpbmcgY2FuIHB1dCB0aGVtc2VsdmVzIG9uIHRoZSBuZXR3b3JrIGJ5IG1hbmlw dWxhdGluZyB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPklDRSBwYXJhbWV0ZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBj bSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KR2l2ZW4gdGhhdCBEVExTIGlz IHN1cHBvc2VkIHRvIGJlIGEgcmVhc29uYWJsZSBvcHRpb24gd2hlbiB5b3UgaGF2ZSBvbi1wYXRo IGF0dGFja2VycyBvbiB0aGUgbmV0d29yayBwYXRoLCBJIGNlcnRhaW5seSBob3BlIHRoZSBkZWZl bnNlcyBhcmUgYWRlcXVhdGUgaW4gdGhpcyBjYXNlIHRvbywgYnV0IEkgZG9uJ3Qga25vdyBEVExT IHdlbGwgZW5vdWdoIHRvIGJlIGFibGUgdG8gc2F5IHdoYXQgdGhvc2UgZGVmZW5zZXMgYXJlLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Ib3dldmVyIHRoZSBtZXNzYWdlcyBhcmUgc2VudCwgdGhlIGhhbmRzaGFrZSBp cyB0aWVkIHRvIHRoZSBlbmRwb2ludCBrZXlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCk9uIDA0LzA0LzIwMTYgMDM6MTAgUE0sIEVyaWMg UmVzY29ybGEgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhpIGZvbGtzLCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgd2FudGVkIHRvIGNhbGwgeW91ciBhdHRlbnRpb24gdG8gYSBkcmFmdCBJ IGp1c3QgcHVibGlzaGVkIHdpdGggYSBwb3NzaWJseSBzdHVwaWQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmlkZWEuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yZXNjb3JsYS1kdGxzLWluLXNkcC0wMCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yZXNjb3JsYS1kdGxzLWlu LXNkcC0wMDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QSBub250cml2aWFsIGZyYWN0aW9uIG9mIGNhbGwgc2V0dXAgdGltZSBpbiBXZWJS VEMgaXMgdGhlIERUTFMgaGFuZHNoYWtlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IHRvIHBpZ2d5 YmFjayB0aGUgZmlyc3QgZmV3IGhhbmRzaGFrZSBtZXNzYWdlczxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW4gdGhlIFNEUCBvZmZlci9hbnN3ZXIg ZXhjaGFuZ2UsIHRodXMgcmVkdWNpbmcgbGF0ZW5jeS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29tbWVudHMgd2VsY29tZS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cHJlPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3By ZT4NCjxwcmU+cnRjd2ViIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhy ZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5v cmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9i bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8cHJlPi0tIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlN1cnZlaWxsYW5jZSBp cyBwZXJ2YXNpdmUuIEdvIERhcmsuPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaW0gUGFudG9uIC0gV2ViL1Zv SVAgY29uc3VsdGFudCBhbmQgaW1wbGVtZW50b3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vd3d3Lndlc3RoYXdrLmNvLnVrIiB0YXJn ZXQ9Il9ibGFuayI+d3d3Lndlc3RoYXdrLmNvLnVrPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPi0tIDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPlN1cnZlaWxsYW5jZSBpcyBwZXJ2YXNpdmUuIEdvIERhcmsuPG86cD48 L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3 ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_949EF20990823C4C85C18D59AA11AD8BADEB9E7DFR712WXCHMBA11z_-- From nobody Tue Apr 5 07:20: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 5E78812D1A9 for ; Tue, 5 Apr 2016 07:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 S6jXKFbqbHI5 for ; Tue, 5 Apr 2016 07:20:02 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 4DC1D12D590 for ; Tue, 5 Apr 2016 07:20:00 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 63115AC5DF730; Tue, 5 Apr 2016 14:19:52 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u35EJsmU009199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Apr 2016 14:19:54 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u35EJleX031034 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Apr 2016 16:19:54 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.185]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 5 Apr 2016 16:19:23 +0200 From: "Drage, Keith (Nokia - GB)" To: "rtcweb@ietf.org" , Justin Uberti Thread-Topic: [rtcweb] Positioning draft-ietf-rtcweb-ip-address as a standards-track document Thread-Index: AQHRjuAkMCUJHmT0vUyrP+9UAmfl2597LziAgAA7yFA= Date: Tue, 5 Apr 2016 14:19:23 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADEB9EDB@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <57004D0F.70300@alvestrand.no> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] Positioning draft-ietf-rtcweb-ip-address as a standards-track document 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, 05 Apr 2016 14:20:08 -0000 SSBoYXZlIG5vIHByb2JsZW0gd2l0aCB0aGUgcHJvcG9zZWQgY2hhbmdlcy4gDQoNCkkgZG8gaG93 ZXZlciBoYXZlIHNvbWUgZnVydGhlciBxdWVzdGlvbnMgYXMgYSByZXN1bHQgb2YgdGhvc2UgY2hh bmdlcy4NCg0KMSkJSW4gY2xhdXNlIDMsIHdlIGhhdmUgdGhlIGZvbGxvd2luZyBzZW50ZW5jZSB1 bmNoYW5nZWQ6DQoNCgkiVGhpcyBtZWFucyB0aGF0IFdlYlJUQyBzaG91bGQgYmUgY29uZmlndXJl ZCBieQ0KICAgZGVmYXVsdCB0byBvbmx5IHJldmVhbCB0aGUgbWluaW11bSBhbW91bnQgb2YgaW5m b3JtYXRpb24gbmVlZGVkIHRvDQogICBlc3RhYmxpc2ggYSBwZXJmb3JtYW50IFdlYlJUQyBzZXNz aW9uLCB3aGlsZSBwcm92aWRpbmcgb3B0aW9ucyB0bw0KICAgcmV2ZWFsIGFkZGl0aW9uYWwgaW5m b3JtYXRpb24gdXBvbiB1c2VyIGNvbnNlbnQsIG9yIGZ1cnRoZXIgbGltaXQNCiAgIHRoaXMgaW5m b3JtYXRpb24gaWYgdGhlIHVzZXIgaGFzIHNwZWNpZmljYWxseSByZXF1ZXN0ZWQgdGhpcy4iDQoN ClNlY3Rpb24gMyBpcyBlbnRpdGxlZCBnb2FscywgYnV0IEkgYW0gdW5zdXJlIGhvdyB0aGlzIHNl bnRlbmNlIGZpdHMgaW4gdGhhdCBzY29wZS4gQ2FuIHlvdSBjbGFyaWZ5IChpbiByZXNwb25zZSBy YXRoZXIgdGhhbiBpbiB0aGUgZHJhZnQgZm9yIHRoZSBtb21lbnQpLg0KDQoyKQlXaGF0IGhhcHBl bnMgdG8gY2xhdXNlIDUuIElzIHRoZSBmaXJzdCBidWxsZXQ6DQoNCgkiQXBwbGljYXRpb25zIHNo b3VsZCBkZXBsb3kgYSBUVVJOIHNlcnZlciB3aXRoIHN1cHBvcnQgZm9yIGJvdGggVURQDQogICAg ICBhbmQgVENQIGNvbm5lY3Rpb25zIHRvIHRoZSBzZXJ2ZXIuICBUaGlzIGVuc3VyZXMgdGhhdCBj b25uZWN0aXZpdHkNCiAgICAgIGNhbiBzdGlsbCBiZSBlc3RhYmxpc2hlZCwgZXZlbiB3aGVuIE1v ZGUgMyBvciA0IGFyZSBpbiB1c2UsDQogICAgICBhc3N1bWluZyB0aGUgVFVSTiBzZXJ2ZXIgY2Fu IGJlIHJlYWNoZWQuIg0KDQpzcGVjaWZpZWQgZWxzZXdoZXJlLCBhbmQgaWYgc28gd2hlcmUsIG9y IGlzIHRoaXMgYSByZWFsICJTSE9VTEQiLg0KDQozKQlTaW1pbGFybHkgb24gY2xhdXNlIDUsIHRo ZSBwcm9wb3NlZCB0ZXh0IHN0YXRlcyB0aGF0IG1vZGUgMSBhbmQgbW9kZSAyIGFyZSBtYW5kYXRv cnkgdG8gc3VwcG9ydCwgd2l0aCB0aGUgaW1wbGljYXRpb24gdGhhdCBtb2RlIDMgYW5kIG1vZGUg NCBhcmUgb3B0aW9uYWwuIEhvd2V2ZXIgY2xhdXNlIDUgc3RhdGVzOg0KDQoJIkFwcGxpY2F0aW9u cyBjYW4gZGV0ZWN0IHdoZW4gdGhleSBkb24ndCBoYXZlIGFjY2VzcyB0byB0aGUgZnVsbA0KICAg ICAgc2V0IG9mIElDRSBjYW5kaWRhdGVzIGJ5IGNoZWNraW5nIGZvciB0aGUgcHJlc2VuY2Ugb2Yg aG9zdA0KICAgICAgY2FuZGlkYXRlcy4gIElmIG5vIGhvc3QgY2FuZGlkYXRlcyBhcmUgcHJlc2Vu dCwgTW9kZSAzIG9yIDQgYWJvdmUNCiAgICAgIGlzIGluIHVzZS4iDQoNCldoaWNoIHNlZW1zIHRv IGltcGx5IHRoYXQgbW9kZSAzIGFuZCBtb2RlIDQgaGF2ZSB0byBiZSBzdXBwb3J0ZWQgYXMgd2Vs bC4NCg0KNCkJQW5kIG9uIHRoZSBsYXN0IGJ1bGxldCBvZiBjbGF1c2UgNSwgSSBhbSB1bnN1cmUg d2hldGhlcg0KDQoJIkZ1dHVyZSB2ZXJzaW9ucyBvZiBicm93c2VycyBtYXkgcHJlc2VudCBhbiBp bmRpY2F0b3IgdG8gc2lnbmlmeQ0KICAgICAgdGhhdCB0aGUgcGFnZSBpcyB1c2luZyBXZWJSVEMg dG8gc2V0IHVwIGEgcGVlci10by1wZWVyIGNvbm5lY3Rpb24uDQogICAgICBBcHBsaWNhdGlvbnMg c2hvdWxkIGJlIGNhcmVmdWwgdG8gb25seSB1c2UgV2ViUlRDIGluIGEgZmFzaGlvbg0KICAgICAg dGhhdCBpcyBjb25zaXN0ZW50IHdpdGggdXNlciBleHBlY3RhdGlvbnMuIiANCg0KYmVsb25ncyBp biB0aGUgZG9jdW1lbnQuIENhbiB5b3UgcHJvdmlkZSBzb21lIGV4cGxhbmF0aW9uIGFzIHRvIHdo eSB5b3UgYmVsaWV2ZSBpdCBpcyB1c2VmdWwuDQoNClJlZ2FyZHMNCg0KS2VpdGgNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRVhUIFZpY3RvciBQYXNjdWFsIEF2aWxhDQpTZW50OiAw NSBBcHJpbCAyMDE2IDEzOjMzDQpUbzogSnVzdGluIFViZXJ0aQ0KQ2M6IHJ0Y3dlYkBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFBvc2l0aW9uaW5nIGRyYWZ0LWlldGYtcnRjd2ViLWlw LWFkZHJlc3MgYXMgYSBzdGFuZGFyZHMtdHJhY2sgZG9jdW1lbnQNCg0KKzENCg0KT24gVHVlLCBB cHIgNSwgMjAxNiBhdCA0OjA4IEFNLCBKdXN0aW4gVWJlcnRpIDxqdWJlcnRpQGdvb2dsZS5jb20+ IHdyb3RlOg0KPiBUaGFua3MgZm9yIHRoZSBjb25jcmV0ZSBmZWVkYmFjay4gSSBhZ3JlZSB3aXRo IHRoZSBwcm9wb3NlZCBkaXJlY3Rpb24uDQo+DQo+IE9uIFNhdCwgQXByIDIsIDIwMTYgYXQgMzo1 MSBQTSwgSGFyYWxkIEFsdmVzdHJhbmQgDQo+IDxoYXJhbGRAYWx2ZXN0cmFuZC5ubz4NCj4gd3Jv dGU6DQo+Pg0KPj4gSSd2ZSByZWFkIHRocm91Z2ggZHJhZnQtaWV0Zi1ydGN3ZWItaXAtYWRkcmVz cyBhZ2Fpbiwgd2l0aCBhbiBleWUgdG8gDQo+PiBzZWVpbmcgaG93IGl0IHdvdWxkIHJlYWQgYXMg YSBzdGFuZGFyZHMtdHJhY2sgZG9jdW1lbnQuDQo+Pg0KPj4gQXMgc3VjaCwgaXQgc2VlbXMgdG8g bWUgdG8gcHJvdmlkZSByYXRoZXIgdGVudGF0aXZlIGxhbmd1YWdlIGluIGEgZmV3IA0KPj4gcGxh Y2VzLCB3aGljaCBjb3VsZCBiZSBzdHJlbmd0aGVuZWQgYnkgdXNlIG9mIHRoZSBDQVBJVEFMSVpF RCBXT1JEUy4NCj4+IEkgdGhpbmsgdGhpcyBpcyBhIEdvb2QgVGhpbmc7IGlmIHRoaXMgaXMgc3Rh bmRhcmRzLXRyYWNrLCB3aXRoIA0KPj4gaW1wZXJhdGl2ZSwgbm9ybWF0aXZlIGxhbmd1YWdlLCBh biBpbXBsZW1lbnRhdGlvbiBjYW4gY2xhaW0gc3VwcG9ydCANCj4+IGZvciBSRkMgWFhYWCBhbmQg ZXhwZWN0IHRoZSBzdGF0ZW1lbnQgdG8gYmUgdW5kZXJzdG9vZC4NCj4+IChSZW1lbWJlciAtIHRo ZXJlIGlzIG5vIHByb3RvY29sIHBvbGljZS4gTm90aGluZyBmb3JjZXMgcGVvcGxlIHRvIA0KPj4g c3VwcG9ydCBSRkMgWFhYWC4pDQo+Pg0KPj4gQ2hhbmdlcyBuZWVkZWQ6DQo+Pg0KPj4gLSBBZGQg dGhlIFJGQyAyMTE5IGluY2FudGF0aW9uLCBpbmNsdWRpbmcgU3RlZmFuJ3MgYWRkaXRpb24gDQo+ PiAoImxvd2VyY2FzZSB3b3JkcyBtZWFuIHdoYXQgdGhleSB1c3VhbGx5IGRvIikNCj4+DQo+PiAt IFJlcGxhY2UgYWxsIG9jY3VyZW5jZXMgb2YgIldlIHJlY29tbWVuZCB0aGF0Li4uIiB3aXRoICJh biANCj4+IGltcGxlbWVudGF0aW9uIE1VU1QiLg0KPj4NCj4+IC0gSW4gc2VjdGlvbiAzLCBlbmQg b2YgZmlyc3QgcGFyYWdyYXBoOiAiICAgU3BlY2lmaWNhbGx5LCBXZWJSVEMNCj4+IHNob3VsZDoi IC0+ICJJbXBsZW1lbnRhdGlvbnMgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIHdpbGw6Ig0KPj4NCj4+ IC0gSW4gc2VjdGlvbiA0OiAiV2UgcmVjb21tZW5kIE1vZGUgMSAuLi4gIiAtPiAiTW9kZSAxIGFu ZCBtb2RlIDIgTVVTVCANCj4+IGJlIHN1cHBvcnRlZC4gTW9kZSAxIFNIT1VMRCBiZSB0aGUgZGVm YXVsdCB3aGVuIHRoZSB1c2VyIGhhcyBub3QgDQo+PiBncmFudGVkIGFjY2VzcyB0byBjYW1lcmEg LyBtaWNyb3Bob25lLiBNb2RlIDIgU0hPVUxEIGJlIHRoZSBkZWZhdWx0IA0KPj4gd2hlbiB0aGUg dXNlciBoYXMgZ3JhbnRlZCBhY2Nlc3MgdG8gY2FtZXJhIC8gbWljcm9waG9uZS4gVGhlIA0KPj4g aW1wbGVtZW50YXRpb24gTUFZIHByb3ZpZGUgbWVhbnMgb2YgbGV0dGluZyB0aGUgdXNlciBvciBh ZG1pbmlzdHJhdG9yIHNlbGVjdCBiZXR3ZWVuIG1vZGVzLg0KPj4gVGhlc2UgbWVhbnMgTVVTVCBO T1QgYmUgcGxhY2VkIHVuZGVyIHRoZSBjb250cm9sIG9mIFdlYlJUQyBhcHBsaWNhdGlvbnMuIg0K Pj4NCj4+IEkgdGhpbmsgdGhpcyB3b3VsZCBtYWtlIHRoZSBzcGVjIGEgbW9yZSB1c2VmdWwgdG9v bCBmb3Igc3BlY2lmeWluZyANCj4+IHdoYXQgYW4gYXBwbGljYXRpb24gZG9lcy4NCj4+DQo+Pg0K Pj4NCj4+IC0tDQo+PiBTdXJ2ZWlsbGFuY2UgaXMgcGVydmFzaXZlLiBHbyBEYXJrLg0KPj4NCj4+ DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g cnRjd2ViIG1haWxpbmcgbGlzdA0KPj4gcnRjd2ViQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPg0KPg0KPg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBydGN3ZWIgbWFpbGluZyBsaXN0 DQo+IHJ0Y3dlYkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3J0Y3dlYg0KPg0KDQoNCg0KLS0NClZpY3RvciBQYXNjdWFsIMOBdmlsYQ0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcg bGlzdA0KcnRjd2ViQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3J0Y3dlYg0K From nobody Tue Apr 5 13:19:14 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 89D5812D7A6 for ; Tue, 5 Apr 2016 13:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 UF2jCTJ_Fzaa for ; Tue, 5 Apr 2016 13:19:11 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 E4D7512D12C for ; Tue, 5 Apr 2016 13:19:10 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id E122FC7E06617 for ; Tue, 5 Apr 2016 20:19:05 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u35KJ9bY026900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 5 Apr 2016 20:19:09 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u35KJ8QC010998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 5 Apr 2016 22:19:09 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.185]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 5 Apr 2016 22:19:08 +0200 From: "Drage, Keith (Nokia - GB)" To: "rtcweb@ietf.org" Thread-Topic: IP gathering permission Thread-Index: AdGPeGd58V/HGoaQSbeQrBprO/9n+Q== Date: Tue, 5 Apr 2016 20:19:07 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADEBA3B8@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [rtcweb] IP gathering permission 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, 05 Apr 2016 20:19:12 -0000 The discussion in the WG (Tuesday p.m. session) that I have just listened t= o causes me concern. Any system that gathers personal information needs to meet the local regula= tory framework. For example, throughout most of Europe that is the privacy = directive and its local implementation in various European countries. While= I don't expect people to analyse the protocol in terms of each local regul= atory framework, I believe we do need to provide the tools to allow these t= o be met.=20 Ultimately, it is not just a matter of whether the user can comprehend what= he has been asked, but whether the regulator is also happy that the needs = of the local regulation have been met. Many times that will come down to th= e view of the local regulator as to whether the situation has been made suf= ficiently clear to the end user. Certainly we need to avoid any assumption that might be provided by the dra= ft that because information A has been released, that information B is also= OK from a privacy consideration. Maybe we need a statement that says any selection needs to meet the privacy= framework imposed on the system, by regulation, by contract, etc. Regards Keith From nobody Tue Apr 5 13:25: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 921A012D12C for ; Tue, 5 Apr 2016 13:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blEfa0t5gmry for ; Tue, 5 Apr 2016 13:25:53 -0700 (PDT) Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (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 108FD12D15D for ; Tue, 5 Apr 2016 13:25:52 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 66B6AC17EF for ; Tue, 5 Apr 2016 20:25:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GSM2I0yVRUi for ; Tue, 5 Apr 2016 20:25:51 +0000 (UTC) Received: from [31.133.178.193] (dhcp-b2c1.meeting.ietf.org [31.133.178.193]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 85F4CC0248 for ; Tue, 5 Apr 2016 20:25:51 +0000 (UTC) Message-ID: <57041F4D.1090808@mozilla.com> Date: Tue, 05 Apr 2016 13:25:49 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [rtcweb] Comments on draft-ietf-rtcweb-fec-03 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, 05 Apr 2016 20:25:55 -0000 Section 4.2: Support for receiving packets with FEC in them is mandatory for Opus. The useinbandfec=1 parameter indicates that the receiver is actually prepared to *use* that data (and thus that the bandwidth overhead is not wasted). The reference to the RTP draft should probably also be updated to point to the final RFC. I'd propose the following text: 'For Opus, a receiver can indicate that it is prepared to use incoming FEC data with the "useinbandfec=1" parameter, as specified in [RFC7587], Section 6.1.' Section 7: I think it's a little unclear what MUST be supported here, particularly for in-band FEC. I believe both Opus and AMR require that all receivers can handle packets with in-band FEC. Are receivers that are WebRTC endpoints required to actually do something with the data they receive (and, e.g., to always set useinbandfec=1 for Opus)? Are senders required to include in-band FEC whenever the receiver asks for it (and network conditions/application requests support it, as indicated in Section 8)? I.e., is this mandatory to support (which in the case of the explicitly named codecs, is already mandatory), or mandatory to use? It might be good to clarify. Whether or not these comments are addressed, I think this document is ready for WGLC. From nobody Tue Apr 5 14:02:01 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 825A812DA0B for ; Tue, 5 Apr 2016 14:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 jqfxc8qN8X2B for ; Tue, 5 Apr 2016 14:01:58 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EE8A12DA04 for ; Tue, 5 Apr 2016 14:01:58 -0700 (PDT) X-AuditID: c1b4fb3a-f79d86d000005b69-44-570427c45c8f Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C7.F4.23401.4C724075; Tue, 5 Apr 2016 23:01:56 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.248.2; Tue, 5 Apr 2016 23:01:54 +0200 To: "rtcweb@ietf.org" , Justin Uberti From: Magnus Westerlund Message-ID: <570427BD.2040506@ericsson.com> Date: Tue, 5 Apr 2016 18:01:49 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM2K7q+4RdZZwg85vGhZbpwpZrP3Xzu7A 5LFgU6nHkiU/mQKYorhsUlJzMstSi/TtErgynl5pYCvYIFvRsPIlSwNjo3gXIyeHhICJxNEf XWwQtpjEhXvrwWwhgSOMEjte53YxcgHZyxglZu/YwAySEBHwluibvo0VxGYTsJC4+aMRrEFY wFBi68qnjCA2r4C2xKRLDewgNouAisSlwx1gcVGBGInj785B1QhKnJz5hKWLkYODWcBe4sHW MpAws4C8RPPW2cwQN2hLNDR1sE5g5JuFpGMWQscsJB0LGJlXMYoWpxYX56YbGemlFmUmFxfn 5+nlpZZsYgSG18Etv612MB587niIUYCDUYmHV0GGOVyINbGsuDL3EKMEB7OSCG+jGku4EG9K YmVValF+fFFpTmrxIUZpDhYlcd6cyH9hQgLpiSWp2ampBalFMFkmDk6pBkbZndPeSU6w/mOq EH1fMf6CpQuv9P4f398GW0i7doYJ2xVc++B9+j3HzjPKTDtXvLfwPvHYxIrt8XmvfW+bJnH+ euByzHLu8eLkPr09SvOyNc+aenqxdD8/ZfXpdXto0dcSfqUI8fezQi5PcRC2ST5lV3xYc3r5 XpbvAUePaa2q/OaV3RLqfFeJpTgj0VCLuag4EQAvgvYYKwIAAA== Archived-At: Subject: [rtcweb] AMR and max-red in draft-ietf-rtcweb-fec 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, 05 Apr 2016 21:02:00 -0000 Hi, As raised in the WG session there are where an open issue if there need to be any specification of the AMR/AMR-WB max-red parameter. So RFC4867 do have the following on offer/answer usage of the parameter: - The parameter "max-red" is a stream property parameter. For send-only or send-recv unicast media streams, the parameter declares the limitation on redundancy that the stream sender will use. For recvonly streams, it indicates the desired value for the stream sent to the receiver. The answerer MAY change the value, but is RECOMMENDED to use the same limitation as the offer declares. In the case of multicast, the offerer MAY declare a limitation; this SHALL be answered using the same value. A media sender using this payload format is RECOMMENDED to always include the "max-red" parameter. This information is likely to simplify the media stream handling in the receiver. This is especially true if no redundancy will be used, in which case "max-red" is set to 0. As this parameter was not defined originally, some senders will not declare this parameter even if it will limit or not send redundancy at all. Most notable is that media senders are RECOMMENDED to include it. Also note that it is the sender that indicates the limitation it intends to adhere to for the streams using this RTP payload type. I also like to note that 3GPP in its specification for its Multimedia Telephony, has specified that one shall not use a value larger than 220 ms, and the value should be a multiple of 20 ms. Please see 3GPP TS 26.114 version 13.3.0 http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/26114-d30.zip So from my perspective I think a WebRTC endpoint simply should follow the AMR RTP Payload specification when supported and include the parameter to indicate the actual upper range of the redundancy it intended to use. It is good to know about the limitation that 3GPP has defined as one likely reason to support AMR/AMR-WB is to be able to interoperate with 3GPP Services. Thus I would suggest that a small addition to the Section 4.3 text and corrections in the first sentence: OLD: For AMR/AMR-WB, support for redundant encoding, and the maximum supported depth, are controlled by the 'max-red' parameter, as specified in [RFC4867], Section 8.1. NEW: For AMR/AMR-WB, support for redundant encoding, and the maximum used depth, is indicated by the 'max-red' parameter, as specified in [RFC4867], Section 8.1 and 8.2. The 3GPP Multimedia Telephony services specifies a maximum value of 220 ms for 'max-red', see [3GPP.26.114]. New Informational Reference: [3GPP.26.114] IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction3GPP 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 Wed Apr 6 01:18:06 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 4D41312D12D for ; Wed, 6 Apr 2016 01:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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 9bTD_kwtGDNg for ; Wed, 6 Apr 2016 01:18:03 -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 7830012D0B7 for ; Wed, 6 Apr 2016 01:18:01 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id A4E92264552; Wed, 6 Apr 2016 10:17:59 +0200 (CEST) Received: from Exchangemail-eme3.itn.ftgroup (unknown [10.114.50.50]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 852AF27C058; Wed, 6 Apr 2016 10:17:59 +0200 (CEST) Received: from OPEXCNORM4C.corporate.adroot.infra.ftgroup ([fe80::347e:851c:671b:3eed]) by OPEXCNORM52.corporate.adroot.infra.ftgroup ([fe80::c482:2589:c116:5790%21]) with mapi id 14.03.0279.002; Wed, 6 Apr 2016 10:17:59 +0200 From: To: Magnus Westerlund , "rtcweb@ietf.org" , Justin Uberti Thread-Topic: [rtcweb] AMR and max-red in draft-ietf-rtcweb-fec Thread-Index: AQHRj35tBYF7jDlHHEyG7ti7A8dS5598mJBA Date: Wed, 6 Apr 2016 08:17:58 +0000 Message-ID: <11040_1459930679_5704C637_11040_8908_1_2842AD9A45C83B44B57635FD4831E60A11E954E6@OPEXCNORM4C.corporate.adroot.infra.ftgroup> References: <570427BD.2040506@ericsson.com> In-Reply-To: <570427BD.2040506@ericsson.com> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.6.74516 Archived-At: Subject: Re: [rtcweb] AMR and max-red in draft-ietf-rtcweb-fec 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, 06 Apr 2016 08:18:05 -0000 Hello Magnus I support your proposal. I would even suggest to relate this to the draft-i= etf-rtcweb-audio-codecs-for-interop (where more information about use of AM= R and AMR-WB is provided ) and specify more explicitly to include it in the= offer/answer with an integer value multiple of 20ms not exceeding 220ms. However, we can stay with your initial proposal if you or anyone else think= s it is preferable. Kind regards St=E9phane OLD: For AMR/AMR-WB, support for redundant encoding, and the maximum supported depth, are controlled by the 'max-red' parameter, as specified in [RFC4867], Section 8.1. NEW: For AMR/AMR-WB, support for redundant encoding, and the maximum used depth, is indicated by the 'max-red' parameter, as specified in [RFC4867], Section 8.1 and 8.2. The 3GPP Multimedia Telephony services specifies a maximum value of 220 ms for 'max-red', see [3GPP.26.114]. If AMR or AMR-WB are offered for interope= rability purpose, see [draft-ietf-rtcweb-audio-codecs-for-interop], the max-red parameter = must be included in the offer and answer and set to an integer value multiple of 20ms. -----Message d'origine----- De=A0: rtcweb [mailto:rtcweb-bounces@ietf.org] De la part de Magnus Westerl= und Envoy=E9=A0: mardi 5 avril 2016 23:02 =C0=A0: rtcweb@ietf.org; Justin Uberti Objet=A0: [rtcweb] AMR and max-red in draft-ietf-rtcweb-fec Hi, As raised in the WG session there are where an open issue if there need to = be any specification of the AMR/AMR-WB max-red parameter. So RFC4867 do have the following on offer/answer usage of the parameter: - The parameter "max-red" is a stream property parameter. For send-only or send-recv unicast media streams, the parameter declares the limitation on redundancy that the stream sender will use. For recvonly streams, it indicates the desired value for the stream sent to the receiver. The answerer MAY change the value, but is RECOMMENDED to use the same limitation as the offer declares. In the case of multicast, the offerer MAY declare a limitation; this SHALL be answered using the same value. A media sender using this payload format is RECOMMENDED to always include the "max-red" parameter. This information is likely to simplify the media stream handling in the receiver. This is especially true if no redundancy will be used, in which case "max-red" is set to 0. As this parameter was not defined originally, some senders will not declare this parameter even if it will limit or not send redundancy at all. Most notable is that media senders are RECOMMENDED to include it. Also note= that it is the sender that indicates the limitation it intends to adhere t= o for the streams using this RTP payload type. I also like to note that 3GPP in its specification for its Multimedia Telep= hony, has specified that one shall not use a value larger than 220 ms, and = the value should be a multiple of 20 ms. Please see 3GPP TS 26.114 version 13.3.0 http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/26114-d30.zip So from my perspective I think a WebRTC endpoint simply should follow the A= MR RTP Payload specification when supported and include the parameter to in= dicate the actual upper range of the redundancy it intended to use. It is g= ood to know about the limitation that 3GPP has defined as one likely reason= to support AMR/AMR-WB is to be able to interoperate with 3GPP Services. Thus I would suggest that a small addition to the Section 4.3 text and corr= ections in the first sentence: OLD: For AMR/AMR-WB, support for redundant encoding, and the maximum supported depth, are controlled by the 'max-red' parameter, as specified in [RFC4867], Section 8.1. NEW: For AMR/AMR-WB, support for redundant encoding, and the maximum used depth, is indicated by the 'max-red' parameter, as specified in [RFC4867], Section 8.1 and 8.2. The 3GPP Multimedia Telephony services specifies a maximum value of 220 ms for 'max-red', see [3GPP.26.114]. New Informational Reference: [3GPP.26.114] IP Multimedia Subsystem (IM= S); Multimedia telephony; Media handling and interaction3GPP Opinions? 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Apr 6 02:28:11 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 36CB112D0BC for ; Wed, 6 Apr 2016 02:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 whdZfRa2azVI for ; Wed, 6 Apr 2016 02:28:06 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A9E612D0B6 for ; Wed, 6 Apr 2016 02:28:06 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id DEFBBC039C; Wed, 6 Apr 2016 11:28:04 +0200 (CEST) Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.60]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id B55794007B; Wed, 6 Apr 2016 11:28:04 +0200 (CEST) Received: from OPEXCNORM4C.corporate.adroot.infra.ftgroup ([fe80::347e:851c:671b:3eed]) by OPEXCNORM74.corporate.adroot.infra.ftgroup ([fe80::fc94:9a93:d000:681d%21]) with mapi id 14.03.0279.002; Wed, 6 Apr 2016 11:28:04 +0200 From: To: Magnus Westerlund , "rtcweb@ietf.org" , Justin Uberti Thread-Topic: [rtcweb] AMR and max-red in draft-ietf-rtcweb-fec Thread-Index: AQHRj35tBYF7jDlHHEyG7ti7A8dS5598mJBAgAAVI/A= Date: Wed, 6 Apr 2016 09:28:04 +0000 Message-ID: <10237_1459934884_5704D6A4_10237_1748_1_2842AD9A45C83B44B57635FD4831E60A11E96567@OPEXCNORM4C.corporate.adroot.infra.ftgroup> References: <570427BD.2040506@ericsson.com> <11040_1459930679_5704C637_11040_8908_1_2842AD9A45C83B44B57635FD4831E60A11E954E6@OPEXCNORM4C.corporate.adroot.infra.ftgroup> In-Reply-To: <11040_1459930679_5704C637_11040_8908_1_2842AD9A45C83B44B57635FD4831E60A11E954E6@OPEXCNORM4C.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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] AMR and max-red in draft-ietf-rtcweb-fec 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, 06 Apr 2016 09:28:09 -0000 Sorry, the last part of the sentence in the proposal was missing : the ma= x-red parameter must be included in the offer and answer and set to an integer value multiple of 20ms not = exceeding 220ms. OLD: For AMR/AMR-WB, support for redundant encoding, and the maximum supported depth, are controlled by the 'max-red' parameter, as specified in [RFC4867], Section 8.1. NEW: For AMR/AMR-WB, support for redundant encoding, and the maximum used depth, is indicated by the 'max-red' parameter, as specified in [RFC4867], Section 8.1 and 8.2. The 3GPP Multimedia Telephony services specifies a maximum value of 220 ms for 'max-red', see [3GPP.26.114]. If AMR or AMR-WB are offered for interope= rability purpose, see [draft-ietf-rtcweb-audio-codecs-for-interop], the max-red parameter = must be included in the offer and answer and set to an integer value multiple of 20ms not = exceeding 220ms. -----Message d'origine----- De=A0: rtcweb [mailto:rtcweb-bounces@ietf.org] De la part de stephane.prous= t@orange.com Envoy=E9=A0: mercredi 6 avril 2016 10:18 =C0=A0: Magnus Westerlund; rtcweb@ietf.org; Justin Uberti Objet=A0: Re: [rtcweb] AMR and max-red in draft-ietf-rtcweb-fec Hello Magnus I support your proposal. I would even suggest to relate this to the draft-i= etf-rtcweb-audio-codecs-for-interop (where more information about use of AM= R and AMR-WB is provided ) and specify more explicitly to include it in the= offer/answer with an integer value multiple of 20ms not exceeding 220ms. However, we can stay with your initial proposal if you or anyone else think= s it is preferable. Kind regards St=E9phane OLD: For AMR/AMR-WB, support for redundant encoding, and the maximum supported depth, are controlled by the 'max-red' parameter, as specified in [RFC4867], Section 8.1. NEW: For AMR/AMR-WB, support for redundant encoding, and the maximum used depth, is indicated by the 'max-red' parameter, as specified in [RFC4867], Section 8.1 and 8.2. The 3GPP Multimedia Telephony services specifies a maximum value of 220 ms for 'max-red', see [3GPP.26.114]. If AMR or AMR-WB are offered for interope= rability purpose, see [draft-ietf-rtcweb-audio-codecs-for-interop], the max-red parameter = must be included in the offer and answer and set to an integer value multiple of 20ms. -----Message d'origine----- De=A0: rtcweb [mailto:rtcweb-bounces@ietf.org] De la part de Magnus Westerl= und Envoy=E9=A0: mardi 5 avril 2016 23:02 =C0=A0: rtcweb@ietf.org; Justin U= berti Objet=A0: [rtcweb] AMR and max-red in draft-ietf-rtcweb-fec Hi, As raised in the WG session there are where an open issue if there need to = be any specification of the AMR/AMR-WB max-red parameter. So RFC4867 do have the following on offer/answer usage of the parameter: - The parameter "max-red" is a stream property parameter. For send-only or send-recv unicast media streams, the parameter declares the limitation on redundancy that the stream sender will use. For recvonly streams, it indicates the desired value for the stream sent to the receiver. The answerer MAY change the value, but is RECOMMENDED to use the same limitation as the offer declares. In the case of multicast, the offerer MAY declare a limitation; this SHALL be answered using the same value. A media sender using this payload format is RECOMMENDED to always include the "max-red" parameter. This information is likely to simplify the media stream handling in the receiver. This is especially true if no redundancy will be used, in which case "max-red" is set to 0. As this parameter was not defined originally, some senders will not declare this parameter even if it will limit or not send redundancy at all. Most notable is that media senders are RECOMMENDED to include it. Also note= that it is the sender that indicates the limitation it intends to adhere t= o for the streams using this RTP payload type. I also like to note that 3GPP in its specification for its Multimedia Telep= hony, has specified that one shall not use a value larger than 220 ms, and = the value should be a multiple of 20 ms. Please see 3GPP TS 26.114 version 13.3.0 http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/26114-d30.zip So from my perspective I think a WebRTC endpoint simply should follow the A= MR RTP Payload specification when supported and include the parameter to in= dicate the actual upper range of the redundancy it intended to use. It is g= ood to know about the limitation that 3GPP has defined as one likely reason= to support AMR/AMR-WB is to be able to interoperate with 3GPP Services. Thus I would suggest that a small addition to the Section 4.3 text and corr= ections in the first sentence: OLD: For AMR/AMR-WB, support for redundant encoding, and the maximum supported depth, are controlled by the 'max-red' parameter, as specified in [RFC4867], Section 8.1. NEW: For AMR/AMR-WB, support for redundant encoding, and the maximum used depth, is indicated by the 'max-red' parameter, as specified in [RFC4867], Section 8.1 and 8.2. The 3GPP Multimedia Telephony services specifies a maximum value of 220 ms for 'max-red', see [3GPP.26.114]. New Informational Reference: [3GPP.26.114] IP Multimedia Subsystem (IM= S); Multimedia telephony; Media handling and interaction3GPP Opinions? 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 ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Apr 6 06:18:48 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 2725512D517; Wed, 6 Apr 2016 06:18:47 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160406131847.24917.83593.idtracker@ietfa.amsl.com> Date: Wed, 06 Apr 2016 06:18:47 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-alpn-03.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, 06 Apr 2016 13:18:47 -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 : Application Layer Protocol Negotiation for Web Real-Time Communications (WebRTC) Author : Martin Thomson Filename : draft-ietf-rtcweb-alpn-03.txt Pages : 7 Date : 2016-04-05 Abstract: Application Layer Protocol Negotiation (ALPN) labels are defined for use in identifying Web Real-Time Communications (WebRTC) usages of Datagram Transport Layer Security (DTLS). Labels are provided for identifying a session that uses a combination of WebRTC compatible media and data, and for identifying a session requiring confidentiality protection from web applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-alpn/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-alpn-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-alpn-03 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 Apr 6 15:27: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 95EA112D101 for ; Wed, 6 Apr 2016 15:27:02 -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 U-_iqYwt7CWt for ; Wed, 6 Apr 2016 15:27:00 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::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 1456A12D0A3 for ; Wed, 6 Apr 2016 15:27:00 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id e6so76998345vkh.2 for ; Wed, 06 Apr 2016 15:27:00 -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=A+S0UaI1BcAI0mKErH0GUF1EpJLxJbAxSjKVIyLkMF0=; b=EhEU/RSZ4fFAtVzRNgUq3xDBV7duAMyLAhuFHqj79bJCTDmNzMjUOsBsMj/fT0SZjP GqGbLbR1fHkSzbQxQsuKjicAtD6tUrr3HgrETC7k9Q9sEzTH6XZJQxuW9IjkSWr6hVbR NQnbKga8ODjxMu7vo3LSB8l77S4zv2QGljmJHBvkMeCpgmOBnuERWJ4gELAxEURq4jer qm4RfarPS5lWFcERdGahWr2V3tB7upz9b9KNJ10D3zEJ3tOtTJR5U6TWA9dO3ron9dpq ds7JvbYZ0Xh/Hj8A3jBTcjOHBbCJdjc1AS7SjRWJhxH/VzSjbjmLixrDl7syUY+qrq+P PWsQ== 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=A+S0UaI1BcAI0mKErH0GUF1EpJLxJbAxSjKVIyLkMF0=; b=Oo6AEOCu0uT31+jWSrCvdgqhXAR3VEF2gOrAmJIkuq4p6eJ22wbph/0DuJ6Ojg2Lyf KazN/+BBBRy7aERARZTrtXwXHkMmdmdBAXqLRUTF/2JD3J+mhzeqycEuDaLWQ+9dF5W8 kgMNd3AjpH7HHxHy90ZNP19FU/wBBHvu/5yaLDqu3fRDXCh3xcIChLQ9s9tWU6aSfJSk /64nhT4naL0N0aMSEexS+2wjPQ7MUig9a5X7nPCOYZ75EbMieEln70k9mik7MaOgrcmu XzpRIJbbCi58AgE+rJ23vI5JB7080RaElK/F0Z+dVEPIpXhgq/HSsduEd5XMVwK9exdN cJNQ== X-Gm-Message-State: AD7BkJLL38QVVH4sd9ERh5Qb7KERhBm79I54mzTm+z3ActAz7mYqPh60Cscf90gyIYnlron6AD4A9LNKVXRJEQ== X-Received: by 10.31.147.82 with SMTP id v79mr3490668vkd.58.1459981619128; Wed, 06 Apr 2016 15:26:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.40 with HTTP; Wed, 6 Apr 2016 15:26:39 -0700 (PDT) From: Bernard Aboba Date: Wed, 6 Apr 2016 15:26:39 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a1141dca2c96fe4052fd87563 Archived-At: Subject: [rtcweb] Review of draft-ietf-rtcweb-fec-03 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, 06 Apr 2016 22:27:02 -0000 --001a1141dca2c96fe4052fd87563 Content-Type: text/plain; charset=UTF-8 Section 3.3 Note that this mechanism can only carry redundancy information for the immediately preceding packet; as such the decoder cannot fully recover multiple consecutive lost packets. [BA] In our experience, this has turned out to be a significant problem on wireless networks where burst loss is common. Section 4.1 When using the Opus codec, use of the built-in Opus FEC mechanism is RECOMMENDED. This provides reasonable protection of the audio stream against typical losses, with modest overhead. Note that as indicated above the built-in Opus FEC only provides single-frame redundancy; if multi-packet protection is needed, the built-in FEC should be combined with [RFC2198 ] redundancy to protect the N-2th, N-3rd, etc. packets. Because of the lower packet rate of audio encodings, usually a single packet per frame, use of a separate FEC stream comes with a higher overhead than other mechanisms, and therefore is NOT RECOMMENDED. [BA] In our implementation, we have found that using external FEC supporting burst loss resilience provides audio quality superior to RFC 2198 redundancy with less overhead, iff the level of protection can be dynamically adjusted (e.g. it is only used if needed). Since that is recommended in Section 8, NOT RECOMMENDED seems too harsh. Maybe optional? Section 5.1 For video content, use of a separate FEC stream with the RTP payload format described in [I-D.ietf-payload-flexible-fec-scheme ] is RECOMMENDED. [BA] The above RECOMMENDED seems to be contradicted by a MUST in Section 7. Section 7 To support the functionality recommended above, implementations MUST support the relevant mechanisms for their supported audio codecs, as described in Section 4 , and the general FEC mechanism described in [I-D.ietf-payload-flexible-fec-scheme ]. Implementations MAY support additional FEC mechanisms if desired, e.g. [RFC5109 ]. [BA] The above paragraph seems to indicate that flex fec is a MUST, rather than merely RECOMMENDED. Personally, I think a MUST for flex fec is too much, and that since existing implementations support ulpfec, this should be upgraded to RECOMMENDED. RECOMMENDED seems more suitable for flexible fec since we don't have much implementation experience yet. My recommendation would be to wait to publish the flex fec document until we had some implementation experience, since if the flex fec goes to RFC before that we could have some surprises (including late IPR declarations) that might lead us to regret publishing early. Section 8 Given this, WebRTC implementations SHOULD only transmit the amount of FEC needed to protect against the observed packet loss (which can be determined, e.g., by monitoring transmit packet loss data from RTCP Receiver Reports [RFC3550 ]), or the application indicates it is willing to pay a quality penalty to proactively avoid losses. [BA] Very much in agreement with this - particularly since RTX can be a quite viable robustness mechanism, particularly when combined with temporal scalability. Where RTX is not sufficient (e.g. RTT is too high), it might be worth mentioning selective FEC protection (e.g. of the base layer only). Since VP8, VP9 and future video codecs can all benefit from this, it's not that esoteric. --001a1141dca2c96fe4052fd87563 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Section 3.3

   Note that=
 this mechanism can only carry redundancy information for the
   immediately preceding packet; as such the decoder cannot fully
   recover multiple consecutive lost packets.
[BA] In our experience, this has turned out to =
be a significant problem
on wireless networks whe=
re burst loss is common. 

Section 4.1

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

   Because of the lower packet rate =
of audio encodings, usually a single
   packet per frame, use of a separate FEC stream comes with a higher
   overhead than other mechanisms, and therefore is NOT RECOMMENDED.
<=
/pre>

[BA] In our implementation, we have found that using=
 external FEC 
supporting burst loss resilience provides audio qua=
lity superior
to RFC 2198 redundancy with less overhead,=C2=A0iff =
the level of
protection can be dynamically adjusted (e.g. it is on=
ly used if
needed). Since that is recommended in Section 8, NOT RE=
COMMENDED=C2=A0
seems too harsh. Maybe optional?

Section 5.1

   For video content, us=
e of a separate FEC stream with the RTP payload
   format described in [I-D.ietf-payload-fle=
xible-fec-scheme] is
   RECOMMENDED. 

[BA] The above RECOMMENDED se=
ems to be contradicted by a MUST in
Section 7. 
Section 7

 To support the functi=
onality recommended above, implementations MUST
   support the relevant mechanisms for their supported audio codecs, as
   described in Section 4, and the general FEC mechanism described in
   [I-D.ietf-payload-flexible-fec-scheme=
].

   Implementations MAY support additional FEC mechanisms if desired,
   e.g.  [RFC5109].


[BA] The above paragraph seems to indicate that f=
lex fec is a MUST,
rather than merely RECOMMENDED.  Personally, I=
 think a MUST for
flex fec is too much, and that since existing i=
mplementations support
ulpfec, this should be upgraded to RECOMME=
NDED.=C2=A0

RECOMMENDED seems more suitable for=
 flexible fec since we don't have much
implementation experien=
ce yet.  My recommendation would be to wait to
publish the flex =
fec document until we had some implementation
experience, since if=
 the flex fec goes to RFC before that we could
have some surpris=
es (including late IPR declarations) that might lead
us to regret =
publishing early. 

Section 8

=

   Given this, WebRTC
   implementations SHOULD only transmit the amount of FEC needed to
   protect against the observed packet loss (which can be determined,
   e.g., by monitoring transmit packet loss data from RTCP Receiver
   Reports [RFC3550]), =
or the application indicates it is willing to pay
   a quality penalty to proactively avoid losses.
[BA] Very much in agreement with this - particularly since RTX =
can
be a quite viable robustness mechanism, particularly when com=
bined
with temporal scalability.  Where RTX is not sufficient (e.=
g. RTT
is too high), it might be worth mentioning selective FEC p=
rotection
(e.g. of the base layer only).   Since VP8, VP9 and fut=
ure video
codecs can all benefit from this, it's not that eso=
teric.


--001a1141dca2c96fe4052fd87563-- From nobody Thu Apr 7 07:27:04 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 BCA0A12D97A; Thu, 7 Apr 2016 07:27:02 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160407142702.19836.9518.idtracker@ietfa.amsl.com> Date: Thu, 07 Apr 2016 07:27:02 -0700 Archived-At: Cc: draft-ietf-rtcweb-alpn@ietf.org, turners@ieca.com, rtcweb-chairs@ietf.org, rtcweb@ietf.org Subject: [rtcweb] Last Call: (Application Layer Protocol Negotiation for Web Real-Time Communications (WebRTC)) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-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, 07 Apr 2016 14:27:03 -0000 The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'Application Layer Protocol Negotiation for Web Real-Time Communications (WebRTC)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-04-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Application Layer Protocol Negotiation (ALPN) labels are defined for use in identifying Web Real-Time Communications (WebRTC) usages of Datagram Transport Layer Security (DTLS). Labels are provided for identifying a session that uses a combination of WebRTC compatible media and data, and for identifying a session requiring confidentiality protection from web applications. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-alpn/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-alpn/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Apr 7 07:44:43 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 05FEE12D7F3 for ; Thu, 7 Apr 2016 07:44:41 -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 UCVW_dspR3d7 for ; Thu, 7 Apr 2016 07:44:38 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DE0D12D9AF for ; Thu, 7 Apr 2016 07:30:36 -0700 (PDT) X-AuditID: c1b4fb2d-f79c06d000005960-23-57066f0ab844 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CF.20.22880.A0F66075; Thu, 7 Apr 2016 16:30:35 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.248.2; Thu, 7 Apr 2016 16:30:33 +0200 To: , "rtcweb@ietf.org" , Justin Uberti References: <570427BD.2040506@ericsson.com> <11040_1459930679_5704C637_11040_8908_1_2842AD9A45C83B44B57635FD4831E60A11E954E6@OPEXCNORM4C.corporate.adroot.infra.ftgroup> <10237_1459934884_5704D6A4_10237_1748_1_2842AD9A45C83B44B57635FD4831E60A11E96567@OPEXCNORM4C.corporate.adroot.infra.ftgroup> From: Magnus Westerlund Message-ID: <57066F04.3090904@ericsson.com> Date: Thu, 7 Apr 2016 11:30:28 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <10237_1459934884_5704D6A4_10237_1748_1_2842AD9A45C83B44B57635FD4831E60A11E96567@OPEXCNORM4C.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM2J7iC53Plu4waKnzBZbpwpZrP3Xzm7R OuMKmwOzx4JNpR5Llvxk8mh5dpItgDmKyyYlNSezLLVI3y6BK+Pqkmamgm0+FZP7ZzE2MK6x 7WLk5JAQMJE4fucPO4QtJnHh3nq2LkYuDiGBI4wSE248YQZJCAksY5Q4d6UYxBYWsJOYubID rEFEIFui8dgEVoiGlUwSR1bcBGtgE7CQuPmjkQ3E5hXQlrj/4RMriM0ioCKx88BxsLioQIzE 8XfnGCFqBCVOznzCAjKIU6CTUWLi7c9AGzg4mAXsJR5sLQOpYRaQl2jeOhvqIG2JhqYO1gmM ArOQtM9C6JiFpGMBI/MqRtHi1OLi3HQjY73Uoszk4uL8PL281JJNjMAwPbjlt+4OxtWvHQ8x CnAwKvHwKuxnDRdiTSwrrsw9xCjBwawkwrsgky1ciDclsbIqtSg/vqg0J7X4EKM0B4uSOG9O 5L8wIYH0xJLU7NTUgtQimCwTB6dUA6Oq1GWhk84Cwv83eVWJntv79oYz32oe2zuWXm21J8vO c23ZLPWLV2dH5Ke4RZsmpUxgl+ldZsNXyr1nXnSjz/7KD9oPBX0rgvinWF6N/5BZG23O9T1Q 01xkn9rE9wnXTh17qSb5J/bYyQ/Xp26adjTyZcfMoK/7Nt9ZY39nwpNAlZhfjD85i12VWIoz Eg21mIuKEwGLhPvuTwIAAA== Archived-At: Subject: Re: [rtcweb] AMR and max-red in draft-ietf-rtcweb-fec 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, 07 Apr 2016 14:44:41 -0000 Hi, I am generally fine with Stephane's proposal. I do note that the "must" in the last sentence probably need to be a "MUST", otherwise if the intention is just to point to requirements that exists, then please reformulate this to not use RFC2119 terms, even in lower cases. Cheers Magnus Den 2016-04-06 kl. 06:28, skrev stephane.proust@orange.com: > Sorry, the last part of the sentence in the proposal was missing : the max-red parameter must be included > in the offer and answer and set to an integer value multiple of 20ms not exceeding 220ms. > > OLD: > For AMR/AMR-WB, support for redundant encoding, and the maximum > supported depth, are controlled by the 'max-red' parameter, as > specified in [RFC4867], Section 8.1. > > NEW: > For AMR/AMR-WB, support for redundant encoding, and the maximum > used depth, is indicated by the 'max-red' parameter, as > specified in [RFC4867], Section 8.1 and 8.2. The 3GPP Multimedia > Telephony services specifies a maximum value of 220 ms for > 'max-red', see [3GPP.26.114]. If AMR or AMR-WB are offered for interoperability purpose, > see [draft-ietf-rtcweb-audio-codecs-for-interop], the max-red parameter must be included > in the offer and answer and set to an integer value multiple of 20ms not exceeding 220ms. > > -----Message d'origine----- > De : rtcweb [mailto:rtcweb-bounces@ietf.org] De la part de stephane.proust@orange.com > Envoyé : mercredi 6 avril 2016 10:18 > Ŕ : Magnus Westerlund; rtcweb@ietf.org; Justin Uberti > Objet : Re: [rtcweb] AMR and max-red in draft-ietf-rtcweb-fec > > Hello Magnus > > I support your proposal. I would even suggest to relate this to the draft-ietf-rtcweb-audio-codecs-for-interop (where more information about use of AMR and AMR-WB is provided ) and specify more explicitly to include it in the offer/answer with an integer value multiple of 20ms not exceeding 220ms. > However, we can stay with your initial proposal if you or anyone else thinks it is preferable. > > Kind regards > > Stéphane > > OLD: > For AMR/AMR-WB, support for redundant encoding, and the maximum > supported depth, are controlled by the 'max-red' parameter, as > specified in [RFC4867], Section 8.1. > > NEW: > For AMR/AMR-WB, support for redundant encoding, and the maximum > used depth, is indicated by the 'max-red' parameter, as > specified in [RFC4867], Section 8.1 and 8.2. The 3GPP Multimedia > Telephony services specifies a maximum value of 220 ms for > 'max-red', see [3GPP.26.114]. If AMR or AMR-WB are offered for interoperability purpose, > see [draft-ietf-rtcweb-audio-codecs-for-interop], the max-red parameter must be included > in the offer and answer and set to an integer value multiple of 20ms. > > -----Message d'origine----- > De : rtcweb [mailto:rtcweb-bounces@ietf.org] De la part de Magnus Westerlund Envoyé : mardi 5 avril 2016 23:02 Ŕ : rtcweb@ietf.org; Justin Uberti Objet : [rtcweb] AMR and max-red in draft-ietf-rtcweb-fec > > Hi, > > As raised in the WG session there are where an open issue if there need to be any specification of the AMR/AMR-WB max-red parameter. > > So RFC4867 do have the following on offer/answer usage of the parameter: > > - The parameter "max-red" is a stream property parameter. For > send-only or send-recv unicast media streams, the parameter > declares the limitation on redundancy that the stream sender > will use. For recvonly streams, it indicates the desired value > for the stream sent to the receiver. The answerer MAY change > the value, but is RECOMMENDED to use the same limitation as the > offer declares. In the case of multicast, the offerer MAY > declare a limitation; this SHALL be answered using the same > value. A media sender using this payload format is RECOMMENDED > to always include the "max-red" parameter. This information is > likely to simplify the media stream handling in the receiver. > This is especially true if no redundancy will be used, in which > case "max-red" is set to 0. As this parameter was not defined > originally, some senders will not declare this parameter even > if it will limit or not send redundancy at all. > > Most notable is that media senders are RECOMMENDED to include it. Also note that it is the sender that indicates the limitation it intends to adhere to for the streams using this RTP payload type. > > I also like to note that 3GPP in its specification for its Multimedia Telephony, has specified that one shall not use a value larger than 220 ms, and the value should be a multiple of 20 ms. Please see 3GPP TS > 26.114 version 13.3.0 > http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/26114-d30.zip > > So from my perspective I think a WebRTC endpoint simply should follow the AMR RTP Payload specification when supported and include the parameter to indicate the actual upper range of the redundancy it intended to use. It is good to know about the limitation that 3GPP has defined as one likely reason to support AMR/AMR-WB is to be able to interoperate with 3GPP Services. > > Thus I would suggest that a small addition to the Section 4.3 text and corrections in the first sentence: > > OLD: > For AMR/AMR-WB, support for redundant encoding, and the maximum > supported depth, are controlled by the 'max-red' parameter, as > specified in [RFC4867], Section 8.1. > > NEW: > For AMR/AMR-WB, support for redundant encoding, and the maximum > used depth, is indicated by the 'max-red' parameter, as > specified in [RFC4867], Section 8.1 and 8.2. The 3GPP Multimedia > Telephony services specifies a maximum value of 220 ms for > 'max-red', see [3GPP.26.114]. > > > New Informational Reference: > > [3GPP.26.114] > > IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction3GPP day="17" month="March" year="2016"/> value="26.114 13.3.0"/> target="http://www.3gpp.org/ftp/Specs/html-info/26114.htm"/> > > 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 > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > -- 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 Apr 7 08:15: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 5254112D5DF for ; Thu, 7 Apr 2016 08:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 GiXHgTKitSve for ; Thu, 7 Apr 2016 08:15:46 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c: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 A48CE12D85D for ; Thu, 7 Apr 2016 08:03:43 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id k1so102601832vkb.0 for ; Thu, 07 Apr 2016 08:03:43 -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=O1aFhActtd3zaAfeHEPGdT40Oq8M26ovU/gjINrTNt4=; b=DwPaf/5Ulrm0GRQJXIX+NnW0eAmv/8ADdE3Di+p95jK8P6rInBxGWCRNSilSQAgrKs Ufqa5t9d6sOompaveeVNfsZBv7JK7lL9+y/FllwWXQ6MRmB5g0Q0PX2MRRfV4ur2jPfo bixQ2Ur1Cpl45ssfwOEeQLHzqeeh2LdEJoU1g2GVgqO5cGzf242b3yGxsHcwW491fy/7 6fUzvtpdbc7FnzdIp+W4DdaEFjyUTA7qxjTf8NJnLjh8Z1gSZ3xMVIrYPsZ1Zrs2NUsM Q6lnjU2jopSZ/9C63Uws6uXoX12Q77B4Y9I3xxVjvw8F0ri9yveQoB/+bzjIcdKpCSn6 77Rw== 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=O1aFhActtd3zaAfeHEPGdT40Oq8M26ovU/gjINrTNt4=; b=M+UeXCq293t405lPvRcmezInOzT5g/w6XZp3ybYK/qgjOxHgKkPENLsvQg+NwI8Z6f bi9gO1ownNPJEhGrEvlmtCPkSOzGTYZnPvMtJLysk1g0DVpeLLgodzXNd3///FtKbw6I VwhYQOzJ88Coj0keVG7d7eIoioM7af0byMFPexj9MStKL97AQY1ife8g4q3Jnqcpa6RJ CuZYu5Z0KO9kwl3VX/X6XRl6jHdZLLav6VJ7YDtiN2VEH0tOasr0OmAEvguWkWMILc25 8jZxfLODD3lo6zTf62MlxPhRMbNQkErFJr5doJEgBBgXPSq38BRO579mK25sYjplhJ6u QNlQ== X-Gm-Message-State: AD7BkJLHl72zSpmRHwjnrDkpOAjbhsBfWpKzANPXN5XR9zwd1PLf2lhF55EM+PfWsYiWIvBU6Edxt2hbE+4KQTQ0 X-Received: by 10.31.11.201 with SMTP id 192mr1603902vkl.135.1460041422620; Thu, 07 Apr 2016 08:03:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.67.164 with HTTP; Thu, 7 Apr 2016 08:03:02 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Thu, 7 Apr 2016 08:03:02 -0700 Message-ID: To: Tim Panton Content-Type: multipart/alternative; boundary=001a114551525aa568052fe662ec Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [rtcweb] [MMUSIC] Tunnelling DTLS in SDP 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, 07 Apr 2016 15:15:48 -0000 --001a114551525aa568052fe662ec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 5, 2016 at 2:52 AM, Tim Panton wrote: > > On 5 Apr 2016, at 03:06, Justin Uberti wrote: > > > > On Mon, Apr 4, 2016 at 8:39 AM, pfh wrote: > >> >> On 4 Apr 2016, at 14:10, Eric Rescorla wrote: >> >> Hi folks, >> >> I wanted to call your attention to a draft I just published with a >> possibly stupid >> idea. >> >> https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 >> >> A nontrivial fraction of call setup time in WebRTC is the DTLS handshake= . >> This document describes how to piggyback the first few handshake message= s >> in the SDP offer/answer exchange, thus reducing latency. >> >> >> It strikes me we could get the same reduced latency benefits by >> piggybacking on ICE >> rather than SDP, e.g. embedding the DTLS packet as data in a new STUN >> attribute type. >> >> The downside of piggybacking on the SDP is that you are increasing the >> trust you have to place in the >> signalling server undermining the elegant decoupling we have at the >> moment between signalling and >> media. (The SDES issues of logging keys in the web servers apply to the >> public certs as well). >> > > I don't think the logging issue applies here. Only the public key would b= e > logged, and it's already transmitted in cleartext during a normal DTLS > handshake (it's a public key, after all). > > > True, but over a different path. > > >> It also significantly clutters the SDP (even more) ! >> > > Please see Jonathan Lennox's comment about garbage piles. I think the onl= y > truly unattractive part here is the fact that the messages will need to b= e > base64ed, resulting in minor blowup. But that seems like a reasonable > downside for 1+ RTT upside. > > > Just when the WebRTC NG was freeing us from Offer/Answer and SDP=E2=80=A6= . > > Sigh. > > =E2=80=8BThe general idea here is "put the beginning of the crypto handshak= e in the signaling"=E2=80=8B. That's not tied to SDP. WebRTC NG could easily do th= e same thing without SDP. > > > >> As you point out, it weakens the usefulness of longer term certs, which >> would be a major nuisance IMHO. >> >> Tim. >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a114551525aa568052fe662ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 5, 2016 at 2:52 AM, Tim Panton &= lt;tim@phonefrom= here.com> wrote:

On 5 Apr 2016, at 03:06, Justin Uberti <juberti@google.com> wrote:


On Mon, Apr 4, 2016 at 8:39 AM, pfh <tim@phonefromhere.com<= /a>> wrote:


Hi folks,<= div>
I wanted to call your attention to a draft I just publis= hed with a possibly stupid
idea.

https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00

A nontrivial fraction of call setup time in WebRTC is= the DTLS handshake.
This document describes how to piggyback the= first few handshake messages
in the SDP offer/answer exchange, t= hus reducing latency.

<= div>It strikes me we could get the same reduced latency benefits by piggyba= cking on ICE
rather than SDP, e.g. embedding the DTLS packet as d= ata in a new STUN attribute type.

The downside of = piggybacking on the SDP is that you are increasing the trust you have to pl= ace in the
signalling server undermining the elegant decoupling w= e have at the moment between signalling and=C2=A0
media. (The SDE= S issues of logging keys in the web servers apply to the public certs as we= ll).

I don't think th= e logging issue applies here. Only the public key would be logged, and it&#= 39;s already transmitted in cleartext during a normal DTLS handshake (it= 9;s a public key, after all).=C2=A0

True, but over a different path.=C2=A0
<= span class=3D"">

It also sig= nificantly clutters the SDP (even more) !

Please see Jonathan Lennox's comment about garbage pil= es. I think the only truly unattractive part here is the fact that the mess= ages will need to be base64ed, resulting in minor blowup. But that seems li= ke a reasonable downside for 1+ RTT upside.

Just when the WebRTC NG was freeing us fro= m Offer/Answer and SDP=E2=80=A6.

Sigh.


= =E2=80=8BThe general idea here is "put the beginning of the crypto han= dshake in the signaling"=E2=80=8B.=C2=A0 That's not tied to SDP.= =C2=A0 WebRTC NG could easily do the same thing without SDP.=C2=A0
=C2=A0

<= br>

As you point out, it weakens the usefulness of lo= nger term certs, which
would be a major nuisance IMHO.
=
Tim.


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




_____________________________= __________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


--001a114551525aa568052fe662ec-- From nobody Thu Apr 7 08:19:24 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 278D912D55C for ; Thu, 7 Apr 2016 08:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 GZ0WyF2fZ3Ro for ; Thu, 7 Apr 2016 08:19:14 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::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 2446E12D8A7 for ; Thu, 7 Apr 2016 08:07:51 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id c4so102748577vkb.3 for ; Thu, 07 Apr 2016 08:07:51 -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=x4C4YndQd/mhmdeQcdULRJVTIxvP0nMFSZAC+lxw3kg=; b=fan0WhPz5t7jfQnrGI8PJLZPZSpshbW39WHwmlTFR4rUWyJVQjeQgiclkqG0/swPj2 7DiaSnAROKoX7KvKjLWQVw06zj3IP1B36ENIzInjSS16QEH2Im78Ay+uNoiN24pMZxaH QNEXMMc3k+x7/5ZMW+yZgI6wAqwRJVI2pMZLhjHLjpdwhVq+av4OsUgq/i7BLgVNYmtC yLshjqAIys/Zq3B+KYg1jM91Bl0cA8iFMfq9zE5pmjcWtJRpGECV95h0AzQWgu7X3raH TW6wHQjxQPto6OtqsMbKTbgusrQr8jWABv8+CHZcThbq/Ih24D4UGoskrzrUzZjRwx3u 68RQ== 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=x4C4YndQd/mhmdeQcdULRJVTIxvP0nMFSZAC+lxw3kg=; b=QtgsgUZtSkOUHQ0xe5gMQFG8rSNIhGOsM4xKBURs8TAKy0cTiI0LBhMXoFxv1gyHEq 4quEDnXhCl9BnSD4QWO/h0F6HqI/WZmVFnZayrtinsNI3plwrrm3XXwjwFZZRVIzryQj yfnS4922IHUr2V+UkN3hDJuwTTjlmON9XJeJgfsHdIChzZ6i99xjYDNVf7uSyFDGwPPA aDk/2UCnG3J8M38cHETxYigMO0rePlq8/bt89V35nJCu2vNF896EHQKOZNbFXR95aNTq VFHq/FV4UyEasnPlPrL3ENBkJdiBBCtCIZEuSUhyTwHJrmGrMbfZ/ms2QhBm1JEFf2vB i1Vg== X-Gm-Message-State: AD7BkJLlFrf6EqGspCfW3IqKwpk4mHgUbu7/c54i/iRRi01ellUcjrTaAFETvGASugZUqlr5j5bqJ1jP9E+PX5SJ X-Received: by 10.31.194.10 with SMTP id s10mr1665195vkf.72.1460041670119; Thu, 07 Apr 2016 08:07:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.67.164 with HTTP; Thu, 7 Apr 2016 08:07:10 -0700 (PDT) In-Reply-To: <57038B35.8040102@alvestrand.no> References: <57038B35.8040102@alvestrand.no> From: Peter Thatcher Date: Thu, 7 Apr 2016 08:07:10 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a114661dc1b5c01052fe6710d Archived-At: Cc: "" Subject: Re: [rtcweb] Tunnelling DTLS in SDP 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, 07 Apr 2016 15:19:19 -0000 --001a114661dc1b5c01052fe6710d Content-Type: text/plain; charset=UTF-8 On Tue, Apr 5, 2016 at 2:53 AM, Harald Alvestrand wrote: > On first read, this makes sense to me. > > I wonder if it could/should be made into a general concept, to fit with > the tendency in WebRTC:NG to separate signalling format even more from > operation? > > We could call it "out of band DTLS setup", say that in general, a DTLS > session can be started in one medium (SDP signalling, in this case), and > continued in another medium (the DTLS-protected media channel), and have a > section describing the details of carrying DTLS-over-SDP. > > When viewing it in this way, using the same technique with Jabber or > proprietary signalling becomes a reasonably obvious exercise. There are > some other twists that seem obvious too - for instance, one could continue > the setup over the SDP channel in subsequent offer/answers if the first > exchange failed to set up a media channel. I'm not sure that makes sense, > though. > In ORTC language, we could simply have an event on the DtlsTransport that is something like .onpacket and another that's .addpacket, and when the transport wants to send a packet, it lets the JS know so it can do so over the signalling path, and then the JS can take care of optimizing it (or not). > > One SDP twist: If forking happens, it could be treated like any other > attempt to generate multiple answers to a ClientHello, I think. I'm sure > it's well defined how to respond to that - it's an obvious attack. Only one > leg of the fork would ever succeed, I assume. > > > > On 04/04/2016 03:10 PM, Eric Rescorla wrote: > > Hi folks, > > I wanted to call your attention to a draft I just published with a > possibly stupid > idea. > > https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 > > A nontrivial fraction of call setup time in WebRTC is the DTLS handshake. > This document describes how to piggyback the first few handshake messages > in the SDP offer/answer exchange, thus reducing latency. > > Comments welcome. > > -Ekr > > > > > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb > > > > -- > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a114661dc1b5c01052fe6710d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 5, 2016 at 2:53 AM, Harald Alvestrand <harald@= alvestrand.no> wrote:
=20 =20 =20
On first read, this makes sense to me.

I wonder if it could/should be made into a general concept, to fit with the tendency in WebRTC:NG to separate signalling format even more from operation?

We could call it "out of band DTLS setup", say that in gene= ral, a DTLS session can be started in one medium (SDP signalling, in this case), and continued in another medium (the DTLS-protected media channel), and have a section describing the details of carrying DTLS-over-SDP.=C2=A0

When viewing it in this way, using the same technique with Jabber or proprietary signalling becomes a reasonably obvious exercise. There are some other twists that seem obvious too - for instance, one could continue the setup over the SDP channel in subsequent offer/answers if the first exchange failed to set up a media channel. I'm not sure that makes sense, though.

In= ORTC language, we could simply have an event on the DtlsTransport that is = something like .onpacket and another that's .addpacket, and when the tr= ansport wants to send a packet, it lets the JS know so it can do so over th= e signalling path, and then the JS can take care of optimizing it (or not).= =C2=A0
=C2=A0

One SDP twist: If forking happens, it could be treated like any other attempt to generate multiple answers to a ClientHello, I think. I'm sure it's well defined how to respond to that - it= 's an obvious attack. Only one leg of the fork would ever succeed, I assume.



On 04/04/2016 03:10 PM, Eric Rescorla wrote:
Hi folks,

I wanted to call your attention to a draft I just published with a possibly stupid
idea.


A nontrivial fraction of call setup time in WebRTC is the DTLS handshake.
This document describes how to piggyback the first few handshake messages
in the SDP offer/answer exchange, thus reducing latency.

Comments welcome.

-Ekr





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



--=20
Surveillance is pervasive. Go Dark.

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


--001a114661dc1b5c01052fe6710d-- From nobody Fri Apr 8 07:40:12 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 9D66F12D194 for ; Fri, 8 Apr 2016 07:40:11 -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 4SEO-aLJSRI1 for ; Fri, 8 Apr 2016 07:40:10 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B43D127058 for ; Fri, 8 Apr 2016 07:40:09 -0700 (PDT) Received: by mail-ig0-x22b.google.com with SMTP id f1so14605677igr.1 for ; Fri, 08 Apr 2016 07:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=C5lU3TwfQc3wX0tieKzNt31o3JKQoub8P3dvQsQ4Bj0=; b=rSXiYU5jnOfnP5ZzVGdCo43dcdEkCzucUkz1q+i1LWvfm0rgfRFGOsguMTiW+tCeYm vfrqbZyK1K+YV2xjDSvUbja6QsSxD3GuzuodWAdcUyuMGWyjIAdtePmisEyhASuI18q6 XzBgURiRg/VRVHeAdWbhrF7qJRHfkGhwVlzG0X76iJHseXhe3yx66U8NOOUkFGsv/1XV 2flNwoRkXPt2WBjMUWmjA3cpwXskpRtEDUxUP2ERyDJsN3YcJTolcEcNfiPbIAZZob/I Y8x3csQIJwHsrUxpdwDsRvc2MfDrsSMr3csWXa+k2umSPSnNfK7DPc69S2/pb8/mYTS5 ZweQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=C5lU3TwfQc3wX0tieKzNt31o3JKQoub8P3dvQsQ4Bj0=; b=EjF+NoXJhyzcQ0gWEqKE+PEaY6faLMfnxwtcJAsFqKl/1CdSeodEgzKS/10B473HVj P1qg8Mi831dzsxc5ix6g7une2lswXCXcIvln1CM8wNGxd8mTDt0DZ9LNHfiH8mRhcDSk 9TFU2ZnSal7mDaSJospNI4OTG+mDAYE9yzJcZinj0tqIhA0K/UH5bUNtdEXEXTgxM2Uu ITyzkE56nLcPieRxQ+2IQGddJ7vvIq13OdK/KNqCI9sxpRyPFEprMVky99oPe61otyUn 9CHuWdNdJ1RGviaFikYkyBuQ7KD0mHCnr8VIE0zW5Za8SE/jfFkQDzHZsub/oNgx2TM3 l9og== X-Gm-Message-State: AD7BkJJjIwiYvhXt0uOoYiVuaVlcOLAm8H5LphzxaF/XEo+BxNO3UW49S4ShvqFHTDwH4BC1K65K+VncQCCpOA== MIME-Version: 1.0 X-Received: by 10.50.171.130 with SMTP id au2mr4176895igc.58.1460126406891; Fri, 08 Apr 2016 07:40:06 -0700 (PDT) Received: by 10.36.43.5 with HTTP; Fri, 8 Apr 2016 07:40:06 -0700 (PDT) Date: Fri, 8 Apr 2016 11:40:06 -0300 Message-ID: From: Martin Thomson To: Jonathan Lennox , Eric Rescorla , Alissa Cooper , Cullen Jennings , "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [rtcweb] friendly amendments to text on DTMF resolution 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, 08 Apr 2016 14:40:11 -0000 grammar of the first sentence (Jonathan) "default duration" for gaps should be "default gap" (ekr) strike "such as browsers" from second paragraph (Alissa) change "will not" to "are not require to" (Martin/Fluffy) From nobody Fri Apr 8 10:54: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 E01A912D4FE for ; Fri, 8 Apr 2016 10:54:36 -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 nldqX166OJSy for ; Fri, 8 Apr 2016 10:54:35 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E6212D0EA for ; Fri, 8 Apr 2016 10:54:34 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id y204so144653435oie.3 for ; Fri, 08 Apr 2016 10:54:34 -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=H9yMaDwIqW65x9wTGop7afBQqIShHeELh+iibx+Vp78=; b=Dw5t3V+6oEpl4ewljcsRmIbS59CO8M2HfL05Gni4pYEsIgH0LguAL5yzyVt3XlLzi3 kAZ/JBzqdmCh4mYPO82mImz4ytnY7v4WLHE1EU0qKqKiRlT7hskqr2gPwWbRgIRoBgMd NCd+nr3VGeS8JuB9ZPpC3wIWT+h/SZKRrnmJHJFONC3IcxwBNe0BNur7dc4iBYoo16vh wdqn5ZUsuSZdbN3Ez5/9m+7WkXlGCXS+koYEjYP9DTEnGoJLQGA+s08mskQM0UtoPkBh M1T9+fb2TNy0ob5nUGd5fsdewpREcwsAX3AfgCxit9zDSosq2DZFwkq8JDiHgNsmQPu1 RW1w== 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=H9yMaDwIqW65x9wTGop7afBQqIShHeELh+iibx+Vp78=; b=QGuC5ppzPEyxQLxdsszuZdzX4mBxR3+Tq5/ZMEX0OLBBehOjTJzrLSnJhKyAsxqckR VerfVSJlU+iC4FcO5hBFAw+c6POM8y5W/XvI/Y/ARcM+EawBu9BmmCmBsYg6hEfVWadQ xALwGSBRf7MO3nFJ5VGHKSTsv5SYTuwZO7Iz8zljHncYUuPoxvsguqKWtMEX7apkIj/v UH70YpIQzvMvV1AXdSFOBWvPi1I2ZdGLiUYGTc0rsEufJv2AzCsefMQaqbvsNvkm4l+b UPEpt+R67B8OmzLUhMYTDbmXn8+VrA0jgxydsFrYdJbWzioL5+16I9HzXSiHVGo5DoNm UB2w== X-Gm-Message-State: AD7BkJIG2pdCQZKbx4d53FAc8ZMZLKAI9U9P2sEx2/c+OOZyV/B3MI9oz2zaaPL/lwQnYUfF8w2X8I80/qj0/Q== X-Received: by 10.202.169.212 with SMTP id s203mr4378869oie.35.1460138074323; Fri, 08 Apr 2016 10:54:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.156 with HTTP; Fri, 8 Apr 2016 10:54:14 -0700 (PDT) From: Ted Hardie Date: Fri, 8 Apr 2016 14:54:14 -0300 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a113ce79e3e422d052ffce334 Archived-At: Subject: [rtcweb] IP handling text 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, 08 Apr 2016 17:54:37 -0000 --001a113ce79e3e422d052ffce334 Content-Type: text/plain; charset=UTF-8 Sorry that we were not able to get to the slides on this during the WG meeting. Here's the proposal from Justin, taken for the slides he prepared. Original text: WebRTC incorporates an explicit permission grant for access to local audio and video, which are typically much more sensitive than the aforementioned IP address information. If the user has consented to media access, this should also allow WebRTC to gather all possible candidates and determine the absolute best route for media traffic. Proposed replacement: Gathering all possible candidates SHOULD only be performed upon user consent, which thwarts the typical drive-by enumeration attacks. The details of this consent are left to the implementation; one potential mechanism is to key this off getUserMedia consent. The getUserMedia suggestion takes into account that the user has provided some consent to the application already; that when doing so the user typically wants to engage in a conversational session, which benefits most from an optimal network path, and lastly, the fact that the underlying issue is complex and difficult to explain, making explicit consent for enumeration troublesome. --001a113ce79e3e422d052ffce334 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry that we were not able to get to the slides on t= his during the WG meeting.=C2=A0 Here's the proposal from Justin, taken= for the slides he prepared.


Original text:

We= bRTC incorporates an explicit permission grant for access to local audio an= d video, which are typically much more sensitive than the aforementioned IP= address information. If the user has consented to media access, this shoul= d also allow WebRTC to gather all possible candidates and determine the abs= olute best route for media traffic.

Proposed replacement:=

Gathering all possible candidates SHOULD only be perform= ed upon user consent, which thwarts the typical drive-by enumeration attack= s. The details of this consent are left to the implementation; one potentia= l mechanism is to key this off getUserMedia consent.

The getUserMedi= a suggestion takes into account that the user has provided some consent to = the application already; that when doing so the user typically wants to eng= age in a conversational session, which benefits most from an optimal networ= k path, and lastly, the fact that the underlying issue is complex and diffi= cult to explain, making explicit consent for enumeration troublesome.
--001a113ce79e3e422d052ffce334-- From nobody Fri Apr 8 14:41:11 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 8669D12D71F for ; Fri, 8 Apr 2016 14:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMgsM6nMHUYA for ; Fri, 8 Apr 2016 14:41:06 -0700 (PDT) Received: from alum-mailsec-scanner-2.mit.edu (alum-mailsec-scanner-2.mit.edu [18.7.68.13]) by ietfa.amsl.com (Postfix) with ESMTP id 837A612D628 for ; Fri, 8 Apr 2016 14:41:06 -0700 (PDT) X-AuditID: 1207440d-bb3ff7000000090b-c9-57082571bdbe Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by (Symantec Messaging Gateway) with SMTP id 01.DE.02315.17528075; Fri, 8 Apr 2016 17:41:05 -0400 (EDT) Received: from Paul-Kyzivats-MacBook-Pro.local (c-73-218-51-154.hsd1.ma.comcast.net [73.218.51.154]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u38Lf4Pw028786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 8 Apr 2016 17:41:05 -0400 To: "rtcweb@ietf.org" From: Paul Kyzivat Message-ID: <5708256F.5080205@alum.mit.edu> Date: Fri, 8 Apr 2016 17:41:03 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHIsWRmVeSWpSXmKPExsUixO6iqFuoyhFuMPenpsXaf+3sDoweS5b8 ZApgjOK2SUosKQvOTM/Tt0vgztj4YRNrwRbpirfLDrM2MH4R6WLk5JAQMJHomdrCCGILCWxl lDjyLqCLkQvI/sUksfLIb1aQhIiAusTlhxfYQWw2AS2JOYf+s4DYwgKuEs83z2YGsXkFtCUa j50BG8QioCLx6/IPJhBbVCBN4t2HeUwQNYISJ2c+AetlFjCTmLf5ITOELS+x/e0c5gmMPLOQ lM1CUjYLSdkCRuZVjHKJOaW5urmJmTnFqcm6xcmJeXmpRbpGermZJXqpKaWbGCFhw7uD8f86 mUOMAhyMSjy8F96zhQuxJpYVV+YeYpTkYFIS5d32kD1ciC8pP6UyI7E4I76oNCe1+BCjBAez kgjvdmWOcCHelMTKqtSifJiUNAeLkjiv2hJ1PyGB9MSS1OzU1ILUIpisDAeHkgTvWhWgRsGi 1PTUirTMnBKENBMHJ8hwLimR4tS8lNSixNKSjHhQJMUXA2MJJMUDtHcySDtvcUFiLlAUovUU o6IU0FaQhABIIqM0D24sLBm8YhQH+lKYdwVIFQ8wkcB1vwIazAQ0+AI/G8jgkkSElFQDo5XQ lmYfNtFp2lanbXZrci/2PqO5SaZUrOuyg8xzM68l09jFtfe8qHRM/LvX7+hr/90Gc/8tW/3y SBxTYYK8q87JuSZzrwq45ybUlRRd+a6YeumXxNfnpTM3rJadbDflN6OU7DH5Eya/4/XPqP0K yWqsOF5p2/HcuH3nm6AaXb77Qg6z7B1+KbEUZyQaajEXFScCAEpuVGfhAgAA Archived-At: Subject: [rtcweb] Followup to discussion of O/A and codecs from Friday 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: Fri, 08 Apr 2016 21:41:09 -0000 During the rtcweb session today, while discussing (I think) JSEP issue #247 (Document what should happen when there are no matching codecs in answer), there was a question about happens in a particular case. I think it was: - X offers codecs A and B (sendrecv) - Y answers codec B (sendrecv) The question was whether Y may use codec A when sending to X. Jonathan gave an answer I disagreed with and we had a chat about it. He got an action item to follow up afterwords, then he asked if I would do it. As I read RFC3264, the answer is: Yes, in the above case Y may send A to X. Then a subsequent scenario came up: what would happen if Y has a need to send a (re)offer? Wouldn't this result in an inability to send using A? (Let's assume that Y is unable/unwilling to *receive* A but can send it, even though this is a weird case.) - Y offers codec B (sendrecv) - X answers codec B and A (sendrecv) This *is* permitted by 3264. And in this case Y will be allowed to continue sending using codec A. Relevant pieces of 3264 supporting this interpretation: - section 5.1 (Generating the Initial Offer/Unicast Streams): ... If multiple formats are listed, it means that the offerer is capable of making use of any of those formats during the session. In other words, the answerer MAY change formats in the middle of the session, making use of any of the formats listed, without sending a new offer. - section 6.1 (Generating the Answer/Unicast Streams): ... For streams marked as sendrecv in the answer, the "m=" line MUST contain at least one codec the answerer is willing to both send and receive, from amongst those listed in the offer. The stream MAY indicate additional media formats, not listed in the corresponding stream in the offer, that the answerer is willing to send or receive (of course, it [the answerer] will not be able to send them at this time, since it was not listed in the offer). - section 8.3.2 (Changing the Set of Media Formats): The list of media formats used in the session MAY be changed. To do this, the offerer creates a new media description, with the list of media formats in the "m=" line different from the corresponding media stream in the previous SDP. This list MAY include new formats, and MAY remove formats present from the previous SDP. ... The corresponding media stream in the answer is formulated as described in Section 6, and may result in a change in media formats as well. Similarly, as described in Section 6, as soon as it sends its answer, the answerer MUST begin sending media using any formats in the offer that were also present in the answer, and SHOULD use the most preferred format in the offer that was also listed in the answer (assuming the stream allows for sending), and MUST NOT send using any formats that are not in the offer, even if they were present in a previous SDP from the peer. Similarly, when the offerer receives the answer, it MUST begin sending media using any formats in the answer, and SHOULD use the most preferred one (assuming the stream allows for sending), and MUST NOT send using any formats that are not in the answer, even if they were present in a previous SDP from the peer. I'm not too clear on how this relates to issue #247, but at least I hope we can agree on what 3264 says. Thanks, Paul From nobody Fri Apr 8 15:01: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 4CE1C12D916 for ; Fri, 8 Apr 2016 15:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.14 X-Spam-Level: X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, T_RP_MATCHES_RCVD=-0.01] 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 cer5PzO4Ucoo for ; Fri, 8 Apr 2016 15:01:13 -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 986B812D658 for ; Fri, 8 Apr 2016 15:01:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id D254C7C7C8E for ; Sat, 9 Apr 2016 00:01:10 +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 tBuNkxUdQFJR for ; Sat, 9 Apr 2016 00:01:10 +0200 (CEST) Received: from [172.20.14.172] (200-127-148-163.net.prima.net.ar [200.127.148.163]) by mork.alvestrand.no (Postfix) with ESMTPSA id 5BBCA7C7C8D for ; Sat, 9 Apr 2016 00:01:09 +0200 (CEST) To: rtcweb@ietf.org References: <5708256F.5080205@alum.mit.edu> From: Harald Alvestrand Message-ID: <57082A21.7010005@alvestrand.no> Date: Sat, 9 Apr 2016 00:01:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <5708256F.5080205@alum.mit.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Followup to discussion of O/A and codecs from Friday 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: Fri, 08 Apr 2016 22:01:16 -0000 This indicates that the answer's omission of a codec does not allow the offerer to deallocate resources that it has reserved for decoding that type of stream (such as hardware). Under this interpretation, if I reserve hardware for decoding VP8 and H.264, and I get back an answer that indicates VP8 only, I cannot deallocate my H.264 resources, since the answerer may choose to send me H.264 anyway. This contradicts something I think I've heard Cullen claim multiple times, but I may have misunderstood Cullen. On 04/08/2016 11:41 PM, Paul Kyzivat wrote: > During the rtcweb session today, while discussing (I think) JSEP issue > #247 (Document what should happen when there are no matching codecs in > answer), there was a question about happens in a particular case. I > think it was: > > - X offers codecs A and B (sendrecv) > - Y answers codec B (sendrecv) > > The question was whether Y may use codec A when sending to X. Jonathan > gave an answer I disagreed with and we had a chat about it. He got an > action item to follow up afterwords, then he asked if I would do it. > > As I read RFC3264, the answer is: > > Yes, in the above case Y may send A to X. > > Then a subsequent scenario came up: what would happen if Y has a need > to send a (re)offer? Wouldn't this result in an inability to send > using A? (Let's assume that Y is unable/unwilling to *receive* A but > can send it, even though this is a weird case.) > > - Y offers codec B (sendrecv) > - X answers codec B and A (sendrecv) > > This *is* permitted by 3264. And in this case Y will be allowed to > continue sending using codec A. > > Relevant pieces of 3264 supporting this interpretation: > > - section 5.1 (Generating the Initial Offer/Unicast Streams): > > ... If multiple formats are listed, it > means that the offerer is capable of making use of any of those > formats during the session. In other words, the answerer MAY change > formats in the middle of the session, making use of any of the > formats listed, without sending a new offer. > > - section 6.1 (Generating the Answer/Unicast Streams): > > ... For streams marked as sendrecv in the answer, > the "m=" line MUST contain at least one codec the answerer is willing > to both send and receive, from amongst those listed in the offer. > The stream MAY indicate additional media formats, not listed in the > corresponding stream in the offer, that the answerer is willing to > send or receive (of course, it [the answerer] will not be able to > send them at this time, since it was not listed in the offer). > > - section 8.3.2 (Changing the Set of Media Formats): > > The list of media formats used in the session MAY be changed. To do > this, the offerer creates a new media description, with the list of > media formats in the "m=" line different from the corresponding media > stream in the previous SDP. This list MAY include new formats, and > MAY remove formats present from the previous SDP. ... > > The corresponding media stream in the answer is formulated as > described in Section 6, and may result in a change in media formats > as well. Similarly, as described in Section 6, as soon as it sends > its answer, the answerer MUST begin sending media using any formats > in the offer that were also present in the answer, and SHOULD use the > most preferred format in the offer that was also listed in the answer > (assuming the stream allows for sending), and MUST NOT send using any > formats that are not in the offer, even if they were present in a > previous SDP from the peer. Similarly, when the offerer receives the > answer, it MUST begin sending media using any formats in the answer, > and SHOULD use the most preferred one (assuming the stream allows for > sending), and MUST NOT send using any formats that are not in the > answer, even if they were present in a previous SDP from the peer. > > I'm not too clear on how this relates to issue #247, but at least I > hope we can agree on what 3264 says. > > Thanks, > Paul > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. From nobody Fri Apr 8 15:18: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 F16D312D5A5 for ; Fri, 8 Apr 2016 15:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 gsm2bB7iBFyT for ; Fri, 8 Apr 2016 15:18:06 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 582D112D5BD for ; Fri, 8 Apr 2016 15:18:01 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id t10so150780736ywa.0 for ; Fri, 08 Apr 2016 15:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Ob+/cqUVn3Ij5r9QEXoQsf6xd3iVBO8EGrnx6amcjbA=; b=IoNijbzj2UmmuGoVQexFw8U3LiG6rOW20mkeCQu1YxCCzMoL+yKPbeE83eO3bwAak9 Fzvjs9b9dPqFgFFKNtYQKRwWbl8iKs/MZOrybLkW5iAmqGMzFlUGZRLwm92j9Bsuez6u f51o86jmPDGMcdyGnsWc4ZOqDue37xLncGzW97+1BQcIEqQtnjhLLmqCIDDTf9QQ3Hb3 5GZ+ADKXy04LCZSkcyujm2fEutyfN7Ux/7kCOD0GcbmLaUjPfBujS6Dlbn1pKkPlB0JD kkp7CrbHP8FRo0u3DP1QhLiXTuV2Vavu6zYAvlhsaZEUr/7inMBXLcrI1spEBuGRTK3q zPIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Ob+/cqUVn3Ij5r9QEXoQsf6xd3iVBO8EGrnx6amcjbA=; b=JR8tHDI2EGdiAELeQfX18pVd1R1HsObRFS8Xxhi3Hvk4NYTb/MzQphBlRCNxBaCBaO ZYXR/Febf6odETXUQFQZbABCJyjXurBQ7XlApCcN/ZVgKQF9iSZxAICxpS19NvVOFP6I tnVxzO09WMB3E7fgQyt4X1hYFhJ2+7+9f6ncxPwYC4U1nPNlSANs85WlJJspQxCD9SUq ZyGSRL0skFYe0POUAPplxEfDZPZ3wmlpLUJAqIEEWDPQOsRniM2EY2DN2jI2dfwfTZf7 iirkCP1WDQPsc9BWOk8rjMCsdIsUBY2CDsIFQsth6n5yNDZpZXNA39Jzyi6lsQ1qlHO+ 6ZXw== X-Gm-Message-State: AD7BkJITmdSrVk3N66CqGieAeK813UHGmQleCSP+9y+T52JZYHCqS18XJn8Q9QQWtoctCadFqfy3xxLuPJ+eVtn5 MIME-Version: 1.0 X-Received: by 10.37.90.87 with SMTP id o84mr5917267ybb.9.1460153880479; Fri, 08 Apr 2016 15:18:00 -0700 (PDT) Received: by 10.129.98.9 with HTTP; Fri, 8 Apr 2016 15:18:00 -0700 (PDT) In-Reply-To: <57082A21.7010005@alvestrand.no> References: <5708256F.5080205@alum.mit.edu> <57082A21.7010005@alvestrand.no> Date: Fri, 8 Apr 2016 15:18:00 -0700 Message-ID: From: Taylor Brandstetter To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a114268885d90940530009131 Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Followup to discussion of O/A and codecs from Friday 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: Fri, 08 Apr 2016 22:18:09 -0000 --001a114268885d90940530009131 Content-Type: text/plain; charset=UTF-8 In Section 6 of RFC 3264: > The answerer MUST send using a media format in the offer that is also listed in the answer > > So, if X offers A and B, and Y answers B, how would Y be able to send A? It's not in both the offer and the answer. On Fri, Apr 8, 2016 at 3:01 PM, Harald Alvestrand wrote: > This indicates that the answer's omission of a codec does not allow the > offerer to deallocate resources that it has reserved for decoding that > type of stream (such as hardware). > > Under this interpretation, if I reserve hardware for decoding VP8 and > H.264, and I get back an answer that indicates VP8 only, I cannot > deallocate my H.264 resources, since the answerer may choose to send me > H.264 anyway. > > This contradicts something I think I've heard Cullen claim multiple > times, but I may have misunderstood Cullen. > > > On 04/08/2016 11:41 PM, Paul Kyzivat wrote: > > During the rtcweb session today, while discussing (I think) JSEP issue > > #247 (Document what should happen when there are no matching codecs in > > answer), there was a question about happens in a particular case. I > > think it was: > > > > - X offers codecs A and B (sendrecv) > > - Y answers codec B (sendrecv) > > > > The question was whether Y may use codec A when sending to X. Jonathan > > gave an answer I disagreed with and we had a chat about it. He got an > > action item to follow up afterwords, then he asked if I would do it. > > > > As I read RFC3264, the answer is: > > > > Yes, in the above case Y may send A to X. > > > > Then a subsequent scenario came up: what would happen if Y has a need > > to send a (re)offer? Wouldn't this result in an inability to send > > using A? (Let's assume that Y is unable/unwilling to *receive* A but > > can send it, even though this is a weird case.) > > > > - Y offers codec B (sendrecv) > > - X answers codec B and A (sendrecv) > > > > This *is* permitted by 3264. And in this case Y will be allowed to > > continue sending using codec A. > > > > Relevant pieces of 3264 supporting this interpretation: > > > > - section 5.1 (Generating the Initial Offer/Unicast Streams): > > > > ... If multiple formats are listed, it > > means that the offerer is capable of making use of any of those > > formats during the session. In other words, the answerer MAY change > > formats in the middle of the session, making use of any of the > > formats listed, without sending a new offer. > > > > - section 6.1 (Generating the Answer/Unicast Streams): > > > > ... For streams marked as sendrecv in the answer, > > the "m=" line MUST contain at least one codec the answerer is willing > > to both send and receive, from amongst those listed in the offer. > > The stream MAY indicate additional media formats, not listed in the > > corresponding stream in the offer, that the answerer is willing to > > send or receive (of course, it [the answerer] will not be able to > > send them at this time, since it was not listed in the offer). > > > > - section 8.3.2 (Changing the Set of Media Formats): > > > > The list of media formats used in the session MAY be changed. To do > > this, the offerer creates a new media description, with the list of > > media formats in the "m=" line different from the corresponding media > > stream in the previous SDP. This list MAY include new formats, and > > MAY remove formats present from the previous SDP. ... > > > > The corresponding media stream in the answer is formulated as > > described in Section 6, and may result in a change in media formats > > as well. Similarly, as described in Section 6, as soon as it sends > > its answer, the answerer MUST begin sending media using any formats > > in the offer that were also present in the answer, and SHOULD use the > > most preferred format in the offer that was also listed in the answer > > (assuming the stream allows for sending), and MUST NOT send using any > > formats that are not in the offer, even if they were present in a > > previous SDP from the peer. Similarly, when the offerer receives the > > answer, it MUST begin sending media using any formats in the answer, > > and SHOULD use the most preferred one (assuming the stream allows for > > sending), and MUST NOT send using any formats that are not in the > > answer, even if they were present in a previous SDP from the peer. > > > > I'm not too clear on how this relates to issue #247, but at least I > > hope we can agree on what 3264 says. > > > > Thanks, > > Paul > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > -- > Surveillance is pervasive. Go Dark. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a114268885d90940530009131 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In Section 6 of RFC 3264:
The answere=
r MUST send using a media format in the offer that is also listed in the an=
swer
So, if X offer= s A and B, and Y answers B, how would Y be able to send A? It's not in = both the offer and the answer.

On Fri, Apr 8, 2016 at 3:01 PM, Haral= d Alvestrand <harald@alvestrand.no> wrote:
This indicates that the answer's omission of a code= c does not allow the
offerer to deallocate resources that it has reserved for decoding that
type of stream (such as hardware).

Under this interpretation, if I reserve hardware for decoding VP8 and
H.264, and I get back an answer that indicates VP8 only, I cannot
deallocate my H.264 resources, since the answerer may choose to send me
H.264 anyway.

This contradicts something I think I've heard Cullen claim multiple
times, but I may have misunderstood Cullen.


On 04/08/2016 11:41 PM, Paul Kyzivat wrote:
> During the rtcweb session today, while discussing (I think) JSEP issue=
> #247 (Document what should happen when there are no matching codecs in=
> answer), there was a question about happens in a particular case. I > think it was:
>
> - X offers codecs A and B (sendrecv)
> - Y answers codec B (sendrecv)
>
> The question was whether Y may use codec A when sending to X. Jonathan=
> gave an answer I disagreed with and we had a chat about it. He got an<= br> > action item to follow up afterwords, then he asked if I would do it. >
> As I read RFC3264, the answer is:
>
> Yes, in the above case Y may send A to X.
>
> Then a subsequent scenario came up: what would happen if Y has a need<= br> > to send a (re)offer? Wouldn't this result in an inability to send<= br> > using A? (Let's assume that Y is unable/unwilling to *receive* A b= ut
> can send it, even though this is a weird case.)
>
> - Y offers codec B (sendrecv)
> - X answers codec B and A (sendrecv)
>
> This *is* permitted by 3264. And in this case Y will be allowed to
> continue sending using codec A.
>
> Relevant pieces of 3264 supporting this interpretation:
>
> - section 5.1 (Generating the Initial Offer/Unicast Streams):
>
>=C2=A0 =C2=A0 ... If multiple formats are listed, it
>=C2=A0 =C2=A0 means that the offerer is capable of making use of any of= those
>=C2=A0 =C2=A0 formats during the session.=C2=A0 In other words, the ans= werer MAY change
>=C2=A0 =C2=A0 formats in the middle of the session, making use of any o= f the
>=C2=A0 =C2=A0 formats listed, without sending a new offer.
>
> - section 6.1 (Generating the Answer/Unicast Streams):
>
>=C2=A0 =C2=A0 ... For streams marked as sendrecv in the answer,
>=C2=A0 =C2=A0 the "m=3D" line MUST contain at least one codec= the answerer is willing
>=C2=A0 =C2=A0 to both send and receive, from amongst those listed in th= e offer.
>=C2=A0 =C2=A0 The stream MAY indicate additional media formats, not lis= ted in the
>=C2=A0 =C2=A0 corresponding stream in the offer, that the answerer is w= illing to
>=C2=A0 =C2=A0 send or receive (of course, it [the answerer] will not be= able to
>=C2=A0 =C2=A0 send them at this time, since it was not listed in the of= fer).
>
> - section 8.3.2 (Changing the Set of Media Formats):
>
>=C2=A0 =C2=A0 The list of media formats used in the session MAY be chan= ged.=C2=A0 To do
>=C2=A0 =C2=A0 this, the offerer creates a new media description, with t= he list of
>=C2=A0 =C2=A0 media formats in the "m=3D" line different from= the corresponding media
>=C2=A0 =C2=A0 stream in the previous SDP.=C2=A0 This list MAY include n= ew formats, and
>=C2=A0 =C2=A0 MAY remove formats present from the previous SDP.=C2=A0 .= ..
>
>=C2=A0 =C2=A0 The corresponding media stream in the answer is formulate= d as
>=C2=A0 =C2=A0 described in Section 6, and may result in a change in med= ia formats
>=C2=A0 =C2=A0 as well.=C2=A0 Similarly, as described in Section 6, as s= oon as it sends
>=C2=A0 =C2=A0 its answer, the answerer MUST begin sending media using a= ny formats
>=C2=A0 =C2=A0 in the offer that were also present in the answer, and SH= OULD use the
>=C2=A0 =C2=A0 most preferred format in the offer that was also listed i= n the answer
>=C2=A0 =C2=A0 (assuming the stream allows for sending), and MUST NOT se= nd using any
>=C2=A0 =C2=A0 formats that are not in the offer, even if they were pres= ent in a
>=C2=A0 =C2=A0 previous SDP from the peer.=C2=A0 Similarly, when the off= erer receives the
>=C2=A0 =C2=A0 answer, it MUST begin sending media using any formats in = the answer,
>=C2=A0 =C2=A0 and SHOULD use the most preferred one (assuming the strea= m allows for
>=C2=A0 =C2=A0 sending), and MUST NOT send using any formats that are no= t in the
>=C2=A0 =C2=A0 answer, even if they were present in a previous SDP from = the peer.
>
> I'm not too clear on how this relates to issue #247, but at least = I
> hope we can agree on what 3264 says.
>
>=C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0Paul
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

--
Surveillance is pervasive. Go Dark.

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

--001a114268885d90940530009131-- From nobody Fri Apr 8 15:21:28 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 D568D12D51C for ; Fri, 8 Apr 2016 15:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=telurix-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 8-Ix9nV5neuw for ; Fri, 8 Apr 2016 15:21:25 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2756712D11F for ; Fri, 8 Apr 2016 15:21:25 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id g185so148007060ioa.2 for ; Fri, 08 Apr 2016 15:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=S7yMFO9uhrhiV+bzQzgb1egAfWEpzYXPNa4IoopeNb4=; b=O2P0mnSWSW5vxYTYWKPgKiJyyus0SWbimm6TWy9SxPVcWahcCzm/PsH2aLjuiGo5GX bocBFhhSchBTNS7i/KvPONAHxxckyXukw4id06HjmUgdKEij3eXmzXeTZOnx2gnOMD7Q mbY081+F6mEV2P3D04dwtbdEeNU/FPBE2lPrQ89fUnMJZCny1wgNi6MluZJRBdoqCVvk dxjsHhNdlocLZIq9ASyPflBRKAS+EaKKOVJKfdWQPsdD6+QXxSK9Ik+tu7G8EHlseSyE X0aFc09CVO30DSk/ulD+Z8dwQkkDF59BijtteCpv2WtAmGBLmgGNOrgHOhe2KIzZYAaD 8X1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=S7yMFO9uhrhiV+bzQzgb1egAfWEpzYXPNa4IoopeNb4=; b=VE9NZDKkfGsiwdCgQumlCV0R3oTUBra7uka6TMA/tdjGhrAKj2fhaQJ/1hUmUHLORO CF+2Wh09OfoXkRMIZ2C0Hod+8K8FOIHU+1l7r3HbhqHC32iFAsagSzj39J7CWcsj9UNs f8HW1LARXVUbtpBjBJX2O5MluQFXNdtnQmchVJFGSGKY0bwhJRTP7/xI5x5X3UroF887 Vr6fADEb2fkyuQbfp07o+dXCWTVgoDEE0waYIlu4fpwLIwjgJgzpEIntoZiqEZLQGIVc uPudsFj9JQfZA3VRGxE/UOv1w++67TU9lyvX8vjMQ3QpaZzlyND2FEo+yCfMCwKWGf4u jHew== X-Gm-Message-State: AD7BkJIO95fKpssrhbQzmH0aGf8Pxg6hU5WHm8Z6Bh/smpJe+XkjW/rYD37qHRLoj0SCxQ== X-Received: by 10.107.165.78 with SMTP id o75mr13521731ioe.56.1460154084576; Fri, 08 Apr 2016 15:21:24 -0700 (PDT) Received: from mail-io0-f177.google.com (mail-io0-f177.google.com. [209.85.223.177]) by smtp.gmail.com with ESMTPSA id au6sm3837290igc.0.2016.04.08.15.21.23 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2016 15:21:24 -0700 (PDT) Received: by mail-io0-f177.google.com with SMTP id o126so125675261iod.0 for ; Fri, 08 Apr 2016 15:21:23 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.157.70 with SMTP id g67mr11043965ioe.38.1460154083724; Fri, 08 Apr 2016 15:21:23 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Fri, 8 Apr 2016 15:21:23 -0700 (PDT) In-Reply-To: <57082A21.7010005@alvestrand.no> References: <5708256F.5080205@alum.mit.edu> <57082A21.7010005@alvestrand.no> Date: Fri, 8 Apr 2016 18:21:23 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a1140b4727a580c0530009d58 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Followup to discussion of O/A and codecs from Friday 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: Fri, 08 Apr 2016 22:21:27 -0000 --001a1140b4727a580c0530009d58 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 8, 2016 at 6:01 PM, Harald Alvestrand wrote: > This indicates that the answer's omission of a codec does not allow the > offerer to deallocate resources that it has reserved for decoding that > type of stream (such as hardware). > > Under this interpretation, if I reserve hardware for decoding VP8 and > H.264, and I get back an answer that indicates VP8 only, I cannot > deallocate my H.264 resources, since the answerer may choose to send me > H.264 anyway. > > Based on what I heard from multiple people (including Jonathan Rosenberg when this document was originally discussed), Offer/Answer was always intended to be asymmetrical. Each side can declare all the codecs it is willing to receive and can send any codec remote party supports. I saw multiple examples of this being implemented and used in exactly this manner. In your example, if you need to free resources for H.264, you need to do another Offer/Answer exchange in which you will send an offer with VP8 only. Regards, _____________ Roman Shpount --001a1140b4727a580c0530009d58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 8, 2016 at 6:01 PM, Harald Alvestrand &l= t;harald@alvestra= nd.no> wrote:
This indicates that the answer's omission of a codec does n= ot allow the
offerer to deallocate resources that it has reserved for decoding that
type of stream (such as hardware).

Under this interpretation, if I reserve hardware for decoding VP8 and
H.264, and I get back an answer that indicates VP8 only, I cannot
deallocate my H.264 resources, since the answerer may choose to send me
H.264 anyway.


Based on what I heard from multiple people = (including Jonathan Rosenberg when this document was originally discussed),= Offer/Answer was always intended to be asymmetrical. Each side can declare= all the codecs it is willing to receive and can send any codec remote part= y supports. I saw multiple examples of this being implemented and used in e= xactly this manner.

In your example, if you need to free resources for H.264, you= need to do another Offer/Answer exchange in which you will send an offer w= ith VP8 only.

Regards,
_____________
Ro= man Shpount
=C2=A0
--001a1140b4727a580c0530009d58-- From nobody Fri Apr 8 15:27: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 902EC12D5A5 for ; Fri, 8 Apr 2016 15:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-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 WKq5sPko4IFe for ; Fri, 8 Apr 2016 15:27:32 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001: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 D41F412D17A for ; Fri, 8 Apr 2016 15:27:31 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id g185so148128956ioa.2 for ; Fri, 08 Apr 2016 15:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Z4k0A9O2J+fUcBNtxxORrni1SbRCld6hOzXOv6fY2O4=; b=CgFU53vKYgF7zJd6nZBg0xVLtONwaoUZcM7mkkovalNVa32VZHiwMV3PE47p8Ja8/Y IMarJIbGL8jY3U6bPghjZapO4MjxY8TAm3/5WuaF0+Pvgx1V5o2PeyQM01kNjgg3EG5v 67Sg5FbWkSAFRnffw9lh8XaRDVwOxr7+FYEXz7UmlF6oAZGmbvDSK3WHMsEjlwqeJH79 1B+lhfvFHH27jIskmnt7RL2NeD4BfSwfUkjPGa1nZGXEG7eXV0XDKI0Fe2U/UhDfLMW+ Pu1wj4FXczLcdNgaZZtiafKXu1Payxe+dAkhuBmTH8FTXQiDqCUYKyskGA6fpRLnxxok ODXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Z4k0A9O2J+fUcBNtxxORrni1SbRCld6hOzXOv6fY2O4=; b=NMuWxOoWZ6uSr5LEA3PddM+rW0VigqcO+onBxmtvJ/4dm5utoo2iDbihX5dXXV0epH Yxo5zwN3zPeiHo3Xj1gdwAFgjzMuhyKBfhdSnGurbtYhg6/JLzKxekNRW5NOcvLOu4CB CH4hnFmrU7JsbD7LuX2F9YEENewjekGOWqPdmTKetDTchK+nTG7XXa+EwTngMj2roFHh mScttyCiqbfREQq0HwUYDNPDhi88mcJtuH1X2HH7ikIaUBJ8fsZ8AMKQarUjZWjmG72G rU3zPGwEMwzxpgYH27QEiU1SvQuHVZHQpWCK3ZXNvA+4G6Ul5+lFwx+lDGtInm/gccS3 N5rg== X-Gm-Message-State: AD7BkJKiYu4giKUAXIWzvtTXEsrFDbTDAurMQN3WcWScm2r1Co2VgKIZpIlkycs76tgnXA== X-Received: by 10.107.156.9 with SMTP id f9mr11931878ioe.120.1460154451204; Fri, 08 Apr 2016 15:27:31 -0700 (PDT) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com. [209.85.213.176]) by smtp.gmail.com with ESMTPSA id k2sm3294198igx.5.2016.04.08.15.27.30 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2016 15:27:30 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id gy3so45756571igb.1 for ; Fri, 08 Apr 2016 15:27:30 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.93.138 with SMTP id cu10mr6335425igb.96.1460154450214; Fri, 08 Apr 2016 15:27:30 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Fri, 8 Apr 2016 15:27:30 -0700 (PDT) In-Reply-To: References: <5708256F.5080205@alum.mit.edu> <57082A21.7010005@alvestrand.no> Date: Fri, 8 Apr 2016 18:27:30 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Taylor Brandstetter Content-Type: multipart/alternative; boundary=bcaec502d300528d2e053000b3e2 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Followup to discussion of O/A and codecs from Friday 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: Fri, 08 Apr 2016 22:27:33 -0000 --bcaec502d300528d2e053000b3e2 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 8, 2016 at 6:18 PM, Taylor Brandstetter wrote: > In Section 6 of RFC 3264: > >> The answerer MUST send using a media format in the offer that is also listed in the answer >> >> So, if X offers A and B, and Y answers B, how would Y be able to send A? > It's not in both the offer and the answer. > > A does not have to be in both offer and answer. Offer/Answer is declarative capability exchange with each side declaring what it is willing to receive. It is not intended to pick a single codec. Negotiation is considered successful if there is at least one common codec, but there are no other requirements. Each party can send any codec remote party is willing to receive and can switch between the codecs remote party supports at any time. So in this example, Y can not only send A but can switch between A and B at any time. Also, answer can include codecs which were not present in the offer, so the whole situation can be reversed. _____________ Roman Shpount --bcaec502d300528d2e053000b3e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Apr 8, 2016 at 6:18= PM, Taylor Brandstetter <deadbeef@google.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex">
In Section 6 of RFC 3264:
The answerer MUST send using a media format in the offer that is also l=
isted in the answer
So, if X offers A and B, and Y answers B, how would Y be able to send A? I= t's not in both the offer and the answer.


A does not have to be in both offer and= answer. Offer/Answer is declarative capability exchange with each side dec= laring what it is willing to receive. It is not intended to pick a single c= odec. Negotiation is considered successful if there is at least one common = codec, but there are no other requirements. Each party can send any codec r= emote party is willing to receive and can switch between the codecs remote = party supports at any time. So in this example, Y can not only send A but c= an switch between A and B at any time.

Also, answe= r can include codecs which were not present in the offer, so the whole situ= ation can be reversed.
___________= __
Roman Shpount
=C2=A0
--bcaec502d300528d2e053000b3e2-- From nobody Fri Apr 8 15:36:02 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 8BD6612D540 for ; Fri, 8 Apr 2016 15:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=mozilla-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 J5j9ayBRlxD3 for ; Fri, 8 Apr 2016 15:35:57 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C99812D14D for ; Fri, 8 Apr 2016 15:35:57 -0700 (PDT) Received: by mail-qg0-x236.google.com with SMTP id j35so102569641qge.0 for ; Fri, 08 Apr 2016 15:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=24ezbfK+n9zXaWEpso7ZydLuWz+mJU4lEscboxDU8go=; b=TIzs6SE4b9gMuLSnL6Mf4azae3qREp58QEbD9zAydPH2pQZ7DExkAM+BTuhEd1ghEp znSlkrVOp1v+9sdRW1mp8ZwMC2C8c2PDVxMRsQ0LrJzDg/AAfj1fgXBEY83cOs7+uUWj upozOp74Ao9WUh92D0ENqqDnDaHT4BReFSzVjmBGkoMY2KpFAUtNwXJyaxmlFFDzPe9L 8ng31gEwl+X6w+xXlxp0EiFNPOA/L7VSaEXcVuEbB/Qoy5EEGtfcqFd7vEkBk5feLJ77 YQBAvEzp6SWRbYv7d2BTD7XAI12QBc6ypSp1hSDa14TTaPwhUMEAquvVKU/PrSIe8ZOr ObRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=24ezbfK+n9zXaWEpso7ZydLuWz+mJU4lEscboxDU8go=; b=RNyCp3Xqqnh/RhZT6wUReN+JqFUOOvYCUcH1c3OlIEqSVppxgd/xQLwWdczWBbIZt7 /GXuXYkRRYgRLmedBW5tsuT8gbE2Q9lp0YT7lYjf0bPgAtgu+q/UJ0dP2lQ4Qqcgn5ar UO4h3xOB0j2jmSCrCxioY/fcLCKfGO/vOicNCJh3sBhgWNWonqo/Cgf3Y0in+m6mmWnQ kd86YsulJrfLtvnQcX3fNT0/U1aXXprGTYOnwRCDradua5xCImheOINWJo9zq10N5j9J f7DA6XKHMc6OMdAq/r4l3vDQb9T+xTi54WYGMrrwjmRs67SeLM1nl+28Df4amszchl1j HHeA== X-Gm-Message-State: AD7BkJJciGItF8/cXiZ24XnfEIQ/SqRkL00IjaNB+kNqPIpb1z/Lc1M76DQiRnS8TqJ8pOEK X-Received: by 10.140.237.75 with SMTP id i72mr15257316qhc.75.1460154956320; Fri, 08 Apr 2016 15:35:56 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable017.46-176-173.mc.videotron.ca. [173.176.46.17]) by smtp.gmail.com with ESMTPSA id q94sm6401435qgq.14.2016.04.08.15.35.54 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2016 15:35:55 -0700 (PDT) To: rtcweb@ietf.org References: From: Jean-Marc Valin Message-ID: <5708324A.7060502@mozilla.com> Date: Fri, 8 Apr 2016 18:35:54 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] friendly amendments to text on DTMF resolution 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, 08 Apr 2016 22:36:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/08/2016 10:40 AM, Martin Thomson wrote: > grammar of the first sentence (Jonathan) "default duration" for > gaps should be "default gap" (ekr) strike "such as browsers" from > second paragraph (Alissa) change "will not" to "are not require to" > (Martin/Fluffy) Can someone point me to the latest text to which the above applies? I did not attend Buenos Aires and could not find anything in the meeting slides. Cheers, Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXCDJEAAoJEJ6/8sItn9q9urUH/RHpcWG48MqEdN37gEnh3cNI Z8om062TuZ6KCAhJ6PJTpGCGSSev1n2ubw+54/3SPiXt7OWM3jiKTVDGo29RI+Vl 3T3fk1VerUEzI0J2CgeIJsByGliybZUj6+yFQiho0I0r9b+Yzabi+PfloYPxaDnG 6Eu50ErnePPuLazHrpKiLLHcotZVv8jyuq6gcbR9WZE+mBKh2jLFg/sCbAlym2au yw94xiXfKsXrz/8OVcYF5ImCnu2xU2OtGW0X87G/7fDZTQCoBulRqK6cqUbgP2Xz LJGxsLuaiA8Q4rqWOpvX8HekxUfbqw3s00L4vLU5YfRmbbQQlC/wcuZ0KcZzbEU= =EhZ0 -----END PGP SIGNATURE----- From nobody Fri Apr 8 15:36:14 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 3787012D5DB for ; Fri, 8 Apr 2016 15:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 0nJc2qNKZFns for ; Fri, 8 Apr 2016 15:36:12 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 DA09012D14D for ; Fri, 8 Apr 2016 15:36:11 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id t10so151149467ywa.0 for ; Fri, 08 Apr 2016 15:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=5ocKPoRMzMOMwrbjLvbFgn37BUumP6cMS+ZLHyVgalo=; b=oDxI9D9yW0c8IuPLEGLqvKZk9NnWOTh5mFvN9LAxz5gDc42kDFz4z6+eF62FGXCh2/ J2LPAUZNOM/OEGYevq0vkmi06bdPq9XM63fpZB7u3WUnUqWoXfZhAaDqq++9BlAtGT4n NEBoL2kyfReEYLimsbBpEL7RLcvc4Sa7PoAE8sERy/4aN3E70YgOSGY22nXFMSVz+NLy C45Yc97etKgcUavIRDF1kk9pHJ/MY1Fb4gBphxU+90uk6sXN/0FBakJ5nk/4rDvCPlOY CuSjIrPcyV6BURV69KDzZyNBYRfDqLK7dlnLwQb/GhGU7DNBGQk5zOCe6qe1y/6/p2d5 sFBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=5ocKPoRMzMOMwrbjLvbFgn37BUumP6cMS+ZLHyVgalo=; b=lDfdy4Hlb72Bf2LcmX2+AAQuYyAn4DD8HQ2pYFM/9MXVAVK/V//uo9F/u7Setw67iC HG2EvEUwj9cAykg75SwObNqaPQvnGX+2xNnD5gNphAOufo+nHrsdvXPPpqhySwxCs678 mAXEzGcvrd3/em2fcmMo+JNRp7dvAYs64Y5CDOVYbN1pAba7k/KcniFxnH/D8rw2Hr8X /P263OPqkCy2h+SbXsBf1nKMjzc3XNoIiWMOnCCFeQK+sODJ3DQkJUDYmlW9e8LZo8mn NMdwHv71dLLwGEBYQJlRN+4dvnAR4ToATl2AYjrE3m8TEOIWoBaYl7FAyP5X1eAEYE/s AE8w== X-Gm-Message-State: AD7BkJKMybfPI2aTaU5Sv71sJodasaozv4Khou7n8xtFalkJaEqnE7edCnNQ6Z9L3P66Ex1YTW0mge0XPhghhI7U MIME-Version: 1.0 X-Received: by 10.37.66.21 with SMTP id p21mr6127165yba.77.1460154971034; Fri, 08 Apr 2016 15:36:11 -0700 (PDT) Received: by 10.129.98.9 with HTTP; Fri, 8 Apr 2016 15:36:10 -0700 (PDT) In-Reply-To: References: <5708256F.5080205@alum.mit.edu> <57082A21.7010005@alvestrand.no> Date: Fri, 8 Apr 2016 15:36:10 -0700 Message-ID: From: Taylor Brandstetter To: Roman Shpount Content-Type: multipart/alternative; boundary=001a11c00a305e0f9a053000d228 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Followup to discussion of O/A and codecs from Friday 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: Fri, 08 Apr 2016 22:36:13 -0000 --001a11c00a305e0f9a053000d228 Content-Type: text/plain; charset=UTF-8 I understand if that was the intent, but that's not what RFC 3264 seems to say. Both Section 6 and Section 8.3.2 state that the answer MUST send a codec listed in both the offer and the answer. So is RFC 3264 wrong? Or is my interpretation of the rule wrong? On Fri, Apr 8, 2016 at 3:27 PM, Roman Shpount wrote: > > On Fri, Apr 8, 2016 at 6:18 PM, Taylor Brandstetter > wrote: > >> In Section 6 of RFC 3264: >> >>> The answerer MUST send using a media format in the offer that is also listed in the answer >>> >>> So, if X offers A and B, and Y answers B, how would Y be able to send A? >> It's not in both the offer and the answer. >> >> > A does not have to be in both offer and answer. Offer/Answer is > declarative capability exchange with each side declaring what it is willing > to receive. It is not intended to pick a single codec. Negotiation is > considered successful if there is at least one common codec, but there are > no other requirements. Each party can send any codec remote party is > willing to receive and can switch between the codecs remote party supports > at any time. So in this example, Y can not only send A but can switch > between A and B at any time. > > Also, answer can include codecs which were not present in the offer, so > the whole situation can be reversed. > _____________ > Roman Shpount > > --001a11c00a305e0f9a053000d228 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I understand if that was the intent, but that's not wh= at RFC 3264 seems to say. Both Section 6 and Section 8.3.2 state that the a= nswer MUST send a codec listed in both the offer and the answer.

So is RFC 3264 wrong? Or is my interpretation of the rule wrong?

On Fri,= Apr 8, 2016 at 3:27 PM, Roman Shpount <roman@telurix.com> w= rote:

On Fri, Apr 8, 2016 at 6:18 PM, Taylor Brandstetter <deadbeef@goog= le.com> wrote:
In Sectio= n 6 of RFC 3264:
The answerer MUST send using a media f=
ormat in the offer that is also listed in the answer
So, if X offers A and B, and Y answers B,= how would Y be able to send A? It's not in both the offer and the answ= er.

=

A does not have to be i= n both offer and answer. Offer/Answer is declarative capability exchange wi= th each side declaring what it is willing to receive. It is not intended to= pick a single codec. Negotiation is considered successful if there is at l= east one common codec, but there are no other requirements. Each party can = send any codec remote party is willing to receive and can switch between th= e codecs remote party supports at any time. So in this example, Y can not o= nly send A but can switch between A and B at any time.

=
Also, answer can include codecs which were not present in the offer, s= o the whole situation can be reversed.
_____________
Roman Shpount
=C2=A0

--001a11c00a305e0f9a053000d228-- From nobody Fri Apr 8 15:47: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 DE4D012D581 for ; Fri, 8 Apr 2016 15:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 3jwK9BmJjPPl for ; Fri, 8 Apr 2016 15:47:01 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96CF412D529 for ; Fri, 8 Apr 2016 15:47:01 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id i84so145156044ywc.2 for ; Fri, 08 Apr 2016 15:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=eWQTwAVvDErOCAoXeE3NK00vk7tw6fzwoVV5KQtf8rY=; b=eDF2UV/LJkhlNpdfEfLOZjaQn3hCBchFP8ID77MAww1tKRfQlS5gIXUlB390hKgtjq iBz0LN/X8T6SSTFQRftA8Yxarx8I7KIW0SPnlvHHTLqEMXOydXQ+UcdFUUBVUBrb2B31 GbQfJKlGwRcPCND9aM1mrCmdcpajUGD2s1lxAqpcQIIHzkPl1E2esKcxAkxqgYJMED3m YBCOKiVnES2Z31d5Zw+lLyxkuqO4cVACqdbTHObhXg2lXS5ug7N8Q1GBTJZ6xBDCkr2r fYncUEzRXhe246NlpvYhlekDSH8DliM/9VB5zxtliElICDClfpTLVzinKUIpRYlr1hZS ma3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=eWQTwAVvDErOCAoXeE3NK00vk7tw6fzwoVV5KQtf8rY=; b=Ad7OvpJWzmlhQv9bnITk4eQzE8KBao5u0LRmcQ03UdyyHu+jlM4fEMA6BxHcBvPfGE qPaWO0tUpN7Gfi5jrYWIGXcAfzc20+VitRs/pOCTF7W7FBF7IKoN2F96SXLHs+MVAjEl H2DkpQOeq78AErv+VlLBpwLxsxHTBDnjllHuqxPCW4LFQW+mIBFGviZnFsz7pyx21MMW KjZNj9fjWpdAYbD+JWQKwhR2ajP+xBGDsvRi3WSEKielY2ELlmaAi+xdarZG6GIibogu XYeyh64bBK4YTqRjRh/nHNFJe9uYAW/t1fjN/9GzBAA6aCQswrxmPuqtjnDbV9HbfQ6S Hl1A== X-Gm-Message-State: AD7BkJJIWCdAsSfmfRzYv5rGqe+AAhN7hNfFEwEZHR138vEvD/f0FlzDCWdleZ9ZUwYjmhES/GaFKSzPf9dhfBBE MIME-Version: 1.0 X-Received: by 10.37.19.67 with SMTP id 64mr6114109ybt.20.1460155620717; Fri, 08 Apr 2016 15:47:00 -0700 (PDT) Received: by 10.129.98.9 with HTTP; Fri, 8 Apr 2016 15:47:00 -0700 (PDT) In-Reply-To: References: <5708256F.5080205@alum.mit.edu> <57082A21.7010005@alvestrand.no> Date: Fri, 8 Apr 2016 15:47:00 -0700 Message-ID: From: Taylor Brandstetter To: Roman Shpount Content-Type: multipart/alternative; boundary=001a113e490a1748d9053000f902 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Followup to discussion of O/A and codecs from Friday 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: Fri, 08 Apr 2016 22:47:04 -0000 --001a113e490a1748d9053000f902 Content-Type: text/plain; charset=UTF-8 Actually, I see that Section 5.1 states: > > [T]he answerer MAY change formats in the middle of the session, making use of any of the formats listed [in the offer], without sending a new offer. > > So, does the combination of these statements imply that the answerer MUST start by sending a format common to both the offer and the answer, but later MAY switch to a format specific to the offer? That seems odd, but I can't think of any other conclusion. On Fri, Apr 8, 2016 at 3:36 PM, Taylor Brandstetter wrote: > I understand if that was the intent, but that's not what RFC 3264 seems to > say. Both Section 6 and Section 8.3.2 state that the answer MUST send a > codec listed in both the offer and the answer. > > So is RFC 3264 wrong? Or is my interpretation of the rule wrong? > > On Fri, Apr 8, 2016 at 3:27 PM, Roman Shpount wrote: > >> >> On Fri, Apr 8, 2016 at 6:18 PM, Taylor Brandstetter >> wrote: >> >>> In Section 6 of RFC 3264: >>> >>>> The answerer MUST send using a media format in the offer that is also listed in the answer >>>> >>>> So, if X offers A and B, and Y answers B, how would Y be able to send >>> A? It's not in both the offer and the answer. >>> >>> >> A does not have to be in both offer and answer. Offer/Answer is >> declarative capability exchange with each side declaring what it is willing >> to receive. It is not intended to pick a single codec. Negotiation is >> considered successful if there is at least one common codec, but there are >> no other requirements. Each party can send any codec remote party is >> willing to receive and can switch between the codecs remote party supports >> at any time. So in this example, Y can not only send A but can switch >> between A and B at any time. >> >> Also, answer can include codecs which were not present in the offer, so >> the whole situation can be reversed. >> _____________ >> Roman Shpount >> >> > > --001a113e490a1748d9053000f902 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Actually, I see that Section 5.1 states:
= 
[=
T]he answerer MAY change formats in the middle of the session, making use o=
f any of the formats listed [in the offer], without sending a new offer.
So, does the combination of these statements imply tha= t the answerer MUST start by sending a format common to both the offer and = the answer, but later MAY switch to a format specific to the offer? That se= ems odd, but I can't think of any other conclusion.

On Fri, Apr 8, 2016 a= t 3:36 PM, Taylor Brandstetter <deadbeef@google.com> wrote= :
I understand if that w= as the intent, but that's not what RFC 3264 seems to say. Both Section = 6 and Section 8.3.2 state that the answer MUST send a codec listed in both = the offer and the answer.

So is RFC 3264 wrong? Or is my= interpretation of the rule wrong?

On Fri= , Apr 8, 2016 at 3:27 PM, Roman Shpount <roman@telurix.com> = wrote:

On Fri= , Apr 8, 2016 at 6:18 PM, Taylor Brandstetter <deadbeef@google.com&g= t; wrote:
In Section 6 of RFC 3= 264:
The answerer MUST send using a media format in the=
 offer that is also listed in the answer
So, if X offers A and B, and Y answers B, how would Y= be able to send A? It's not in both the offer and the answer.

=

A does not have to be in both offer= and answer. Offer/Answer is declarative capability exchange with each side= declaring what it is willing to receive. It is not intended to pick a sing= le codec. Negotiation is considered successful if there is at least one com= mon codec, but there are no other requirements. Each party can send any cod= ec remote party is willing to receive and can switch between the codecs rem= ote party supports at any time. So in this example, Y can not only send A b= ut can switch between A and B at any time.

Also, a= nswer can include codecs which were not present in the offer, so the whole = situation can be reversed.
_____________
Roman Shpount
=C2=A0


--001a113e490a1748d9053000f902-- From nobody Fri Apr 8 15:47:17 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 9AE9312D680 for ; Fri, 8 Apr 2016 15:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=telurix-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 FptSfes5G8-9 for ; Fri, 8 Apr 2016 15:47:05 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A25012D529 for ; Fri, 8 Apr 2016 15:47:05 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id g185so148512638ioa.2 for ; Fri, 08 Apr 2016 15:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=R6Ff5Nj/tspohGXjysQYyiVaIo6XPpKqbMO8DxI7gNk=; b=F+XynAKk4RWgOD6YX2HvdtWsr9EkL6Ju6T7oVeGYgX0lDVUzIE4e6t1E/QSUWIyXtG xrsq6tNMz863091KKHPp+jItHzxIzW60uLsAfRMiyKvYiTbrmmdDgJ+UQYi0Rotcg2mo 8Wl7zD2HMBd6kIfCzR6q/XiIzAcgdPM6rMIVL1vuN9V+FoAzDOpYJOPUW6WBDLvSVzex FIicbHScN1WFdwlfjPontqVQ6THokv1W9DHhmlDS0P2itq8oWkcdbLZTEWZktPlGqMAq Cox59spjMAM2pDrGGH8M3w1HbL3H9ExAR3pLgw2jPARzmGiThMQB0lqerqfxmHmVTHO5 SYMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=R6Ff5Nj/tspohGXjysQYyiVaIo6XPpKqbMO8DxI7gNk=; b=AXgKluMx0CdhSepqheCySTu7bUEB3n2FQTNkwQrVjXbCsTCcyIJxdMwqSqZ8Vc8PG9 TTRHPI4UmYJWII3EPOFBPMLmelHdwuCvRpZ5DZmrBm+JhklNJ2y9xSTyvhiEKqZSck8t NzzA9OXN+habzxt+HBa0d0+qmWCyignTC5OZJlE/g5x7gHeUsPOHbGwbASf4JkiI6RGF 7osG4yG6kamhhwS9ecHlxFvbQIF9k+xXSDNB15QdQH6FHS+sK5C2e3VtmlvxpH+deBbH 7LGP2iFDio6bOTU/N6TrFubFz853yGhriiHT/Gzc5Aekm6TvEkEIrJE1/X2QE4SG6wHT SKRA== X-Gm-Message-State: AD7BkJLIvBFanH1PiQp7siwMI/nXEksGSsp5XIxPJVqprYdgmT8XECjb4oeiLr1I+vqZ/w== X-Received: by 10.107.158.134 with SMTP id h128mr12047757ioe.153.1460155624703; Fri, 08 Apr 2016 15:47:04 -0700 (PDT) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com. [209.85.223.171]) by smtp.gmail.com with ESMTPSA id n13sm8030047ioi.44.2016.04.08.15.47.04 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2016 15:47:04 -0700 (PDT) Received: by mail-io0-f171.google.com with SMTP id g185so148512360ioa.2 for ; Fri, 08 Apr 2016 15:47:04 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.12.224 with SMTP id 93mr12496659iom.70.1460155623891; Fri, 08 Apr 2016 15:47:03 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Fri, 8 Apr 2016 15:47:03 -0700 (PDT) In-Reply-To: References: <5708256F.5080205@alum.mit.edu> <57082A21.7010005@alvestrand.no> Date: Fri, 8 Apr 2016 18:47:03 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Taylor Brandstetter Content-Type: multipart/alternative; boundary=001a113f91ae478d3a053000f938 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Followup to discussion of O/A and codecs from Friday 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: Fri, 08 Apr 2016 22:47:07 -0000 --001a113f91ae478d3a053000f938 Content-Type: text/plain; charset=UTF-8 Taylor, After rereading RFC3264, I can see that you are correct: If the codec is not present in the answer, offerer MAY stop listening for this payload type (https://tools.ietf.org/html/rfc3264#section-7). Sorry for confusion, _____________ Roman Shpount On Fri, Apr 8, 2016 at 6:36 PM, Taylor Brandstetter wrote: > I understand if that was the intent, but that's not what RFC 3264 seems to > say. Both Section 6 and Section 8.3.2 state that the answer MUST send a > codec listed in both the offer and the answer. > > So is RFC 3264 wrong? Or is my interpretation of the rule wrong? > > On Fri, Apr 8, 2016 at 3:27 PM, Roman Shpount wrote: > >> >> On Fri, Apr 8, 2016 at 6:18 PM, Taylor Brandstetter >> wrote: >> >>> In Section 6 of RFC 3264: >>> >>>> The answerer MUST send using a media format in the offer that is also listed in the answer >>>> >>>> So, if X offers A and B, and Y answers B, how would Y be able to send >>> A? It's not in both the offer and the answer. >>> >>> >> A does not have to be in both offer and answer. Offer/Answer is >> declarative capability exchange with each side declaring what it is willing >> to receive. It is not intended to pick a single codec. Negotiation is >> considered successful if there is at least one common codec, but there are >> no other requirements. Each party can send any codec remote party is >> willing to receive and can switch between the codecs remote party supports >> at any time. So in this example, Y can not only send A but can switch >> between A and B at any time. >> >> Also, answer can include codecs which were not present in the offer, so >> the whole situation can be reversed. >> _____________ >> Roman Shpount >> >> > > --001a113f91ae478d3a053000f938 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Taylor,

After rereading RFC3264, I can = see that you are correct: If the codec is not present in the answer, offere= r MAY stop listening for this payload type (https://tools.ietf.org/html/rfc3264#section-7).


________= _____
Roman Shpount

On Fri, Apr 8, 2016 at 6:36 PM, Taylor Brand= stetter <deadbeef@google.com> wrote:
I understand if that was the intent, but tha= t's not what RFC 3264 seems to say. Both Section 6 and Section 8.3.2 st= ate that the answer MUST send a codec listed in both the offer and the answ= er.

So is RFC 3264 wrong? Or is my interpretation of the= rule wrong?

On Fri, Apr 8, 2016 at 3:27= PM, Roman Shpount <roman@telurix.com> wrote:
<= br>
On Fri, Apr 8, 2016 at 6:18= PM, Taylor Brandstetter <deadbeef@google.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex">
In Section 6 of RFC 3264:
The answerer MUST send using a media format in the offer that is also l=
isted in the answer
So, if X offers A and B, and Y answers B, how would Y be able to send A? I= t's not in both the offer and the answer.
=

A does not have to be in both offer and answer. Offer/An= swer is declarative capability exchange with each side declaring what it is= willing to receive. It is not intended to pick a single codec. Negotiation= is considered successful if there is at least one common codec, but there = are no other requirements. Each party can send any codec remote party is wi= lling to receive and can switch between the codecs remote party supports at= any time. So in this example, Y can not only send A but can switch between= A and B at any time.

Also, answer can include cod= ecs which were not present in the offer, so the whole situation can be reve= rsed.
_____________
Roman S= hpount
=C2=A0


--001a113f91ae478d3a053000f938-- From nobody Fri Apr 8 16:30:32 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 5D56312D118 for ; Fri, 8 Apr 2016 16:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=telurix-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 zHuSZ4cRciiG for ; Fri, 8 Apr 2016 16:30:29 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 328A5127058 for ; Fri, 8 Apr 2016 16:30:29 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id q128so149195376iof.3 for ; Fri, 08 Apr 2016 16:30:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=eDpQSF11uew6manYcsUAJcG/Vp2/YQZsvy4ILAnpcTw=; b=gikKa2mfyuZUIKVmvRDPVczy93HldSLi9/mMTk1WvXUXrnPlFmaIuxK/slJZtD7qhJ 3g0W2nVzlrfBCgxa0C800hztYcNy+syaLk9Boep+2O1iFs5JHgUPAS71wJ5DgYLI2YKR dQUPcADp9QiPxFmKtRKEVuBlmKD8h9MTyLrwTF2PLEfnBEaHgdTpdt9SArJOjLHYjTij 3WX3JKdJnGabh0UR1dSAjUz4drJiFRVwMIUJIUJAH2yDl1CtCK3Laq10/mWdrYQzO74/ 0Z+Ra31l8XfDMhz/W7Ml/XYPfywOiK5+RVupwzKPRiWZAviUScJXQzMG6e3nmpie8UmY yh6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=eDpQSF11uew6manYcsUAJcG/Vp2/YQZsvy4ILAnpcTw=; b=iMB9qJWPNLYaaB/ZGwQyxVIwaebKRj80REN7QWuLkn85wzcs1xzO97vDzBLgTZ478r JMluKTWXeMqrkOQqiaBtgsGdmnl7J40kHcMOlCUc475+qorSiiYiCp/A9+g/56wCcwXv wj1P/Vpgq9OdshUOF1mXMGa7LhRfjQSy5Vv+KSHt0W8lHrYGHsacsxeW8miuiZL4HBmZ DlL7APZ27J3psVdeu6+CJE3YibFpD5MUVHhzXUKM5kplWimIK9rFYqiCyl+sK1ozpJqr xRjwFTHcKiUisGUuibMOqbTYTVeEGiuh5EpH+ZUC8k5RomtYSfXoI4CRvLgHIvBxRtLY 1a1A== X-Gm-Message-State: AD7BkJJ2rfHtJmnrppXQE2sXto/JGCSt8R6J4GiwIGF0eJ7uulMzpTvEa0Ajx3aysw3hoQ== X-Received: by 10.107.156.140 with SMTP id f134mr11748802ioe.112.1460158228517; Fri, 08 Apr 2016 16:30:28 -0700 (PDT) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com. [209.85.213.174]) by smtp.gmail.com with ESMTPSA id v21sm8142133iov.4.2016.04.08.16.30.27 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2016 16:30:28 -0700 (PDT) Received: by mail-ig0-f174.google.com with SMTP id ui10so29073964igc.1 for ; Fri, 08 Apr 2016 16:30:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.28.42 with SMTP id y10mr6623951igg.24.1460158227630; Fri, 08 Apr 2016 16:30:27 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Fri, 8 Apr 2016 16:30:27 -0700 (PDT) Date: Fri, 8 Apr 2016 19:30:27 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "rtcweb@ietf.org" , Justin Uberti , Christer Holmberg Content-Type: multipart/alternative; boundary=089e01537a4079562805300194b9 Archived-At: Subject: [rtcweb] DTLS role during SDP renegotiation 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, 08 Apr 2016 23:30:32 -0000 --089e01537a4079562805300194b9 Content-Type: text/plain; charset=UTF-8 Hi All, I've listened through the IEFT95 session recording and I wanted to clarify one thing. DTLS setup attribute MUST be set to the currently negotiated role if not accompanied by ICE restart and SHOULD be actpass in case of ICE restart. The reason for this is that answerer is allowed to start a new DTLS association in response to the offer with ICE restart. When answerer starts a new DTLS association, it might be beneficial to change the DTLS setup role. Answerer is not allowed to start new DTLS association if offerer did not initiate an ICE restart since new transport cannot be created for the DTLS association, so offerer MUST preserve the setup role in this case. Regards, _____________ Roman Shpount --089e01537a4079562805300194b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

I've listened through= the IEFT95 session recording and I wanted to clarify one thing. DTLS setup= attribute MUST be set to the currently negotiated role if not accompanied = by ICE restart and SHOULD be actpass in case of ICE restart. The reason for= this is that answerer is allowed to start a new DTLS association in respon= se to the offer with ICE restart. When answerer starts a new DTLS associati= on, it might be beneficial to change the DTLS setup role. Answerer is not a= llowed to start new DTLS association if offerer did not initiate an ICE res= tart since new transport cannot be created for the DTLS association, so off= erer MUST preserve the setup role in this case.

Regards,=
_____________
Roma= n Shpount
--089e01537a4079562805300194b9-- From nobody Sat Apr 9 13:19: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 8D49512D162 for ; Sat, 9 Apr 2016 13:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.272 X-Spam-Level: X-Spam-Status: No, score=0.272 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.972] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 bNfXMrSkQ3iB for ; Sat, 9 Apr 2016 13:19:49 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 4B25412D157 for ; Sat, 9 Apr 2016 13:19:49 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by comcast with SMTP id ozLdaSjwJnIc7ozMCaV3UB; Sat, 09 Apr 2016 20:19:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460233188; bh=ulJ/XS7tK8MhQzHzkqEvLtz29fa7GuM/9r7j3Quexp8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=lZM+IZVGeD2fKc9nLGRobogVObHB0mJ9yiDkoyrCNjbIrcXz5TvfreX859CRtQyix HJ36MLi1hregWlHJUqn+dsxkkqw9KuxwKc+eoUhu6UDxbEiPQQKQcVB/8gkqL9we7W cL6XmxVAqc7GrkEGPv3jDIUgEknwcPcPbfRUXGXXgLvwguvzfXlkRlEqD/19bi50nE ASfy5V8QmUbszqCmDYPOVxXX4YD6REmy+pkYV1PW0l8omTdo7OyOMobg/tDPA5nYTK 8B34iMJkVLmepqjBN1TPPl5orz5HqThSM+5+BLcQcFfS0XCfIQT69kJh9hPDPej1x6 ReATAuonzBRVw== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-19v.sys.comcast.net with comcast id gLKo1s0043KdFy101LKoXA; Sat, 09 Apr 2016 20:19:48 +0000 To: rtcweb@ietf.org References: <5708256F.5080205@alum.mit.edu> <57082A21.7010005@alvestrand.no> From: Paul Kyzivat Message-ID: <570963E3.2090204@alum.mit.edu> Date: Sat, 9 Apr 2016 16:19:47 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Followup to discussion of O/A and codecs from Friday 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: Sat, 09 Apr 2016 20:19:50 -0000 On 4/8/16 6:47 PM, Roman Shpount wrote: > Taylor, > > After rereading RFC3264, I can see that you are correct: If the codec is > not present in the answer, offerer MAY stop listening for this payload > type (https://tools.ietf.org/html/rfc3264#section-7). > > Sorry for confusion, Hmm. Also, the end of section 6.1 says: The answerer MUST send using a media format in the offer that is also listed in the answer, Together, those contradict what I said above. So I guess Harald gets his wish to be able to discard resources for codecs that weren't mentioned in the answer. Unfortunately this also means it isn't possible to have asymmetric behavior. For instance, it means you can't have telephone-events work in one direction and not the other. Sorry for missing the above, Paul From nobody Sun Apr 10 07:40: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 D092012D56A for ; Sun, 10 Apr 2016 07:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.517 X-Spam-Level: X-Spam-Status: No, score=-115.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=-0.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 HjbJ5FyDRUjO for ; Sun, 10 Apr 2016 07:40:07 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0A7A12B00D for ; Sun, 10 Apr 2016 07:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=389; q=dns/txt; s=iport; t=1460299207; x=1461508807; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jcsKKXb7ytsiuUrp7l1Cta42GsS/qsyhq4vlP+c8b94=; b=WeJcO/1WIBkcBtunUR58Ur+jeHWBU23QQBgGJxz7LjHFHrMDH8RMMULv 9eSG1XzjU0DOOWgMLcAzBr4GXMeY/GZNxzGB8kGivQIbJ1JN15m8GOZ0r gVv/nGDDLVhtsvBq/+ahGCVFNyemfn1RrgYvimkrxADdff2GDjZsz/RVx E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAgAYZQpX/4YNJK1cgzeBUAaud4lJg?= =?us-ascii?q?g8BDYFzhg0CgSE4FAEBAQEBAQFlJ4RBAQEBAwE6PwULAgEIGB4QIRElAgQOBYg?= =?us-ascii?q?SAwoItlMNhR8BAQEBAQEBAQEBAQEBAQEBAQEBAQEViBaCVoJBgXyDLYIrAQSXU?= =?us-ascii?q?zEBjBaBdYFRAY07h0qHWwEeAQFCg2dsiS1+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,462,1454976000"; d="scan'208";a="90198940" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Apr 2016 14:40:06 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u3AEe6fY027056 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 10 Apr 2016 14:40:06 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 10 Apr 2016 10:40: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.1104.009; Sun, 10 Apr 2016 10:40:05 -0400 From: "Cullen Jennings (fluffy)" To: Jean-Marc Valin Thread-Topic: friendly amendments to text on DTMF resolution Thread-Index: AQHRkaSOKFM8ijhUi0WMQL8TjJGDHJ+DjYEA Date: Sun, 10 Apr 2016 14:40:05 +0000 Message-ID: <560A374D-DDEF-4C23-83FF-841251AFEE3D@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.20.249.165] Content-Type: text/plain; charset="us-ascii" Content-ID: <5CA0D48A915EBA42B1522051B4ABC7CB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Jonathan Lennox , Ted Hardie , "rtcweb@ietf.org" Subject: Re: [rtcweb] friendly amendments to text on DTMF resolution 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, 10 Apr 2016 14:40:08 -0000 > On Apr 8, 2016, at 8:40 AM, Martin Thomson wro= te: >=20 > grammar of the first sentence (Jonathan) > "default duration" for gaps should be "default gap" (ekr) > strike "such as browsers" from second paragraph (Alissa) > change "will not" to "are not require to" (Martin/Fluffy) Just wanted to +1 that Martin got all the points I recall on this. = From nobody Wed Apr 13 13:32: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 A1E6512E4BF for ; Wed, 13 Apr 2016 13:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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, T_KAM_HTML_FONT_INVALID=0.01] 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 Bp7kRF4k2H0m for ; Wed, 13 Apr 2016 13:32:02 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c: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 1BBB312E4BD for ; Wed, 13 Apr 2016 13:32:02 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id t129so85483974vkg.2 for ; Wed, 13 Apr 2016 13:32:02 -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=OgfH2bUrGu6UYKTBTQvUMidaNtD8qEQcRQrpqrLLoXg=; b=SNhwbHI9//6db3l1J3e2PI9FnQqu5VhisOR0UinNQHbMWgVh2nFaRaPGLeVRocjD6o SYufwX5T7Si2OyNCZprDv/fR1PsIV+3iKSW3+O8kkjVr9U8zYlR/zPCbXILBN6uDlkkp +RyLkNCZigUqgR+ZIq5z0ewKyYAjK4dpDp7lybZltgTnxTKatY4r/fYiEjZNsDpSm+Q0 tEHtIqUuiDcpyn79Z60e84qdQp6KsbsKMj/P0oGRWj0KClHr4BHvBvKHnKv6+dPw/2OP Kta1Kb2ifZ68phxumYVnko6+8IT2qxA4LwvbgbGx1CcBP/pwLkzhzWxAeIFKZmGKoCJW gujQ== 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=OgfH2bUrGu6UYKTBTQvUMidaNtD8qEQcRQrpqrLLoXg=; b=cRYi1D5bECfjy9q74iE7c8GNVTXCDFiiLeiRtaiRAlQbphInqEtYLYHZztjctEZCJ3 TOXbAF/3VTARUJr2bSUKnt07dMsFKRiJxGaYFeMpOQRa+4Ry9D+SzXbvdasnhLZUC7+7 7R9XT9lmS7RaqAtPRxwNvn/bNZxKcSiKj+Va/YB0N8J+a54J0j3ePt34ZQ+YIaNxCSOn a3XYhFxnpgNFVOoOM4ubOgGsed5UdG13E7ARN/n0wa0Z57JIJI7ZOxPghx1p+649b/Ej 2WuTkPNlvlHoJFii+YE2jNfC3qEsvdOw9EoaXaT8ZNdAbAsB/i/puroe6G8MOep1w2Xa WV3A== X-Gm-Message-State: AOPr4FUCepsQgNgLgT+ggc8r0q7rheR4/AgC/ey2aoAlnEyITXEvggdwWBTVz4GzPU4yks7lcuM0J52mxSaytw== X-Received: by 10.159.38.49 with SMTP id 46mr5198972uag.139.1460579521200; Wed, 13 Apr 2016 13:32:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.35.111 with HTTP; Wed, 13 Apr 2016 13:31:41 -0700 (PDT) From: Ted Hardie Date: Wed, 13 Apr 2016 13:31:41 -0700 Message-ID: To: "rtcweb@ietf.org" , Cullen Jennings , Sean Turner Content-Type: multipart/alternative; boundary=001a113e3966870a6c053063abee Archived-At: Subject: [rtcweb] Confirmation of DTMF issue 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, 13 Apr 2016 20:32:03 -0000 --001a113e3966870a6c053063abee Content-Type: text/plain; charset=UTF-8 With Martin's friendly amendments, the room at IETF 95 agreed to the follow as the resolution of the DTMF discussion. The chairs would like anyone who has new issues with this to let us know as soon as possible and no later than Wednesday, April 20th, noon UTC, "DTMF events generated by a WebRTC endpoint MUST have a duration of no more than 8000 ms and no less than 40 ms. The recommended default duration is 100 ms for each tone. The gap between events MUST be no less than 30 ms; the recommended default gap duration is 70 ms. WebRTC endpoints are not required to do anything with RFC 4733 tones sent to them, except gracefully drop them. There is currently no API to inform JavaScript about the received DTMF or other RFC 4733 tones." regards, Ted, Cullen, and Sean --001a113e3966870a6c053063abee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
With Martin's friendly amendments, the room = at IETF 95 agreed to the follow as the resolution of the DTMF discussion.= =C2=A0 The chairs would like anyone who has new issues with this to let us = know as soon as possible and no later than Wednesday, April 20th, noon UTC,=


"<= span style=3D"font-size:10.6667px;color:rgb(0,0,0);background-color:transpa= rent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:= none;vertical-align:baseline">DTMF events generated by a WebRTC endpoint MU= ST have a duration of no more than 8000 ms and no less than 40 ms.=C2=A0 Th= e recommended default duration is 100 ms for each tone. The gap between eve= nts MUST be no less than 30 ms; =C2=A0the recommended default gap duration = is 70 ms.

WebRTC endpoints are= not required to do anything with RFC 4733 tones sent to them, except grace= fully drop them. There is currently no API to inform JavaScript about the r= eceived DTMF or other RFC 4733 tones."

regards,

Ted, Cullen, and Sean=
--001a113e3966870a6c053063abee-- From nobody Wed Apr 13 13:51: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 C8AD812E51E for ; Wed, 13 Apr 2016 13:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 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, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-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 40iWeDk-F_Qq for ; Wed, 13 Apr 2016 13:51:36 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D88EB12E4F1 for ; Wed, 13 Apr 2016 13:51:35 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id 2so84343308ioy.1 for ; Wed, 13 Apr 2016 13:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=v73DS9HD+C/rLMXAyEY6GHIXAkb5+sS+u3+wpUfl5EY=; b=Q+niNVDF0Z33VhIIaJEZCHtTYYtQGgJU179QJB20BcD3wK/YmLuD3RWr6PYIi9yUSP QItETs02VqMqYPT30S8z4mD9k+53joFKQLHLI4xTic/HhWF/Rhb3wV45IJs+KiY1kJAb c5KJLDCnYGxnco0kJrptVldr7uJwv85YjkMLhAzafPKBGpmkbz4+jlsSsohhaLv6Anvj KOrVgPM7yEH8V874C3xDstgv+tTQAuWHJIYGrYRrv9PSLlsO7/cNuEnZLpqw1m8yE7PM /wQu62u4T6oFKn1fS4VqDnPGOSwkxzzyzfPcq2eTevVJanektX3Uq76rA4QSxBU8XF5/ mW5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=v73DS9HD+C/rLMXAyEY6GHIXAkb5+sS+u3+wpUfl5EY=; b=Uw83mi8NWmWgk8b8WUfHa4xJmMnr9w3X7VFV+b2xagdBZPBBBDi+OyvEObMBLMD+9a y9J74kVBeHleA8rb5RWMKfKDVVy4OZeQbUn6oybl3dEYbZFyoJBO8SCODNZBJ/W3o0LL Dt668Yq39/YlWY+/XBZ/UuJGyOtG4XOg48K1phsPcL2AQUj2WrqQFQpMKH2R9NANWfeG O6yfoocjJxtA6H9BAeYChRQZGilHVoUQGobe0Ja8m2EHmUbltlhpPBrJsKRbjxhkKqmp 9mFcFUsT7/P8/mhDe6DMciHbwmHWJ58H8fypd0BuU0L35z5C3+vjU+VD82kidNnQOaSu H2fg== X-Gm-Message-State: AOPr4FW+DPdUZHZj0d8cZNRTHocLsHlF9n9ZKvKzX7h725+1rqz7KZuQog+fJp/CPNUtZA== X-Received: by 10.107.168.72 with SMTP id r69mr11906135ioe.179.1460580695093; Wed, 13 Apr 2016 13:51:35 -0700 (PDT) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com. [209.85.213.170]) by smtp.gmail.com with ESMTPSA id i74sm24428067ioe.37.2016.04.13.13.51.33 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Apr 2016 13:51:34 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id ui10so71754345igc.1 for ; Wed, 13 Apr 2016 13:51:33 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.66.171 with SMTP id g11mr33166071igt.96.1460580693768; Wed, 13 Apr 2016 13:51:33 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Wed, 13 Apr 2016 13:51:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Apr 2016 16:51:33 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Ted Hardie Content-Type: multipart/alternative; boundary=047d7bdc08a66b0078053063f178 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of DTMF issue 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, 13 Apr 2016 20:51:38 -0000 --047d7bdc08a66b0078053063f178 Content-Type: text/plain; charset=UTF-8 I support this language. _____________ Roman Shpount On Wed, Apr 13, 2016 at 4:31 PM, Ted Hardie wrote: > With Martin's friendly amendments, the room at IETF 95 agreed to the > follow as the resolution of the DTMF discussion. The chairs would like > anyone who has new issues with this to let us know as soon as possible and > no later than Wednesday, April 20th, noon UTC, > > > "DTMF events generated by a WebRTC endpoint MUST have a duration of no > more than 8000 ms and no less than 40 ms. The recommended default duration > is 100 ms for each tone. The gap between events MUST be no less than 30 ms; > the recommended default gap duration is 70 ms. > > WebRTC endpoints are not required to do anything with RFC 4733 tones sent > to them, except gracefully drop them. There is currently no API to inform > JavaScript about the received DTMF or other RFC 4733 tones." > > regards, > > Ted, Cullen, and Sean > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7bdc08a66b0078053063f178 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support this language.
<= br clear=3D"all">
_____________
Roman= Shpount

On Wed, Apr 13, 2016 at 4:31 PM, Ted Hardie = <ted.ietf@gmail.com> wrote:
With Martin's friendly amendments, the ro= om at IETF 95 agreed to the follow as the resolution of the DTMF discussion= .=C2=A0 The chairs would like anyone who has new issues with this to let us= know as soon as possible and no later than Wednesday, April 20th, noon UTC= ,


"= DTMF events generated by a WebRTC endpoint M= UST have a duration of no more than 8000 ms and no less than 40 ms.=C2=A0 T= he recommended default duration is 100 ms for each tone. The gap between ev= ents MUST be no less than 30 ms; =C2=A0the recommended default gap duration= is 70 ms.

WebRTC endpoints ar= e not required to do anything with RFC 4733 tones sent to them, except grac= efully drop them. There is currently no API to inform JavaScript about the = received DTMF or other RFC 4733 tones."

regards,

Ted, Cullen, and Sea= n

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


--047d7bdc08a66b0078053063f178-- From nobody Wed Apr 13 18:45:32 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 BA12012D129 for ; Wed, 13 Apr 2016 18:45:30 -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 UPlXbSnQKIqm for ; Wed, 13 Apr 2016 18:45:29 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C14E12D1AD for ; Wed, 13 Apr 2016 18:45:29 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id 2so90241312ioy.1 for ; Wed, 13 Apr 2016 18:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=naVpZn0ZLmC4SY+NK8xwrgvYU5bX3RnmIq+r3KP3Eek=; b=k4bByrHxXJcl7hdZOd5gLorhBk8ZlYCjYERSchStCd1XH406zH1/AStjIcnGmhz/ZT p+yUFTiRK7Mx/93i9NdZZ7ZsuLfIvacvaIfaJWExLhFHxJ+0akQgRzLXfyTQNKKjNV3F Y3B8gIGOmEvHU1SfrAuuZTK6WiAOFZx6V9XVek99c5crWO37QodxhwlkiKhK4HfcDMMD DD2pGbhKsIqFe20ev4cs0naxe+by3r6ioPqfDT/2xsaaL2h1v0i8jrQSSaRDXVRJO+mA 9gLVdbPGaTSY8F6RoqcRpnRlvtMFXsFVLajKv/FldfUqXVKHPhSUoJ+OLaNNu4pTBe+B 3XBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=naVpZn0ZLmC4SY+NK8xwrgvYU5bX3RnmIq+r3KP3Eek=; b=OMOLYSahWXPKYvkLtfxBMxRB5ooE1JeIvMz547MELrmGTOC/+bPov1jwrbS2pZChX2 GoU1bjz5H7U/W8ii8EaR1F/w2U7P9g00enmYTjj49AlYdeGYpVZaZ4YfZfCJcHm/E8QC rHGiaOg+3GMK571WCgNYfikA6J5IsnhVdtyMQ0gnjlv2O1Q4d81WodaV2agbJbrpqcOg jOu7OZPUJKF7/WPpnHm+VXj1YPhy6Xx9eTVagzIRHbdXEO2S6YOzwvSKUi4dYESp7yc5 chXaZ6QRf1nuY2ck9iOAG8ylI4IqjK1EIhPIAJzOHYmNrwwD+KyhcX2JPvMJdcdcycAG FYUg== X-Gm-Message-State: AOPr4FUKKFjIZKt0mMXKc6L+jVnbAq6KkkDRoH+LxsLJKaDre+ZMCeny41w39konePUqul6YuQxOzkvgFNEQYw== MIME-Version: 1.0 X-Received: by 10.107.161.140 with SMTP id k134mr14134653ioe.190.1460598328347; Wed, 13 Apr 2016 18:45:28 -0700 (PDT) Received: by 10.36.43.5 with HTTP; Wed, 13 Apr 2016 18:45:28 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Apr 2016 22:45:28 -0300 Message-ID: From: Martin Thomson To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of DTMF issue 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, 14 Apr 2016 01:45:30 -0000 +1 A bigger +1 to finishing this. I never realized that immersion coating was possible for something as large as a bike shed. On 13 April 2016 at 17:31, Ted Hardie wrote: > With Martin's friendly amendments, the room at IETF 95 agreed to the follow > as the resolution of the DTMF discussion. The chairs would like anyone who > has new issues with this to let us know as soon as possible and no later > than Wednesday, April 20th, noon UTC, > > > "DTMF events generated by a WebRTC endpoint MUST have a duration of no more > than 8000 ms and no less than 40 ms. The recommended default duration is > 100 ms for each tone. The gap between events MUST be no less than 30 ms; > the recommended default gap duration is 70 ms. > > WebRTC endpoints are not required to do anything with RFC 4733 tones sent to > them, except gracefully drop them. There is currently no API to inform > JavaScript about the received DTMF or other RFC 4733 tones." > > regards, > > Ted, Cullen, and Sean > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Thu Apr 14 00:01: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 8F86D12D97C for ; Thu, 14 Apr 2016 00:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.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 yIOIVA0Rgnli for ; Thu, 14 Apr 2016 00:00:58 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0685.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::685]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B9712D79B for ; Thu, 14 Apr 2016 00:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GkH371vlbrW85rz7tqa2vsZGHF8aN6y7VSiPCX90ewc=; b=O2y0OkbdBn88c4w4xtZq7ssz5JdiOwLJtXfiAa7hQR3k4ouhB2T9tBTDT0+Twh+7yY0SOoE44UK3VvcNy/DGk8SESqt6sglXOWeFdGHnYOddxPaInelLQluoyEcIg8ZW1AQ0BmsvklmVTh57l/nIbbQe59rb4mSvuThH0F7yorI= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1549.namprd03.prod.outlook.com (10.162.129.155) with Microsoft SMTP Server (TLS) id 15.1.453.26; Thu, 14 Apr 2016 07:00:35 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0453.029; Thu, 14 Apr 2016 07:00:35 +0000 From: "Asveren, Tolga" To: Martin Thomson , Ted Hardie Thread-Topic: [rtcweb] Confirmation of DTMF issue Thread-Index: AQHRlcOWrSnLkbndS0SnfqTKfpfy1p+Isx0AgABXbuA= Date: Thu, 14 Apr 2016 07:00:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 1b34e35a-e12c-433b-80da-08d364327a92 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1549; 5:ESWC7lXmS5aEtpvC2oRZ4dIAMw42PcBWs/bfr6QRYwiEFBnm2hA/W6oKcla20PPsMSgTrCSWzS1wgUmMhghDLXVWPC6T/rQ/YcMrIaU+ml+ALbCUhBpoEAHXZIjIFUU9W7Ssk3EOCwweTrZRU0/oRw==; 24:K161Xjdy0Syg1rxogmLTpN2+Lk0kW1kybkmo5+V/kAeLDKUS5sDEG2+A5zJUaX2X5d00wCSwCcySpVMCoBApqoSm5VXQ0JbIkbbQjSoF6Pk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1549; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:SN1PR0301MB1549; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1549; x-forefront-prvs: 0912297777 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(24454002)(13464003)(3280700002)(92566002)(3660700001)(122556002)(33656002)(9686002)(4326007)(2906002)(15975445007)(586003)(74316001)(164054004)(5008740100001)(77096005)(81166005)(86362001)(2900100001)(19580405001)(2950100001)(5001770100001)(5002640100001)(189998001)(66066001)(5004730100002)(102836003)(5003600100002)(10400500002)(106116001)(76176999)(1220700001)(54356999)(50986999)(11100500001)(87936001)(99286002)(1096002)(76576001)(19580395003)(3846002)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1549; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2016 07:00:35.3810 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1549 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Confirmation of DTMF issue 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, 14 Apr 2016 07:01:04 -0000 The text looks good to me too. Thanks, Tolga > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Martin > Thomson > Sent: Wednesday, April 13, 2016 9:45 PM > To: Ted Hardie > Cc: Cullen Jennings ; rtcweb@ietf.org > Subject: Re: [rtcweb] Confirmation of DTMF issue >=20 > +1 >=20 > A bigger +1 to finishing this. I never realized that immersion coating w= as > possible for something as large as a bike shed. >=20 > On 13 April 2016 at 17:31, Ted Hardie wrote: > > With Martin's friendly amendments, the room at IETF 95 agreed to the > > follow as the resolution of the DTMF discussion. The chairs would > > like anyone who has new issues with this to let us know as soon as > > possible and no later than Wednesday, April 20th, noon UTC, > > > > > > "DTMF events generated by a WebRTC endpoint MUST have a duration of > no > > more than 8000 ms and no less than 40 ms. The recommended default > > duration is > > 100 ms for each tone. The gap between events MUST be no less than 30 > > ms; the recommended default gap duration is 70 ms. > > > > WebRTC endpoints are not required to do anything with RFC 4733 tones > > sent to them, except gracefully drop them. There is currently no API > > to inform JavaScript about the received DTMF or other RFC 4733 tones." > > > > regards, > > > > Ted, Cullen, and Sean > > > > _______________________________________________ > > 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 Thu Apr 14 00:49: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 2752E12E0CB for ; Thu, 14 Apr 2016 00:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=mozilla-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 lkwvoxW2xSYm for ; Thu, 14 Apr 2016 00:49:33 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83CF212E12D for ; Thu, 14 Apr 2016 00:49:32 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id r184so27049549qkc.1 for ; Thu, 14 Apr 2016 00:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=HFeJ+NlFKTF9cMY5q7GhrIw7yXj4o0vM2HzHaerMuak=; b=Z1+G1iKVvfus84YvnnFBp+DBz1LoggLW6fn1ACp29R/m9zx7A0ZX4aASV9kjGH1xRj qRfCVHMaA0uwO/HTwgae1UblwfEVEOBz7CdjRIntW/yA69ej09Nbj/FGTg30/BGilMl4 G9WK/1HDkKZKbzetHFW902eAdxWK46cV6GqnNnUUyRby4l4q5IkpxkuY+w2Q4qOI6Wcy ke/eCOFUTf1ZYzDPZ5Z15obylH/Mk60+BPxN/riNwJ49FMca5joee5a2bELgtyQxsSJP OXU4pNvF+RIKKfgTNghDKyBk1JxKsUk6w9E+7Sy2ynM6I8kz8zHahUR3xxoc2R+8hrpg vu8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=HFeJ+NlFKTF9cMY5q7GhrIw7yXj4o0vM2HzHaerMuak=; b=k7d+bM41Fmpgz+reOx/XPiyWS3Pki1VK/YpyxuM5RvwUXOvxVnNmers/HUcgld5oZR IUebB8lPjgTlgCKOFTyWgwWoPMki6Cb1FsGAqYuMLTDrsLSfmicZnjOPVeOR0BZoEXyK +dp2YAW/dWoQD84ilO7Nq6uPT8B++67wLDGWbRWyTbGKe+zuGAtfK6fY9O7KNzDxtHSc KAbLy1kqf7ILeQSQy09KBkhSG2i4jjFnZ5vYmaMuxJRGbI0sn1oEHeHEkKtsk4bH8XGS 4YH0GNulo73rZwhV+HfJ5nCo19jtWShkwHdmIJ6ApvwFmX/Lh3Si+mbqXjtskDoGLvCS gncw== X-Gm-Message-State: AOPr4FX0nR3GphMco1Q3qO1HWL0btvnXfzliqHnN28gtsInHqHndb2TnGUgnzgbNyRs8f/LR X-Received: by 10.55.172.72 with SMTP id v69mr16308300qke.45.1460620171335; Thu, 14 Apr 2016 00:49:31 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable017.46-176-173.mc.videotron.ca. [173.176.46.17]) by smtp.gmail.com with ESMTPSA id c66sm17393055qha.27.2016.04.14.00.49.29 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2016 00:49:30 -0700 (PDT) To: Ted Hardie , "rtcweb@ietf.org" , Cullen Jennings , Sean Turner References: From: Jean-Marc Valin Message-ID: <570F4B89.8080400@mozilla.com> Date: Thu, 14 Apr 2016 03:49:29 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Confirmation of DTMF issue 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, 14 Apr 2016 07:49:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 +1 On 04/13/2016 04:31 PM, Ted Hardie wrote: > With Martin's friendly amendments, the room at IETF 95 agreed to > the follow as the resolution of the DTMF discussion. The chairs > would like anyone who has new issues with this to let us know as > soon as possible and no later than Wednesday, April 20th, noon > UTC, > > > "DTMF events generated by a WebRTC endpoint MUST have a duration of > no more than 8000 ms and no less than 40 ms. The recommended > default duration is 100 ms for each tone. The gap between events > MUST be no less than 30 ms; the recommended default gap duration > is 70 ms. > > WebRTC endpoints are not required to do anything with RFC 4733 > tones sent to them, except gracefully drop them. There is currently > no API to inform JavaScript about the received DTMF or other RFC > 4733 tones." > > regards, > > Ted, Cullen, and Sean > > > _______________________________________________ rtcweb mailing > list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXD0uGAAoJEJ6/8sItn9q9378IAJIeqMRAVSpDoI1Hvoru27fw mjzfE7C/BwdW6KpuglQxDlNxli2r1sAw7RG49Ou4UQ/liHpnforkOsrqk3AbcT+o ONkmg1Leu1jGm+OUXBJ2hcpIs/OzqgmFAnImSmn2CdYD51EjWj5fdIByTmdUDQPE MQCES3bC1MbUHAL/62+7g1ChR3Ci0hay25kZnLl/LfsbOaJT+y0vV5Gw8RZoylTh lDoWHmfOV2OvS54kPvorQUJl/GC4YL0AH/pAVbwGCTgwyrpNcGW/YhjQmM8qD9ja XeKwN4IHSpwtdV4LeZ+1AfYDd+8w7sz53Ha1HPRN8zbnbp3sfFA9xl2a2w61r90= =ctMk -----END PGP SIGNATURE----- From nobody Thu Apr 14 09:43: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 AC7A112E69D for ; Thu, 14 Apr 2016 09:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=IVc3gMzS; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=ibVuimsW 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 kVzc-sPTosuA for ; Thu, 14 Apr 2016 09:42:57 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B01E612E69A for ; Thu, 14 Apr 2016 09:42:57 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 1F0CD20801 for ; Thu, 14 Apr 2016 12:42:56 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Thu, 14 Apr 2016 12:42:56 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=E2LZIwx15zIqIFljbZrXGmaVUP8=; b=IVc3gM zSJ2Q2ps+7QUIRJpRc9QbCUdWUwSY5RfbmyWWrouiiXwJz2bJ5Ox+MJ/IyXz+mdj lY2a0O706JCbDOl1c3TC9FXvkAQDsFmmYbebl9T8wAAti1sXnxBOaeKIjgz8bNZP ALDKFLOjN1k36lryI2B0ALBPVOwvWwi63bUwk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=E2LZIwx15zIqIFl jbZrXGmaVUP8=; b=ibVuimsWYLRJuujarUGc427p/hD8e/hkoyF3KlXpVKmUEfy mD+n+JbI4GMDHgoTAGULGIQSKvS5W4Z5tAVZ6pdd9itRlsp6CKmjOWbyzbqsPY3H okmPgZCa8UNW399OjdmMh58Iv0GFJ0JwpPQqngO66ds5BHUdn4ePNkMdkiYw= X-Sasl-enc: iJiRfKg+XljPM1R/Qxq2W3Kdx0wSYyPVkj2p8RopES2h 1460652175 Received: from dhcp-171-68-21-99.cisco.com (dhcp-171-68-21-99.cisco.com [171.68.21.99]) by mail.messagingengine.com (Postfix) with ESMTPA id 91BAB680250; Thu, 14 Apr 2016 12:42:55 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: <4F3B615A-A77A-434E-B3A9-DDABE8994373@cooperw.in> Date: Thu, 14 Apr 2016 09:42:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F3B615A-A77A-434E-B3A9-DDABE8994373@cooperw.in> To: ietf@ietf.org X-Mailer: Apple Mail (2.3112) Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Last call redux: draft-ietf-rtcweb-rtp-usage-26 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, 14 Apr 2016 16:43:00 -0000 No comments were received, so this document will revert to the RFC = Editor. > On Mar 23, 2016, at 1:44 PM, Alissa Cooper wrote: >=20 > draft-ietf-rtcweb-rtp-usage-25 was approved for publication in July = 2015 and is in the RFC Editor's queue. Subsequently, the RTCWEB WG = identified a change that needed to be made in Section 4.5 related to = multiplexing RTP and RTCP. The change is reflected in = draft-ietf-rtcweb-rtp-usage-26 and copied below. >=20 > The IESG will not revisit its decision to approve this document for = publication unless it receives feedback from the community indicating a = need to do so. Please send substantive comments to the ietf@ietf.org = mailing list by 2016-04-13. Exceptionally, comments may be sent to = iesg@ietf.org instead. >=20 > The change is: >=20 > OLD: >=20 > If SDP is used for signalling, this > negotiation MUST use the attributes defined in [RFC5761]. For > backwards compatibility, implementations are also REQUIRED to support > RTP and RTCP sent on separate transport-layer flows. >=20 > NEW: >=20 > If SDP is used for signalling, this > negotiation MUST use the mechanism defined in [RFC5761]. > Implementations can also support sending RTP and RTCP on separate > transport-layer flows, but this is OPTIONAL to implement. If an > implementation does not support RTP and RTCP sent on separate > transport-layer flows, it MUST indicate that using the mechanism > defined in [I-D.ietf-mmusic-mux-exclusive]. >=20 > The document is available at = https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Apr 14 10:18:48 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 4DD0212B071; Thu, 14 Apr 2016 10:18:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160414171846.6832.14090.idtracker@ietfa.amsl.com> Date: Thu, 14 Apr 2016 10:18:46 -0700 Archived-At: Cc: rtcweb@ietf.org, draft-ietf-rtcweb-audio@ietf.org, rtcweb-chairs@ietf.org Subject: [rtcweb] Alissa Cooper's Yes on draft-ietf-rtcweb-audio-10: (with COMMENT) 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, 14 Apr 2016 17:18:46 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-rtcweb-audio-10: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The text below is due to be added in Section 3 of the document, pending list confirmation of consensus in the room from IETF 95, which is due to wrap up on April 20. "DTMF events generated by a WebRTC endpoint MUST have a duration of no more than 8000 ms and no less than 40 ms. The recommended default duration is 100 ms for each tone. The gap between events MUST be no less than 30 ms; the recommended default gap duration is 70 ms. WebRTC endpoints are not required to do anything with RFC 4733 tones sent to them, except gracefully drop them. There is currently no API to inform JavaScript about the received DTMF or other RFC 4733 tones." From nobody Fri Apr 15 05:56:28 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 04C8012DA3F; Fri, 15 Apr 2016 05:56:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160415125624.15172.9206.idtracker@ietfa.amsl.com> Date: Fri, 15 Apr 2016 05:56:24 -0700 Archived-At: Cc: rtcweb@ietf.org, draft-ietf-rtcweb-audio@ietf.org, rtcweb-chairs@ietf.org Subject: [rtcweb] Alexey Melnikov's No Objection on draft-ietf-rtcweb-audio-10: (with COMMENT) 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, 15 Apr 2016 12:56:24 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-rtcweb-audio-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Section 5: AEC is a SHOULD implement with no reference. Is this well understood to be implementable without any reference? In section 8: acronym VBR is used for the first time without explanation. From nobody Fri Apr 15 08:22:15 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 AD57A12DA21; Fri, 15 Apr 2016 08:22:13 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -100.988 X-Spam-Level: X-Spam-Status: No, score=-100.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=ietf.org header.b=a3p+qOyv; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=cooperw.in header.b=IVc3gMzS; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=messagingengine.com header.b=ibVuimsW 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 hyCOBcXaAHq1; Fri, 15 Apr 2016 08:22:11 -0700 (PDT) Received: from ipo2.fzu.cz (ipo2.fzu.cz [147.231.27.21]) by ietfa.amsl.com (Postfix) with ESMTP id C69C912D977; Fri, 15 Apr 2016 08:22:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2FTKAC1BhFXfQga55Negwx/WCW8SQuFIkqBOkwBAQEBAQEEDwEBKFBBAQQNAYNtAQEBAwEBAQE3BgEBBAoeCwECAgEBAgYBAQoYJggDASMFGhEZBQ+IDQcBAQIBAQmvKIUoAQSNQAEBAQEGAQEBAQEBAQEBAQEPAgSEF4N/glaEPU6CX4IrAY5KiUaFeIh8gQGEToJ2hWaPJ4JbghFMd4RIhAcBAQE X-IPAS-Result: A2FTKAC1BhFXfQga55Negwx/WCW8SQuFIkqBOkwBAQEBAQEEDwEBKFBBAQQNAYNtAQEBAwEBAQE3BgEBBAoeCwECAgEBAgYBAQoYJggDASMFGhEZBQ+IDQcBAQIBAQmvKIUoAQSNQAEBAQEGAQEBAQEBAQEBAQEPAgSEF4N/glaEPU6CX4IrAY5KiUaFeIh8gQGEToJ2hWaPJ4JbghFMd4RIhAcBAQE X-IronPort-AV: E=Sophos;i="5.24,487,1454972400"; d="scan'208";a="12925768" Content-Type: multipart/mixed; boundary="===============0918431056564073326==" MIME-Version: 1.0 Received: from mail3.fzu.cz ([147.231.26.8]) by ipo2.fzu.cz with ESMTP; 15 Apr 2016 17:21:53 +0200 Received: by mail3.fzu.cz (Postfix, from userid 1481) id C2C2F204C4; Fri, 15 Apr 2016 17:21:52 +0200 (CEST) X-IronPort-Anti-Spam-Result: A0FuLQC0xw9XirZvHC5eGQEBAQGCb39YJbwhJAuBa4M3SoE9TAEBAQEBAQQPAQEBCBgHUEEBBA0BgWMhFxABAQEBAQElAQEBAQEBAQEBAQEBAQEBAQEBAQEWAggnDy0BAQEBAgEBAQE3BgEBBAoeCwECAgEBAgYBAQoYJggDASMfERkFD4gNBwEBAgEBCa9ChSgBBI1vAQEBAQYBAQEBAQEBAQEBAQ8CBIQXg3+CVoQ9TheCSIIrjkuJRYV3iHyBAYROgnWFZoc9h2qCW4IQTHeESIQHAQEB X-IPAS-Result: A0FuLQC0xw9XirZvHC5eGQEBAQGCb39YJbwhJAuBa4M3SoE9TAEBAQEBAQQPAQEBCBgHUEEBBA0BgWMhFxABAQEBAQElAQEBAQEBAQEBAQEBAQEBAQEBAQEWAggnDy0BAQEBAgEBAQE3BgEBBAoeCwECAgEBAgYBAQoYJggDASMfERkFD4gNBwEBAgEBCa9ChSgBBI1vAQEBAQYBAQEBAQEBAQEBAQ8CBIQXg3+CVoQ9TheCSIIrjkuJRYV3iHyBAYROgnWFZoc9h2qCW4IQTHeESIQHAQEB X-IronPort-AV: E=Sophos;i="5.24,485,1454972400"; d="scan'208";a="12901209" Received: from latimerie.flaska.net ([46.28.111.182]) by ipo2.fzu.cz with ESMTP; 14 Apr 2016 18:43:13 +0200 Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1900:3001:11::2c]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by latimerie.flaska.net (Postfix) with ESMTPS id F10A360208 for ; Thu, 14 Apr 2016 18:43:11 +0200 (CEST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D0912E6A8; Thu, 14 Apr 2016 09:43:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1460652183; bh=sMCxvcmIIFSnrTaODKOXpY78vw83eXYIaQuknPaXAb8=; h=Subject:From:In-Reply-To:Date:References:To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=a3p+qOyvvHiVA69rZKDLhqOKOkLGNpseSRg/smorHkq9NUTjKT6ATmz8zu5q/Bm9u nlK2TUJO3/UstpJAUyqL3qBMszVQ4gtvVzeqJLd4dSg4SUeqawGiwFScXwDyadnI8Z iT13fdGphigBT3xxODspZ/4igC+BNhcKUjc26ZYQ= X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA4D12E69B for ; Thu, 14 Apr 2016 09:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.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 7JAVjFVMmjnL for ; Thu, 14 Apr 2016 09:42:57 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB6812E694 for ; Thu, 14 Apr 2016 09:42:57 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 1C9CA207D8 for ; Thu, 14 Apr 2016 12:42:56 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 14 Apr 2016 12:42:56 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=E2LZIwx15zIqIFljbZrXGmaVUP8=; b=IVc3gM zSJ2Q2ps+7QUIRJpRc9QbCUdWUwSY5RfbmyWWrouiiXwJz2bJ5Ox+MJ/IyXz+mdj lY2a0O706JCbDOl1c3TC9FXvkAQDsFmmYbebl9T8wAAti1sXnxBOaeKIjgz8bNZP ALDKFLOjN1k36lryI2B0ALBPVOwvWwi63bUwk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=E2LZIwx15zIqIFl jbZrXGmaVUP8=; b=ibVuimsWYLRJuujarUGc427p/hD8e/hkoyF3KlXpVKmUEfy mD+n+JbI4GMDHgoTAGULGIQSKvS5W4Z5tAVZ6pdd9itRlsp6CKmjOWbyzbqsPY3H okmPgZCa8UNW399OjdmMh58Iv0GFJ0JwpPQqngO66ds5BHUdn4ePNkMdkiYw= X-Sasl-enc: iJiRfKg+XljPM1R/Qxq2W3Kdx0wSYyPVkj2p8RopES2h 1460652175 Received: from dhcp-171-68-21-99.cisco.com (dhcp-171-68-21-99.cisco.com [171.68.21.99]) by mail.messagingengine.com (Postfix) with ESMTPA id 91BAB680250; Thu, 14 Apr 2016 12:42:55 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: <4F3B615A-A77A-434E-B3A9-DDABE8994373@cooperw.in> Date: Thu, 14 Apr 2016 09:42:54 -0700 Message-Id: References: <4F3B615A-A77A-434E-B3A9-DDABE8994373@cooperw.in> To: ietf@ietf.org X-Mailer: Apple Mail (2.3112) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Errors-To: ietf-bounces@ietf.org Sender: "ietf" Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Last call redux: draft-ietf-rtcweb-rtp-usage-26 X-BeenThere: rtcweb@ietf.org List-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, 15 Apr 2016 15:22:13 -0000 --===============0918431056564073326== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable No comments were received, so this document will revert to the RFC = Editor. > On Mar 23, 2016, at 1:44 PM, Alissa Cooper wrote: >=20 > draft-ietf-rtcweb-rtp-usage-25 was approved for publication in July = 2015 and is in the RFC Editor's queue. Subsequently, the RTCWEB WG = identified a change that needed to be made in Section 4.5 related to = multiplexing RTP and RTCP. The change is reflected in = draft-ietf-rtcweb-rtp-usage-26 and copied below. >=20 > The IESG will not revisit its decision to approve this document for = publication unless it receives feedback from the community indicating a = need to do so. Please send substantive comments to the ietf@ietf.org = mailing list by 2016-04-13. Exceptionally, comments may be sent to = iesg@ietf.org instead. >=20 > The change is: >=20 > OLD: >=20 > If SDP is used for signalling, this > negotiation MUST use the attributes defined in [RFC5761]. For > backwards compatibility, implementations are also REQUIRED to support > RTP and RTCP sent on separate transport-layer flows. >=20 > NEW: >=20 > If SDP is used for signalling, this > negotiation MUST use the mechanism defined in [RFC5761]. > Implementations can also support sending RTP and RTCP on separate > transport-layer flows, but this is OPTIONAL to implement. If an > implementation does not support RTP and RTCP sent on separate > transport-layer flows, it MUST indicate that using the mechanism > defined in [I-D.ietf-mmusic-mux-exclusive]. >=20 > The document is available at = https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --===============0918431056564073326== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Upozorn=C4=9Bn=C3=AD / Disclaimer --===============0918431056564073326==-- From nobody Sun Apr 17 22:44:28 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 9BD0112D099; Sun, 17 Apr 2016 22:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.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 qUxAMvzf5ud2; Sun, 17 Apr 2016 22:44:25 -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 71DA412D0EB; Sun, 17 Apr 2016 22:44:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 3E6F57C43F0; Mon, 18 Apr 2016 07:44:23 +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 VFrHxgB6bCCT; Mon, 18 Apr 2016 07:44:22 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:12:4dbe:631f:43e:d0c4]) by mork.alvestrand.no (Postfix) with ESMTPSA id 023B47C0625; Mon, 18 Apr 2016 07:44:21 +0200 (CEST) To: Alexey Melnikov , The IESG References: <20160415125624.15172.9206.idtracker@ietfa.amsl.com> From: Harald Alvestrand Message-ID: <57147435.1040400@alvestrand.no> Date: Mon, 18 Apr 2016 07:44:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160415125624.15172.9206.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: rtcweb@ietf.org, draft-ietf-rtcweb-audio@ietf.org, rtcweb-chairs@ietf.org Subject: Re: [rtcweb] Alexey Melnikov's No Objection on draft-ietf-rtcweb-audio-10: (with COMMENT) 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, 18 Apr 2016 05:44:27 -0000 On 04/15/2016 02:56 PM, Alexey Melnikov wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In Section 5: AEC is a SHOULD implement with no reference. Is this well > understood to be implementable without any reference? I believe the concept of AEC (echo cancellation) is sufficiently well understood that it can be implemented without a reference. Specific echo cancellation algorithms are typically quite fluid and/or proprietary; I do not believe that the Internet would benefit from referencing any single AEC algorithm. Two endpoints do not need to agree on an AEC algorithm to function. > > In section 8: acronym VBR is used for the first time without explanation. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Apr 18 00:26:48 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 8795A12DD80 for ; Mon, 18 Apr 2016 00:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=CnP/rhea; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=Pw4UvQmT 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 H9SovMmnU450 for ; Mon, 18 Apr 2016 00:26:46 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08FCD12DD5F for ; Mon, 18 Apr 2016 00:26:46 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 6A12820BCF for ; Mon, 18 Apr 2016 03:26:45 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 18 Apr 2016 03:26:45 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=UU7A5jY24bwXnfJy4vrC2mNmAuw=; b=CnP/rh eamTc/vG+2WQjPOYDI15vuOMT8TULuZoIjZI787oRvW40hBCQx7yrDr1/Zy+2bHE h7koM4A2EoLGX9gZUZOkWhLlzFxact+D75DxJ7eG0S82f7OLqACyj2O2OyaYzcXz 3d1qOa0aN8RH2FVnqqwH4Vs9mJaE6O7ZpntgY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=UU7A5jY24bwXnfJ y4vrC2mNmAuw=; b=Pw4UvQmTunxNr6ua6jAg/ukfmXRAsP4v8Btd+yIg/6TBKwI wjgySgLWdDZBObWc10ZJfk1lmU0hygDHmTgiQhHzDuX/Lib7vGrjdsHg5Pomvp11 FbBw37h2InGAG79Poud0nGZcy2LhFOua5Ogkvsso8enMsZ+wixTdnKJdm/CA= X-Sasl-enc: Y/rZbHOx0aHcltYO8xe3BvZbq/Dv9ORA3GfjY83JZHwI 1460964405 Received: from [10.0.151.254] (unknown [212.183.128.129]) by mail.messagingengine.com (Postfix) with ESMTPA id ED95BC00017; Mon, 18 Apr 2016 03:26:44 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13E238) In-Reply-To: <57147435.1040400@alvestrand.no> Date: Mon, 18 Apr 2016 08:30:59 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <20160415125624.15172.9206.idtracker@ietfa.amsl.com> <57147435.1040400@alvestrand.no> To: Harald Alvestrand Archived-At: Cc: rtcweb@ietf.org, The IESG , rtcweb-chairs@ietf.org, draft-ietf-rtcweb-audio@ietf.org Subject: Re: [rtcweb] Alexey Melnikov's No Objection on draft-ietf-rtcweb-audio-10: (with COMMENT) 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, 18 Apr 2016 07:26:47 -0000 Hi Harald, > On 18 Apr 2016, at 06:44, Harald Alvestrand wrote: > >> On 04/15/2016 02:56 PM, Alexey Melnikov wrote: >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> In Section 5: AEC is a SHOULD implement with no reference. Is this well >> understood to be implementable without any reference? > > I believe the concept of AEC (echo cancellation) is sufficiently well > understood that it can be implemented without a reference. > > Specific echo cancellation algorithms are typically quite fluid and/or > proprietary; I do not believe that the Internet would benefit from > referencing any single AEC algorithm. > Two endpoints do not need to agree on an AEC algorithm to function. Ok, fair enough. It would be good to expand the acronym for ignorant people like me though. > >> >> In section 8: acronym VBR is used for the first time without explanation. >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Mon Apr 18 00:47: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 1E87112DA93; Mon, 18 Apr 2016 00:46:59 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 Vxvs_MdykNBk; Mon, 18 Apr 2016 00:46:57 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0122.outbound.protection.outlook.com [104.47.93.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A597112DA59; Mon, 18 Apr 2016 00:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8nHNYab7t2VUg/qqrvgMxRiMWxDAiVnrohAiH0wzS6w=; b=PedftEzQlsnegw6CioximlcnH+K+m88ELxnNu2UfeoRuOH5DM+X0IIcUVvYdIgOsEL/SyhfeCfDx8gEORYK7gT+6EJJfNmX7OOeayOBXj9VNWi5uSllVh8nrZ+k3ka2pMfdOOo8cGC8nJ2pmsmtruDVqonUDlcQ9OjS7ZwptW+M= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TYXPR01MB0926.jpnprd01.prod.outlook.com (10.168.45.21) with Microsoft SMTP Server (TLS) id 15.1.453.26; Mon, 18 Apr 2016 07:46:53 +0000 To: Alexey Melnikov , Harald Alvestrand References: <20160415125624.15172.9206.idtracker@ietfa.amsl.com> <57147435.1040400@alvestrand.no> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <571490EB.3080306@it.aoyama.ac.jp> Date: Mon, 18 Apr 2016 16:46:51 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OS2PR01CA0041.jpnprd01.prod.outlook.com (10.164.161.151) To TYXPR01MB0926.jpnprd01.prod.outlook.com (10.168.45.21) X-MS-Office365-Filtering-Correlation-Id: 5c6876e2-d7ab-4c49-7913-08d3675d9c23 X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0926; 2:leBhtP/AmLIh9QXbGQ2njuecYExqf5Ne4GpWsyLvZN3mZqQPuVWRS0aNrJMvj5YIXxytQNTFgwJSg1q52wy0HYsNsnhjFRazalu3w1Yxrrpi4swSJqle7lWH6XFATUw9UNKYezHmccfJ8VtuEIS1eK+1QSIGIZc9W7rxm8F2j+anTg95aStiwBJqhPKeOEZj; 3:GYwra4QtB2VS7Uuhnt/fYa2hU+gHnXZ5XBmNjeWtf7u1DV8q5QPusYGXgV8MREE7bONunWPk8vOV2xF4C/5xpHt7ZkN0tp2vAAJsEQkAbzoSyCceEtAs+ypTLXqWypYo; 25:ZgkufvpGQ9+KNXO85itUxF3nWZtJC0FR4WwlBqp6Melz/aFx8xuOzH0ONNtxU/N3lBo8PixFgBGTc4PgXcGn0Kadm9Q7wgK2QOm7dJ7/mS5gP/VxETrF3aZOTCnBZKW8dUk7ytaGOukS1o6ny5TeDLb95f6UsZUpq/t4AvOqjGqr/0nIKuLmQ8/soAWrI3Wxyh3TDNbys3bEGRHgGFYxel6dzF89+IR1IQ0lwUSfUz1RVqyGari8ZbZESbavAnoWee+y74a2zEGf+n7HYqGnH5axd1brs0m9VvZ0ssP3jCkFghTd2MTFZaKMzVYexRr4t5ggFEuk2HuPynIBLW0S/cml3SEOmEmF+nkNdjoxBoNm2kMRVT/yUYUygg9AVfd1NlYU2eUrikiRBHSEoXRAOREHK/lEsU6SQhQaT2zZerOgeKgjwuJ2JKeSAmezKdH4FwPSONZVt4NhyT+AfyuCF8L8vlc+1/+vgKTG3DONZgZF0ESvZJKl7fakmXM+cX75mn18UtN2TAIc+49gPA6uMSy+oY6iX31doqoMBLGZCvxPRRuNVZUVb6OHH/uUCsg8Oobf4Y7JOJ6NpeWh9L/lwI78d8GoISPHmyqWVmgwIj061QHi74bLwEMfrtC77lz6 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TYXPR01MB0926; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(9101521026)(6040130)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041046)(6043046); SRVR:TYXPR01MB0926; BCL:0; PCL:0; RULEID:; SRVR:TYXPR01MB0926; X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0926; 4:c8Ax/0izw4K1rvngfsNOGCHnXuJ98l6MhT05Y3iSqFIU4y9n0NZhE6PDnONiO0TwPDgXzWH7sJkks7aE/FuraqYpYdaH7/Ls1OELcXuOeDFCqpDqBIGJ9AlQ3BiEQ6Uh1Y4AgkE7WqaAFhEq/AEcAgTuAX5ZmfNAwVyyb6MitT5qzklclIpE7M9DNr7rOXe8kIEcre3nPjjDDkXRZfHpV26/r6KBCgp2zzGRtrEETvYEYZI73KFifaKg/fad+A6ywy2WGnwP0OILdvLCfKfslJm7PLK6g98t5LDbwUk4qmQfdFjF92GMMfE6CKWO9EJwXFip3Qh4gj4X4haLJ7uwjWROt5FA99akQ08HnKcBsVhZXbitYunCFD0BYDklbKH7Z1eg/yXVBnwHqkPpb4F2MLMU66YMXqTZO9yL5IExOvrIvUslxaEHnKo1aWlU1ORe X-Forefront-PRVS: 0916FC3A18 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(24454002)(23676002)(19580395003)(19580405001)(81166005)(80316001)(4001350100001)(2950100001)(77096005)(5008740100001)(2906002)(189998001)(92566002)(83506001)(74482002)(33656002)(65956001)(230783001)(3846002)(586003)(65816999)(6116002)(50466002)(1096002)(47776003)(86362001)(42186005)(230700001)(64126003)(4326007)(54356999)(50986999)(65806001)(99136001)(5004730100002)(87266999)(76176999)(66066001)(5001770100001)(7059030)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TYXPR01MB0926; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWVhQUjAxTUIwOTI2OzIzOm0xay9JNzNjVTZOalhEZG1jejl4Sk5tbVFN?= =?utf-8?B?OWxNVC9GYlR6VVNNOC93a01IMWxuc1huR202MHNFSHNESmpXSnNjcTREcG1I?= =?utf-8?B?MlpUb09JaGtRbjFvWk9xMmdrQ2JsZWl1Tk9EOWpvMjRjSmRwZTV6eFhRYmFa?= =?utf-8?B?dTdUMUMyVURRbjlnbzM0NmhvRFYwdjJMZUNsbSs0LzNpZGZGRXJQaUFaRjNr?= =?utf-8?B?dEhmTDM3Y3NBNW1yZXJWcjFlb1hLbmRiRkxZSkpibXZlRi9YMnRvVXVxSlhR?= =?utf-8?B?bmt0alpWVTVZVTlQZHR3bGEvNjdLM3B2VkZLblFnd2REMkU5T3d3azFsdnpL?= =?utf-8?B?RjhXQWp0TTJDNnlZanUwKyt3K1cvLzBOL0p2amtGaWVoQ3dzSEQ1bVZvSGNu?= =?utf-8?B?Q0JNMDlVOGNVZHdTb1B4ZzRWSS9teGdDaHNkcDlBWndVSVlOaDMxV3pBdGU1?= =?utf-8?B?TzJIZlhGYVNRcVpvaEFIVkQ3RmxCKzdZQ2NxMEU0bnp1VTVqdU1DeXY0YXV5?= =?utf-8?B?OUFteFlCT290Qnl5ZW8wU0RaZDNPVHpiY2VaZ29VT0ZJbkZwSzM3MlJJT0ZR?= =?utf-8?B?Y2w1bHc3aFJBcU1SNERZdXU2SDJWemo4dm5ucys3TkZsQ1Fkd05SYlRsMGZp?= =?utf-8?B?OVhvOFR0cWFwZ2dJeWw3S0V1cFJHQTRaV1RHYmNZNnJ0eFdzUmZ1VUo5Yncx?= =?utf-8?B?eUcxNkpMOGxyQ3BicjZrZS91Vy9QR0t0TlBxaUs2RFlFN1hrQTI2c3VOTUxE?= =?utf-8?B?cUljWTViS01vYjV3bTNYNnRNOXlaRmtwMEx6eklxZVFQK1kzOEs1Yzdtc3py?= =?utf-8?B?TTdhc2pKYUR0eHFwVEc4YVI2Nm5oZnZpdHRlYnUvbFRCMm8vbE9VK1p6ejdN?= =?utf-8?B?NEYzL2FyOHVudTltMEkwZk5SUjdTY09mMTJIK0ovOEJjbDBxZzdrbDBEK1pW?= =?utf-8?B?aFczeGJEQUhoMDRrR1FlT3crUS9sQ1BSelZOb3VUTEQ4QXBYeEk2VUpHYUZu?= =?utf-8?B?anFnalhaOVJObjJKa0l0R1ZTSFRGMG8vbk0rRjczbEwrK3ZKUzlRY21XZFBF?= =?utf-8?B?R2FIZ1lNV05BekhwUmNreFE1REpIL0liNWVUdVIxRk0vLzRSZGJNOHFPUnhV?= =?utf-8?B?NDZIQVdpNHZzejJRQkttc2xEdithL2QraHRiUVJVdUpXTnBid2pZeHRhTFBo?= =?utf-8?B?eXhCUUJUdlFVd2lnSnhMVGxiNmYvR3l2R2xMd2NjNFEwS3Q2cm9RZU11R2hB?= =?utf-8?B?QUd5RVpXOHNQc1ErdnNHRkF1U0FraVF2cC8vazZtYndlbjk0L2JrQUh3Y0hh?= =?utf-8?B?cXFxelZjVUg5Q1R0NW9ZOXBwTG1salFKRXUwbENnaWdEUTNWNjRWc011QzdN?= =?utf-8?B?NG9JOWdiVWdGdlZvbVBVb0pPOFFqMU9UVHNncHhkOSs0TjdaL05qOE93aVEx?= =?utf-8?B?bUJTNVJzNjMvRU5hdWV1UjVZVHVNNUozeVpuV2RuT01VdzdhUGljdVpFZG11?= =?utf-8?Q?AOeodnl4u6ic7c79Umj19lnarJmANAsmxzApb8YgCrpkWB?= X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0926; 5:ZFNcBOElDWdY1SFxSKDIruc88G0AgDdoPZAEwUP6HYJp+J3Jy9nutBcZqvfzV29qol8EJ4QqqUjIGB/HvKhNFM+KwPxXh8jlsJAoeq9nbf2bHarDoT3JlcTTuZPV/uE2VptdDXZHWlN72eF5ek/SbA==; 24:dqcOcJaIFaKyVD1ZBWE0wO+ODN/x56f5ZWUE7GqyOkyHgvmamPBMLA+rDLFezLGR0Qc8eCHWsDBzsJtzIfzTJX0+kZlOrmtBnJ5B/DUbqyY= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Apr 2016 07:46:53.6061 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYXPR01MB0926 Archived-At: Cc: rtcweb@ietf.org, The IESG , rtcweb-chairs@ietf.org, draft-ietf-rtcweb-audio@ietf.org Subject: Re: [rtcweb] Alexey Melnikov's No Objection on draft-ietf-rtcweb-audio-10: (with COMMENT) 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, 18 Apr 2016 07:46:59 -0000 On 2016/04/18 16:30, Alexey Melnikov wrote: >> On 18 Apr 2016, at 06:44, Harald Alvestrand wrote: >>> In Section 5: AEC is a SHOULD implement with no reference. Is this well >>> understood to be implementable without any reference? >> >> I believe the concept of AEC (echo cancellation) is sufficiently well >> understood that it can be implemented without a reference. >> >> Specific echo cancellation algorithms are typically quite fluid and/or >> proprietary; I do not believe that the Internet would benefit from >> referencing any single AEC algorithm. >> Two endpoints do not need to agree on an AEC algorithm to function. > > Ok, fair enough. > > It would be good to expand the acronym for ignorant people like me though. I wanted to make exactly the same comment, but then I checked, and the expansion is given in the TOC and the title of section 5 (the only place where the acronym is used without expansion), so it might be good enough. Regards, Martin. From nobody Mon Apr 18 01:41: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 A00BF12E02D for ; Mon, 18 Apr 2016 01:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=gNlquIlo; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=C3lC8+XV 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 4YKrpOPG-4Nh for ; Mon, 18 Apr 2016 01:41:18 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52B1112DFEF for ; Mon, 18 Apr 2016 01:41:18 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id BC77C20246 for ; Mon, 18 Apr 2016 04:41:17 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 18 Apr 2016 04:41:17 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=yw8RinnxhT4lNN7m6PJSlZKgKOM=; b=gNlquI loJKBdeWa63SI8KZlLAe8q/mUxA1Ucr3kFxkkfKI12Cc+pfKrfwG5EaiZNXTiXpK vSGjivulOy9mG61fB6HDqBGi2An/JSwjvUCYiujdojBy+M4AUbaoODbbziy+LJsk 1HQjKruIWR9vPuCOrChB4BzZDlaNByalBq2RQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=yw8RinnxhT4lNN7 m6PJSlZKgKOM=; b=C3lC8+XVtnnp/UpIjyGPEwxXzM5o+sBGU5TKJOLWMzhoYyU PQgkZQ8S+ts5oiPsDThvOMc3XvhSVfTH92NCdRH6wH2Hfy/d870KX8dKro73TGMc U9STw8xtL7FXxQYob0Ordb5LLeaR/BkG6D14bZSBax2VDcocRIaYZdliVsk4= X-Sasl-enc: sGsDl11Y/PlZB/tJfZxaABOk2atnZPHJbj9qEX2TxOMU 1460968877 Received: from [10.0.151.254] (unknown [212.183.128.129]) by mail.messagingengine.com (Postfix) with ESMTPA id 47342C00017; Mon, 18 Apr 2016 04:41:17 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13E238) In-Reply-To: <571490EB.3080306@it.aoyama.ac.jp> Date: Mon, 18 Apr 2016 09:45:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <21137C25-5911-4F61-AE9D-13EB25C36D6B@fastmail.fm> References: <20160415125624.15172.9206.idtracker@ietfa.amsl.com> <57147435.1040400@alvestrand.no> <571490EB.3080306@it.aoyama.ac.jp> To: =?utf-8?Q?"Martin_J._D=C3=BCrst"?= Archived-At: Cc: rtcweb@ietf.org, The IESG , rtcweb-chairs@ietf.org, draft-ietf-rtcweb-audio@ietf.org Subject: Re: [rtcweb] Alexey Melnikov's No Objection on draft-ietf-rtcweb-audio-10: (with COMMENT) 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, 18 Apr 2016 08:41:19 -0000 > On 18 Apr 2016, at 08:46, Martin J. D=C3=BCrst wr= ote: >=20 > On 2016/04/18 16:30, Alexey Melnikov wrote: >=20 >>> On 18 Apr 2016, at 06:44, Harald Alvestrand wrote= : >=20 >>>> In Section 5: AEC is a SHOULD implement with no reference. Is this well= >>>> understood to be implementable without any reference? >>>=20 >>> I believe the concept of AEC (echo cancellation) is sufficiently well >>> understood that it can be implemented without a reference. >>>=20 >>> Specific echo cancellation algorithms are typically quite fluid and/or >>> proprietary; I do not believe that the Internet would benefit from >>> referencing any single AEC algorithm. >>> Two endpoints do not need to agree on an AEC algorithm to function. >>=20 >> Ok, fair enough. >>=20 >> It would be good to expand the acronym for ignorant people like me though= . >=20 > I wanted to make exactly the same comment, but then I checked, and the exp= ansion is given in the TOC and the title of section 5 (the only place where t= he acronym is used without expansion), so it might be good enough. Ok. RFC Editor is quite good at fixing these anyway. From nobody Mon Apr 18 08:00: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 7CEB012D8FA for ; Mon, 18 Apr 2016 08:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-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 03xTJ0wbEfMP for ; Mon, 18 Apr 2016 07:59:58 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6367212D7DA for ; Mon, 18 Apr 2016 07:59:58 -0700 (PDT) Received: by mail-ig0-x235.google.com with SMTP id f1so74928932igr.1 for ; Mon, 18 Apr 2016 07:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=/2X85TYujLShjb8N9f4zk7/Wakys+Nwa6CAx2DBtLLY=; b=zxFIcrIyBwDTqUO8NSUocuMoS0Vf/IH3vUy6E/+ozeJ6MsxjK7t3PkyyKvvrjVZinC jE+pL97SnQ0fpGs46VMsSo5dQfPMeZvZUpeTqbNBZHvlnQWEHjJetLbOmXBSvQPZd9Wm MtC9hON9/IZgL22/ylvRX1/F3rmQMsiOU/FvFBxctbBKgyvOAuKb6TnSA4zaHSsU4K7p YZ7cNirOrsW9pqLUQkNpuDTT+0p37Z6fCWyukH9nKKKMTnOpMQFJL3mkBMLNehqDPQvw G54TYeYBCCymXIldPOWJvivHVZdw+tF+LS4Lm5to0E65MpL2qqjSL+wfqw1JCwF7qccG zAcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/2X85TYujLShjb8N9f4zk7/Wakys+Nwa6CAx2DBtLLY=; b=jCydJNGt6rXKx+dZvEGym24Pi5pMlxeWaj9ucd2zs7+8rha7ftzmubYXddpQChS5dr xmcsvMZH7c54n6SNiDmPI+dluY0gw1UpIgjOok3QiCTKbnnHoEfstb5kvlPy2qFF/MXa dW89Jo37rd1brMPFzlwGB40ryr0aYMsECas7eyPYJ2pq6kJ8cMTFL7BS2fVRdvunvc9F ml8MWK/YdnV63Hss6cI4B6HUTTTRx6PdyeajNiqsy+YMB2/a953U7Zz8wuQlLXKvTAck AaEcwPimnpcXhvpd00XU7Ueff3AoXDf7yyeaANN4Dpzl/YYF4yyT1i5yq4mVXgEXDQuT jK0w== X-Gm-Message-State: AOPr4FXPE5agAFxtiiZ8OXDKQ1pNAc/5B79oooJ3A3uJSXWM64WKR/fbou6JMoT73FSKyw== X-Received: by 10.50.118.225 with SMTP id kp1mr20644844igb.9.1460991597612; Mon, 18 Apr 2016 07:59:57 -0700 (PDT) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com. [209.85.223.169]) by smtp.gmail.com with ESMTPSA id ke5sm3660185igb.17.2016.04.18.07.59.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Apr 2016 07:59:56 -0700 (PDT) Received: by mail-io0-f169.google.com with SMTP id g185so197162200ioa.2; Mon, 18 Apr 2016 07:59:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.160.141 with SMTP id j135mr42233717ioe.171.1460991596536; Mon, 18 Apr 2016 07:59:56 -0700 (PDT) Received: by 10.36.144.69 with HTTP; Mon, 18 Apr 2016 07:59:56 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 Apr 2016 10:59:56 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1140a2b621b1a00530c39d18 Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [rtcweb] Tunnelling DTLS in SDP 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, 18 Apr 2016 15:00:01 -0000 --001a1140a2b621b1a00530c39d18 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla wrote: > I wanted to call your attention to a draft I just published with a > possibly stupid > idea. > > https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 > > A nontrivial fraction of call setup time in WebRTC is the DTLS handshake. > This document describes how to piggyback the first few handshake messages > in the SDP offer/answer exchange, thus reducing latency. > > Comments welcome. > > One other issue I thought off was that with DTLS SDP either offerer or answerer can start a new DTLS association. When answerer starts a new session it will have exactly the same problems as forking, since this will create multiple DTLS sessions with the same client random. This can be solved with some sort of fallback mechanism to either regular DTLS setup or to sending a ClientHello in the answer. Regards, _____________ Roman Shpount --001a1140a2b621b1a00530c39d18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla <ekr@rtfm.com>= wrote:
I wanted to call your attention to a draft I just published w= ith a possibly stupid
idea.

https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00

A nontrivial fraction of call setup time in WebRTC is= the DTLS handshake.
This document describes how to piggyback the= first few handshake messages
in the SDP offer/answer exchange, t= hus reducing latency.

Comments welcome.
=

One other issue I thought = off was that with DTLS SDP either offerer or answerer can start a new DTLS = association. When answerer starts a new session it will have exactly the sa= me problems as forking, since this will create multiple DTLS sessions with = the same client random. This can be solved with some sort of fallback mecha= nism to either regular DTLS setup or to sending a ClientHello in the answer= .

Regards,
_____________
Roman Shpount
=C2=A0
--001a1140a2b621b1a00530c39d18-- From nobody Mon Apr 18 23:19:10 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 7D74412D174; Mon, 18 Apr 2016 23:19:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160419061908.10998.29452.idtracker@ietfa.amsl.com> Date: Mon, 18 Apr 2016 23:19:08 -0700 Archived-At: Cc: draft-ietf-rtcweb-audio-codecs-for-interop@ietf.org, rtcweb@ietf.org, rtcweb-chairs@ietf.org, liushucheng@huawei.com Subject: [rtcweb] Benoit Claise's No Objection on draft-ietf-rtcweb-audio-codecs-for-interop-05: (with COMMENT) 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, 19 Apr 2016 06:19:08 -0000 Benoit Claise has entered the following ballot position for draft-ietf-rtcweb-audio-codecs-for-interop-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio-codecs-for-interop/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Shucheng LIU's OPS DIR review: **** Editorial **** * Section 2, page 3: > > o Legacy networks: In this document, legacy networks encompass the > conversational networks that are already deployed like the PSTN, > the PLMN, the IP/IMS networks offering VoIP services, including > 3GPP "4G" Evolved Packet System[TS23.002] Missing space in "Evolved Packet System[TS23.002]" * Section 2, page 3: > o PSTN:Public Switched Telephone Network Missing space. * Section 3, page 4: > Consequently, > a significant number of calls are likely to occur between terminals > supporting WebRTC endpoints and other terminals like mobile handsets, > fixed VoIP terminals, DECT terminals that do not support WebRTC > endpoints nor implement OPUS. Seems should s/terminals, DECT terminals/terminals, and DECT terminals/ * Section 3: each of the bullets is separated by two blank lines rather than a single one. * Section 4.1.1, page 5: > especially s/especially/specially/ * Section 4.1.3, page 5: > The payload format to be used for AMR-WB is described in [RFC4867] > with bandwidth efficient format and one speech frame encapsulated in > each RTP packets s/packets/packet/ * Section 4.2.1, page 6: > This include both mobile phone calls using GSM and 3G s/include/includes/ * Section 4.2.1, page 6: > such as, GSMA voice IMS profile for VoLTE in [IR.92]. Please remove the comma. * Section 4.2.1, page 6: > degrading the high efficiency over mobile radio access.References > for Missing space. * Section 4.2.3, page 7: > The payload format to be used for AMR is described in [RFC4867] with > bandwidth efficient format and one speech frame encapsulated in each > RTP packets. s/packets/packet/ From nobody Tue Apr 19 07:39:33 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 0E44612D125; Tue, 19 Apr 2016 07:39:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160419143929.31609.3320.idtracker@ietfa.amsl.com> Date: Tue, 19 Apr 2016 07:39:29 -0700 Archived-At: Cc: draft-ietf-rtcweb-audio-codecs-for-interop@ietf.org, rtcweb@ietf.org, rtcweb-chairs@ietf.org Subject: [rtcweb] Stephen Farrell's No Objection on draft-ietf-rtcweb-audio-codecs-for-interop-05: (with COMMENT) 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, 19 Apr 2016 14:39:29 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-rtcweb-audio-codecs-for-interop-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio-codecs-for-interop/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- section 3: MOS could do with a reference From nobody Tue Apr 19 23:58:15 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 BED9A12EC0C for ; Tue, 19 Apr 2016 23:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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 cgMkOG1MIzsY for ; Tue, 19 Apr 2016 23:58:11 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0AF012D741 for ; Tue, 19 Apr 2016 23:58:10 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 1795D18C346; Wed, 20 Apr 2016 08:58:09 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.2]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id EA7484C066; Wed, 20 Apr 2016 08:58:08 +0200 (CEST) Received: from OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0279.002; Wed, 20 Apr 2016 08:58:08 +0200 From: To: Magnus Westerlund , "rtcweb@ietf.org" , Justin Uberti Thread-Topic: [rtcweb] AMR and max-red in draft-ietf-rtcweb-fec Thread-Index: AQHRj35tBYF7jDlHHEyG7ti7A8dS5598mJBAgAAVI/CAAcXYAIAUEG1w Date: Wed, 20 Apr 2016 06:58:08 +0000 Message-ID: <16166_1461135489_57172880_16166_19564_1_2842AD9A45C83B44B57635FD4831E60A11EA2D92@OPEXCLILM44.corporate.adroot.infra.ftgroup> References: <570427BD.2040506@ericsson.com> <11040_1459930679_5704C637_11040_8908_1_2842AD9A45C83B44B57635FD4831E60A11E954E6@OPEXCNORM4C.corporate.adroot.infra.ftgroup> <10237_1459934884_5704D6A4_10237_1748_1_2842AD9A45C83B44B57635FD4831E60A11E96567@OPEXCNORM4C.corporate.adroot.infra.ftgroup> <57066F04.3090904@ericsson.com> In-Reply-To: <57066F04.3090904@ericsson.com> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.20.61517 Archived-At: Subject: Re: [rtcweb] AMR and max-red in draft-ietf-rtcweb-fec 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, 20 Apr 2016 06:58:13 -0000 Hello Magnus, Sorry for the late answer In order to ensure proper interworking it is worth having a real normative = "MUST" here. > OLD: > For AMR/AMR-WB, support for redundant encoding, and the maximum > supported depth, are controlled by the 'max-red' parameter, as > specified in [RFC4867], Section 8.1. > > NEW: > For AMR/AMR-WB, support for redundant encoding, and the maximum > used depth, is indicated by the 'max-red' parameter, as > specified in [RFC4867], Section 8.1 and 8.2. The 3GPP Multimedia > Telephony services specifies a maximum value of 220 ms for > 'max-red', see [3GPP.26.114]. If AMR or AMR-WB are offered for inter= operability purpose, > see [draft-ietf-rtcweb-audio-codecs-for-interop], the max-red paramet= er MUST be included > in the offer and answer and set to an integer value multiple of 20ms n= ot exceeding 220ms. St=E9phane -----Message d'origine----- De=A0: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Envoy=E9=A0: jeudi 7 avril 2016 16:30 =C0=A0: PROUST St=E9phane IMT/OLPS; rtcweb@ietf.org; Justin Uberti Objet=A0: Re: [rtcweb] AMR and max-red in draft-ietf-rtcweb-fec Hi, I am generally fine with Stephane's proposal. I do note that the "must"=20 in the last sentence probably need to be a "MUST", otherwise if the intenti= on is just to point to requirements that exists, then please reformulate th= is to not use RFC2119 terms, even in lower cases. Cheers Magnus Den 2016-04-06 kl. 06:28, skrev stephane.proust@orange.com: > Sorry, the last part of the sentence in the proposal was missing : the = max-red parameter must be included > in the offer and answer and set to an integer value multiple of 20ms n= ot exceeding 220ms. > > OLD: > For AMR/AMR-WB, support for redundant encoding, and the maximum > supported depth, are controlled by the 'max-red' parameter, as > specified in [RFC4867], Section 8.1. > > NEW: > For AMR/AMR-WB, support for redundant encoding, and the maximum > used depth, is indicated by the 'max-red' parameter, as > specified in [RFC4867], Section 8.1 and 8.2. The 3GPP Multimedia > Telephony services specifies a maximum value of 220 ms for > 'max-red', see [3GPP.26.114]. If AMR or AMR-WB are offered for inter= operability purpose, > see [draft-ietf-rtcweb-audio-codecs-for-interop], the max-red paramet= er must be included > in the offer and answer and set to an integer value multiple of 20ms n= ot exceeding 220ms. > > -----Message d'origine----- > De : rtcweb [mailto:rtcweb-bounces@ietf.org] De la part de=20 > stephane.proust@orange.com Envoy=E9 : mercredi 6 avril 2016 10:18 =C0 := =20 > Magnus Westerlund; rtcweb@ietf.org; Justin Uberti Objet : Re: [rtcweb]=20 > AMR and max-red in draft-ietf-rtcweb-fec > > Hello Magnus > > I support your proposal. I would even suggest to relate this to the draft= -ietf-rtcweb-audio-codecs-for-interop (where more information about use of = AMR and AMR-WB is provided ) and specify more explicitly to include it in t= he offer/answer with an integer value multiple of 20ms not exceeding 220ms. > However, we can stay with your initial proposal if you or anyone else thi= nks it is preferable. > > Kind regards > > St=E9phane > > OLD: > For AMR/AMR-WB, support for redundant encoding, and the maximum > supported depth, are controlled by the 'max-red' parameter, as > specified in [RFC4867], Section 8.1. > > NEW: > For AMR/AMR-WB, support for redundant encoding, and the maximum > used depth, is indicated by the 'max-red' parameter, as > specified in [RFC4867], Section 8.1 and 8.2. The 3GPP Multimedia > Telephony services specifies a maximum value of 220 ms for > 'max-red', see [3GPP.26.114]. If AMR or AMR-WB are offered for inter= operability purpose, > see [draft-ietf-rtcweb-audio-codecs-for-interop], the max-red paramet= er must be included > in the offer and answer and set to an integer value multiple of 20ms. > > -----Message d'origine----- > De : rtcweb [mailto:rtcweb-bounces@ietf.org] De la part de Magnus=20 > Westerlund Envoy=E9 : mardi 5 avril 2016 23:02 =C0 : rtcweb@ietf.org;=20 > Justin Uberti Objet : [rtcweb] AMR and max-red in=20 > draft-ietf-rtcweb-fec > > Hi, > > As raised in the WG session there are where an open issue if there need t= o be any specification of the AMR/AMR-WB max-red parameter. > > So RFC4867 do have the following on offer/answer usage of the parameter: > > - The parameter "max-red" is a stream property parameter. For > send-only or send-recv unicast media streams, the parameter > declares the limitation on redundancy that the stream sender > will use. For recvonly streams, it indicates the desired value > for the stream sent to the receiver. The answerer MAY change > the value, but is RECOMMENDED to use the same limitation as the > offer declares. In the case of multicast, the offerer MAY > declare a limitation; this SHALL be answered using the same > value. A media sender using this payload format is RECOMMENDED > to always include the "max-red" parameter. This information is > likely to simplify the media stream handling in the receiver. > This is especially true if no redundancy will be used, in which > case "max-red" is set to 0. As this parameter was not defined > originally, some senders will not declare this parameter even > if it will limit or not send redundancy at all. > > Most notable is that media senders are RECOMMENDED to include it. Also no= te that it is the sender that indicates the limitation it intends to adhere= to for the streams using this RTP payload type. > > I also like to note that 3GPP in its specification for its Multimedia=20 > Telephony, has specified that one shall not use a value larger than=20 > 220 ms, and the value should be a multiple of 20 ms. Please see 3GPP=20 > TS > 26.114 version 13.3.0 > http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/26114-d30.zip > > So from my perspective I think a WebRTC endpoint simply should follow the= AMR RTP Payload specification when supported and include the parameter to = indicate the actual upper range of the redundancy it intended to use. It is= good to know about the limitation that 3GPP has defined as one likely reas= on to support AMR/AMR-WB is to be able to interoperate with 3GPP Services. > > Thus I would suggest that a small addition to the Section 4.3 text and co= rrections in the first sentence: > > OLD: > For AMR/AMR-WB, support for redundant encoding, and the maximum > supported depth, are controlled by the 'max-red' parameter, as > specified in [RFC4867], Section 8.1. > > NEW: > For AMR/AMR-WB, support for redundant encoding, and the maximum > used depth, is indicated by the 'max-red' parameter, as > specified in [RFC4867], Section 8.1 and 8.2. The 3GPP Multimedia > Telephony services specifies a maximum value of 220 ms for > 'max-red', see [3GPP.26.114]. > > > New Informational Reference: > > [3GPP.26.114] > > IP Multimedia Subsystem= =20 > (IMS); Multimedia telephony; Media handling and=20 > interaction3GPP< > date day=3D"17" month=3D"March" year=3D"2016"/> name=3D"3GPP TS" > value=3D"26.114 13.3.0"/> target=3D"http://www.3gpp.org/ftp/Specs/html-info/26114.htm"/> e> > > Opinions? > > 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 > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. = Les messages electroniques etant susceptibles d'alteration, Orange decline = toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --=20 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 ---------------------------------------------------------------------- ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Apr 20 09:03:24 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 25BB512E6D6 for ; Wed, 20 Apr 2016 09:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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, T_KAM_HTML_FONT_INVALID=0.01] 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 aQHtl_rth4w0 for ; Wed, 20 Apr 2016 09:03:22 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C582212DAE1 for ; Wed, 20 Apr 2016 09:03:22 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id k142so44815800oib.1 for ; Wed, 20 Apr 2016 09:03:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=tiAVY0X9c5O+CSWEkzMU93sd4TeEcJ2pWmEaLHLGJ+s=; b=pFvqK7SolVfrlqTJZT1najrEsWAwenGGLbcPMx9QPucXA15eIud0ElwJDxwf+QAM1K xDYzsuLoNgFcyzy6QyP0MFPA1yXP9arecYtkLKak8ySQTx329nRspm63FLPtzgHORXXb SUE2iXsJ5itVoE6DgFxwxEZz8KGqQNudxjNwqeI60las/AK62UNGOSIw2sKrUB7N4FAZ d03sselU+KS3E4gDslB6UChMaQYXYpRWxX66H2AV3OHckVvvvHgGQPNvSrCoodjfh2pS iU7RUIik+n9SI/CMMDIp0U1sYTdSIFuSEaLPiCtJ9LzZxpXGf5z554hRfG1Eaj1eOtMq b3BA== 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; bh=tiAVY0X9c5O+CSWEkzMU93sd4TeEcJ2pWmEaLHLGJ+s=; b=LYe3CssbKWl7O86OqPd+/GjLnzp+i5/+7YTTR8YCFLdK2CStW1lYUukjw4dYMbxm/O TMGfUFKoYSAl2+vjmUuor11/4gNacv1QqRd97HM8/jXg0B9L0Jgfc9ym3SpTx+65cJwF 4M//oGKbvWkVeiDCzi/l1J48ywlOm8+ZqwArgPYAHIbKhJoTVLr2T0j4UM8UkZ/ItH7i uEZrvphrHpalInd0aMlzRCHuMOu5V2LPy67BGJacKgkyiwWiK4xOYuEtj4CyEQxFQgNr 3QaKmp13DyW8p8aCTAZu2d+QT7H/ovgHSnOVHWBLnxX7vPo/qBMqE0bBKv1P7JqqrYOh vZTQ== X-Gm-Message-State: AOPr4FUqdQtD+j/ZLfXGdiAXJGtnOo/JtJTBDpHWRrqVs08jv1npTp3WV5Lkl95VJ8H/2bUpY6weq04QYxOV2g== X-Received: by 10.202.80.205 with SMTP id e196mr4183604oib.126.1461168202187; Wed, 20 Apr 2016 09:03:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.156 with HTTP; Wed, 20 Apr 2016 09:03:02 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Wed, 20 Apr 2016 09:03:02 -0700 Message-ID: To: "rtcweb@ietf.org" , Cullen Jennings , Sean Turner Content-Type: multipart/alternative; boundary=001a113d7a8ca60be80530ecbbfb Archived-At: Subject: Re: [rtcweb] Confirmation of DTMF issue 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, 20 Apr 2016 16:03:24 -0000 --001a113d7a8ca60be80530ecbbfb Content-Type: text/plain; charset=UTF-8 Having seen confirmation of this approach and no new issues, we will move forward with this language. Thanks to everyone working on the issue, Ted, Cullen, Sean On Wed, Apr 13, 2016 at 1:31 PM, Ted Hardie wrote: > With Martin's friendly amendments, the room at IETF 95 agreed to the > follow as the resolution of the DTMF discussion. The chairs would like > anyone who has new issues with this to let us know as soon as possible and > no later than Wednesday, April 20th, noon UTC, > > > "DTMF events generated by a WebRTC endpoint MUST have a duration of no > more than 8000 ms and no less than 40 ms. The recommended default duration > is 100 ms for each tone. The gap between events MUST be no less than 30 ms; > the recommended default gap duration is 70 ms. > > WebRTC endpoints are not required to do anything with RFC 4733 tones sent > to them, except gracefully drop them. There is currently no API to inform > JavaScript about the received DTMF or other RFC 4733 tones." > > regards, > > Ted, Cullen, and Sean > --001a113d7a8ca60be80530ecbbfb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Having seen confirmation of this approach and no= new issues, we will move forward with this language.
Thanks to everyone= working on the issue,

Ted, Cullen, Sean

On Wed, Apr 13= , 2016 at 1:31 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
With Martin'= ;s friendly amendments, the room at IETF 95 agreed to the follow as the res= olution of the DTMF discussion.=C2=A0 The chairs would like anyone who has = new issues with this to let us know as soon as possible and no later than W= ednesday, April 20th, noon UTC,


"DTMF events ge= nerated by a WebRTC endpoint MUST have a duration of no more than 8000 ms a= nd no less than 40 ms.=C2=A0 The recommended default duration is 100 ms for= each tone. The gap between events MUST be no less than 30 ms; =C2=A0the re= commended default gap duration is 70 ms.

WebRTC endpoints are not required to do anything with RFC 4733 t= ones sent to them, except gracefully drop them. There is currently no API t= o inform JavaScript about the received DTMF or other RFC 4733 tones."<= br>
regards,

<= span style=3D"font-family:arial,helvetica,sans-serif">Ted, Cullen, and Sean

--001a113d7a8ca60be80530ecbbfb-- From nobody Wed Apr 20 21:40:24 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 4AF8D12DA1F; Wed, 20 Apr 2016 21:40:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160421044021.903.32424.idtracker@ietfa.amsl.com> Date: Wed, 20 Apr 2016 21:40:21 -0700 Archived-At: Cc: draft-ietf-rtcweb-audio-codecs-for-interop@ietf.org, rtcweb@ietf.org, rtcweb-chairs@ietf.org Subject: [rtcweb] Spencer Dawkins' Yes on draft-ietf-rtcweb-audio-codecs-for-interop-05: (with COMMENT) 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, 21 Apr 2016 04:40:21 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-rtcweb-audio-codecs-for-interop-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio-codecs-for-interop/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I remember that the "but what about THIS audio codec?" discussions were pretty contentious for a while, and wanted to say that this document does a really good job of handling that question. Thanks for producing it. From nobody Thu Apr 21 08:31:30 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 14EF112EC3D; Thu, 21 Apr 2016 08:31:28 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160421153128.19586.68256.idtracker@ietfa.amsl.com> Date: Thu, 21 Apr 2016 08:31:28 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-11.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, 21 Apr 2016 15:31:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers of the IETF. Title : WebRTC Audio Codec and Processing Requirements Authors : Jean-Marc Valin Cary Bran Filename : draft-ietf-rtcweb-audio-11.txt Pages : 7 Date : 2016-04-21 Abstract: This document outlines the audio codec and processing requirements for WebRTC endpoints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-audio-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-audio-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 22 03:26:06 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 5628A12D6EA; Fri, 22 Apr 2016 03:26:05 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160422102605.7731.18039.idtracker@ietfa.amsl.com> Date: Fri, 22 Apr 2016 03:26:05 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-codecs-for-interop-06.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, 22 Apr 2016 10:26:05 -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 : Additional WebRTC audio codecs for interoperability. Author : Stephane Proust Filename : draft-ietf-rtcweb-audio-codecs-for-interop-06.txt Pages : 12 Date : 2016-04-22 Abstract: To ensure a baseline level of interoperability between WebRTC endpoints, a minimum set of required codecs is specified. However, to maximize the possibility to establish the session without the need for audio transcoding, it is also recommended to include in the offer other suitable audio codecs that are available to the browser. This document provides some guidelines on the suitable codecs to be considered for WebRTC endpoints to address the most relevant interoperability use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio-codecs-for-interop/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-audio-codecs-for-interop-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-audio-codecs-for-interop-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 25 02:23:56 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 D75E912D535 for ; Mon, 25 Apr 2016 02:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-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 ffycjOknzy_j for ; Mon, 25 Apr 2016 02:23:53 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA60B12D527 for ; Mon, 25 Apr 2016 02:23:51 -0700 (PDT) Received: from [172.20.10.2] (2.150.17.227.tmi.telenormobil.no [2.150.17.227]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id u3P9NfbM005517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 25 Apr 2016 11:23:49 +0200 To: rtcweb@ietf.org From: Philipp Hancke Message-ID: <571DE213.8080306@goodadvice.pages.de> Date: Mon, 25 Apr 2016 11:23:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [rtcweb] which bandwidth modifiers need to be supported? 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, 25 Apr 2016 09:23:55 -0000 which bandwidth modifiers for b= lines does a client need to support? Chrome currently supports b=AS, however the implementation is closer to TIAS semantically. Firefox does not implement either currently. http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-maxBitrate uses TIAS as a definition. For parsing, supporting both is fine (for a while at least). For serialization I would prefer picking one (TIAS) to having to track which variant a peer supports. From nobody Mon Apr 25 10:05:21 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 6546112D552; Mon, 25 Apr 2016 10:05:19 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160425170519.28258.64025.idtracker@ietfa.amsl.com> Date: Mon, 25 Apr 2016 10:05:19 -0700 Archived-At: Cc: rtcweb-chairs@ietf.org, draft-ietf-rtcweb-audio@ietf.org, rtcweb@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [rtcweb] Protocol Action: 'WebRTC Audio Codec and Processing Requirements' to Proposed Standard (draft-ietf-rtcweb-audio-11.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, 25 Apr 2016 17:05:19 -0000 The IESG has approved the following document: - 'WebRTC Audio Codec and Processing Requirements' (draft-ietf-rtcweb-audio-11.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-audio/ Technical Summary This document outlines the audio codec and processing requirements for WebRTC client application and endpoint devices. Working Group Summary Some members of the WG wished to add additional MTI codecs. Rational for those are provided in draft-ietf-rtcweb-audio-codecs-for-interop which is referenced by this spec. Document Quality There are several implementations including FireFox and Chrome. Personnel Who is the Document Shepherd? Cullen Jennings Who is the Responsible Area Director? Alissa Cooper From nobody Mon Apr 25 10:06:27 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 8ADD812B018; Mon, 25 Apr 2016 10:06:26 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160425170626.28215.83117.idtracker@ietfa.amsl.com> Date: Mon, 25 Apr 2016 10:06:26 -0700 Archived-At: Cc: draft-ietf-rtcweb-audio-codecs-for-interop@ietf.org, rtcweb-chairs@ietf.org, rtcweb@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [rtcweb] Document Action: 'Additional WebRTC audio codecs for interoperability.' to Informational RFC (draft-ietf-rtcweb-audio-codecs-for-interop-06.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, 25 Apr 2016 17:06:26 -0000 The IESG has approved the following document: - 'Additional WebRTC audio codecs for interoperability.' (draft-ietf-rtcweb-audio-codecs-for-interop-06.txt) as Informational RFC 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-audio-codecs-for-interop/ Technical Summary The document explains some additional audio codecs that WebRTC devices and browsers may wish to support and some of reasons that an implementation might choose to use that codec. It does not specify any mandatory to implement codecs for WebRTC. Working Group Summary Some people in the WG would like these codecs to be mandatory to implement for WebRTC browsers. Document Quality There are WebRTC devices (but not browsers) that implement theses codecs. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Shepherd is Cullen Jennings. AD is Alissa Cooper. From nobody Tue Apr 26 01:11:15 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 5D82912D0E3 for ; Tue, 26 Apr 2016 01:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 a91Ds41M4Bnc for ; Tue, 26 Apr 2016 01:11:12 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6067C12D0D3 for ; Tue, 26 Apr 2016 01:11:12 -0700 (PDT) Received: from [192.168.10.131] (ip84-247-137-40.breiband.no [84.247.137.40]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id u3Q8BBIf023633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 26 Apr 2016 10:11:13 +0200 To: rtcweb@ietf.org References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> From: Philipp Hancke Message-ID: <571F229C.6090303@goodadvice.pages.de> Date: Tue, 26 Apr 2016 10:11:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.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, 26 Apr 2016 08:11:14 -0000 Am 20.03.2016 um 23:31 schrieb internet-drafts@ietf.org: > > 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 Recommendations > Authors : Justin Uberti > Guo-wei Shieh > Filename : draft-ietf-rtcweb-ip-handling-01.txt > Pages : 8 > Date : 2016-03-20 I stumbled upon a (now deleted) stackoverflow posting yesterday in which obfuscated code "used webrtc" to hack the users router. Basically webrtc was used to get the local ip address from which the routers ip is inferred. Then a default admin account is tried. It turns out the idea is not knew, I heard from some former coworkers that they used this in penetration testing before. But it has now reached stackoverflow which means there will soon be rumors and all kinds of "webrtc allows hacking your router" stories. The principal problem here is default passwords. WebRTC makes it slightly easier by removing the need to run a series of http requests to find out the routers ip. Should this be mentioned as an example in #1 of the problem statement? From nobody Thu Apr 28 09:01:13 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 9651F12DA19; Thu, 28 Apr 2016 09:01:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160428160109.27729.26050.idtracker@ietfa.amsl.com> Date: Thu, 28 Apr 2016 09:01:09 -0700 Archived-At: Cc: draft-ietf-rtcweb-alpn@ietf.org, turners@ieca.com, rtcweb@ietf.org, rtcweb-chairs@ietf.org Subject: [rtcweb] Alexey Melnikov's No Objection on draft-ietf-rtcweb-alpn-03: (with COMMENT) 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, 28 Apr 2016 16:01:09 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-rtcweb-alpn-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-alpn/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please excuse my ignorance (pointers would be appreciated, if this is explained elsewhere): do RTP intermediary need to be updated to understand this spec? If yes, how can you enforce requirements on "c-webrtc"? From nobody Thu Apr 28 16:51:24 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 A0A6512B041; Thu, 28 Apr 2016 16:51:22 -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 x5tXYJiQWXui; Thu, 28 Apr 2016 16:51:21 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::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 D355212B071; Thu, 28 Apr 2016 16:51:20 -0700 (PDT) Received: by mail-ig0-x231.google.com with SMTP id u10so7508861igr.1; Thu, 28 Apr 2016 16:51:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ubf4HUXyJ/yve9PWJTvYCILAdAVmhWtDdpnoHTw8PYs=; b=XgA8fhXkRZ3v1zTiQOlfieZ9RwCGWqjtVaSrbL5tQ7S9cd9+/qsr7qTFV57TQycsPH OARU9Ssa9wDRvwqtb05AcS5y2ncR6k4PELY4NBRf8jP1lo9IIdCPMU2z2mMRRz4kClUp uChrC/+n8dYHiev7o8hKDoYixqgSj6Fhtw3hOfyZESGpoMVakI04yZotgGTe+t6Napga i1wnX0gQdcO43KF9rMrOsK5drl5O0l6Nha+10AZfghEg7bZ1BbSzhD0rn99982kQxJh/ YQonrxpuH++28e27T4Gg0vleIxXUcx7Q7ldVhuFMwqUse+u7303QUU9OQSCMyDQ7H3Eu 6YUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ubf4HUXyJ/yve9PWJTvYCILAdAVmhWtDdpnoHTw8PYs=; b=F3dwq287tpoYUPKQ1Yb1TLWg9IAaowtvKo0gX28bVdt+JeVWSECTE1FaJRx1ucr2+e uUc48AP8LsG4mERJLLxgnu43LYCq0KumnotF1Lm4jwu/6WFz5fOHW5b6WZHVCoeC1WaD 44us+nezHFB8egBcaaGzjeHVtdicAhn3/w3M4Efzd+ViEkvU70IU8BlDVunPCgfbIIgO e4+yNnfStt1aLRN+49YT7avm3GA5mi7axuT6a84AOmw31RnXrx71dZDTytizWfap1O5q aqx4tQdXDuV1EaxyZK2kusudijtPtkRQFrQ2IX4L7bcYISs9vrC5s8h5fgNEFJe2G3M0 C8fg== X-Gm-Message-State: AOPr4FVeHKQqwF6RLk0xAOmAm+gYH6iq0juloXBP6NRCTdcW1kRiZwfkLH33iW1rAiPgESsR1fBDiV1AnQv7xg== MIME-Version: 1.0 X-Received: by 10.50.101.169 with SMTP id fh9mr772657igb.58.1461887480247; Thu, 28 Apr 2016 16:51:20 -0700 (PDT) Received: by 10.36.43.82 with HTTP; Thu, 28 Apr 2016 16:51:20 -0700 (PDT) In-Reply-To: <20160428160109.27729.26050.idtracker@ietfa.amsl.com> References: <20160428160109.27729.26050.idtracker@ietfa.amsl.com> Date: Fri, 29 Apr 2016 09:51:20 +1000 Message-ID: From: Martin Thomson To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-rtcweb-alpn@ietf.org, Sean Turner , "rtcweb@ietf.org" , The IESG , rtcweb-chairs@ietf.org Subject: Re: [rtcweb] Alexey Melnikov's No Objection on draft-ietf-rtcweb-alpn-03: (with COMMENT) 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, 28 Apr 2016 23:51:22 -0000 On 29 April 2016 at 02:01, Alexey Melnikov wrote: > Please excuse my ignorance (pointers would be appreciated, if this is > explained elsewhere): do RTP intermediary need to be updated to > understand this spec? No. Mostly. RTP intermediaries can choose to implement this spec as an endpoint, but there is typically no benefit from doing so. RTP intermediaries don't usually have a strong distinction between "the thing that does (S)RTP" and "the thing that controls signaling" and so don't gain much by isolating media from the latter. From nobody Fri Apr 29 02:30:18 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 2688112D09B for ; Fri, 29 Apr 2016 02:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=Jy5BeW1W; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=beqG+u68 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 Oe6FBHvN6458 for ; Fri, 29 Apr 2016 02:30:12 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEAFD12D768 for ; Fri, 29 Apr 2016 02:30:09 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 58D1621A2D for ; Fri, 29 Apr 2016 05:30:09 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute2.internal (MEProxy); Fri, 29 Apr 2016 05:30:09 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=qtBJt7PCgRuO4KsHo1ZERBBP9P4=; b=Jy5BeW 1WeIPi32iqVt6vfdRdD5kTEHNjQL8yFqa+7NjbcSeoI25KX1RWlmrqJelLAf1II2 gh8dZSDSV0urvvbXgeSEtZhiEnUO+2aL7icyi2HrL4dSIO81TvCrPcOrF/73Nftd pot7mgNYeKFIJ3eNjMMmLSVUjpEp2p2/sfn10= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=qtBJt7PCgRuO4Ks Ho1ZERBBP9P4=; b=beqG+u685sNyNcCzlHmnlbwcjHa9bNNvIAaXePA3zOAZi2Y 1Rp5eHyMQhBa/5NNb6K3ybrzgAbx0pLJJOTAg8d9n5jqBQrt9sTNBxZd6lKFIB0q rVt38FASgbu0/0RtgOnmCQZdJ+wLTlRZPmX1BtRxNvY3sowoSrQh/EPEWRU0= Received: by web5.nyi.internal (Postfix, from userid 99) id 25E92A782CB; Fri, 29 Apr 2016 05:30:09 -0400 (EDT) Message-Id: <1461922209.247721.593209417.4B4A0912@webmail.messagingengine.com> X-Sasl-Enc: EWoxEUZdFUalrQ6XDEWa7x/y5UkkIlAU1j1VK3OmldaA 1461922209 From: Alexey Melnikov To: Martin Thomson MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-491eb5a4 Date: Fri, 29 Apr 2016 10:30:09 +0100 In-Reply-To: References: <20160428160109.27729.26050.idtracker@ietfa.amsl.com> Archived-At: Cc: draft-ietf-rtcweb-alpn@ietf.org, Sean Turner , rtcweb@ietf.org, The IESG , rtcweb-chairs@ietf.org Subject: Re: [rtcweb] Alexey Melnikov's No Objection on draft-ietf-rtcweb-alpn-03: (with COMMENT) 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, 29 Apr 2016 09:30:13 -0000 On Fri, Apr 29, 2016, at 12:51 AM, Martin Thomson wrote: > On 29 April 2016 at 02:01, Alexey Melnikov > wrote: > > Please excuse my ignorance (pointers would be appreciated, if this is > > explained elsewhere): do RTP intermediary need to be updated to > > understand this spec? > > No. Mostly. RTP intermediaries can choose to implement this spec as > an endpoint, but there is typically no benefit from doing so. RTP > intermediaries don't usually have a strong distinction between "the > thing that does (S)RTP" and "the thing that controls signaling" and so > don't gain much by isolating media from the latter. Section 3 says: RTP middleboxes and entities that forward media or data cannot promise to maintain confidentiality. Any entity that forwards content, or records content for later access by entities other than the authenticated peer, MUST NOT offer or accept a session with the "c-webrtc" identifier. So, my questions are: 1) Do RTP middleboxes frequently forward content, or records content for later access by entities other than the authenticated peer? 2) If the answer to 1) is "yes", why would RTP middlebox software developers bother to update software to comply with this specification? Please help me understand, if I misunderstood the text. From nobody Fri Apr 29 03:06: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 83B4912D0C0; Fri, 29 Apr 2016 03:06:06 -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 Pts6THuCed4O; Fri, 29 Apr 2016 03:06:04 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::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 4D20412D09B; Fri, 29 Apr 2016 03:06:04 -0700 (PDT) Received: by mail-ig0-x229.google.com with SMTP id bi2so17634834igb.0; Fri, 29 Apr 2016 03:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ow5qHgmM7rN7eYECPfwtgPMHGirybJqFv+fsuCG9PHA=; b=s0OIPZ3JqlStiXb9hG/djh+8S42z3jfpslbKLckdB5PBxCGwKQmeEkLg7U9VeUgqTb sI71u0ozpVafGQGSWrhLTYl/gGJG02AQ2y1BbGNHs3/yw9o7sm6gAfcn0LUau9GYi8/X fLcM8e5vHO8nDjJAJFtLOf/bsnhdEH2O13Tr1IXwRdWm46UL77YVJOmk7JdKkW4Bs8ua S0NPDsDXnAmYNdpoWaP8xeEHPt6jVCflZy+ANWlqILV6APNbrlZQDzadjbpnt79GeiaN l0tzAiOAYYNmYoynSiKqrI/swQwPeQXEqoD8mddxcFVpBev63EZTEHzkyh5B40J3eLXd xUlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ow5qHgmM7rN7eYECPfwtgPMHGirybJqFv+fsuCG9PHA=; b=nBcg1aPgZrzPSGlqmXXO33vVadV5ns0p9gJOAEnFaISIFOcoLD4cY/dIOSDQTRgs/m VuBtoNPAIGVcn6K7fmRqoXAIV6/AYAVuJTThUCBWrmjFAymL3NgbWl60lVqDp4n9241J iG9UDYpssiSNWE1BciAZY0S7SuDY/dClLbHWbqjV14VFzPt/MHUZcEUwtPWK/N1/R2dd jafSlWzJg8Pacm8GoUangdlUp4ivFMXWJqBzpmRgFTom7FC/GkQhXnTBxzp9euzarW8l My7JzBGIOd6KoTA0Wa3vPqS763gYns1Ok9UFgfsv59r0rxOnLckKbhLx4wqHqfFBuS80 JyTA== X-Gm-Message-State: AOPr4FUnWPxjJHOho8rUYuOiIoiPiMwu+mY7mKbyjNIg6N8LE0gohRf2AfhXcofmIjKWgSMIS9A8OCUdU8t6mA== MIME-Version: 1.0 X-Received: by 10.50.101.169 with SMTP id fh9mr3460489igb.58.1461924363582; Fri, 29 Apr 2016 03:06:03 -0700 (PDT) Received: by 10.36.43.82 with HTTP; Fri, 29 Apr 2016 03:06:03 -0700 (PDT) In-Reply-To: <1461922209.247721.593209417.4B4A0912@webmail.messagingengine.com> References: <20160428160109.27729.26050.idtracker@ietfa.amsl.com> <1461922209.247721.593209417.4B4A0912@webmail.messagingengine.com> Date: Fri, 29 Apr 2016 20:06:03 +1000 Message-ID: From: Martin Thomson To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-rtcweb-alpn@ietf.org, Sean Turner , "rtcweb@ietf.org" , The IESG , rtcweb-chairs@ietf.org Subject: Re: [rtcweb] Alexey Melnikov's No Objection on draft-ietf-rtcweb-alpn-03: (with COMMENT) 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, 29 Apr 2016 10:06:06 -0000 On 29 April 2016 at 19:30, Alexey Melnikov wrote: > 1) Do RTP middleboxes frequently forward content, or records content for > later access by entities other than > the authenticated peer? > 2) If the answer to 1) is "yes", why would RTP middlebox software > developers bother to update software to comply with this specification? (I should really read my own doc before answering.) Yes, middleboxes do this all the time. However, they don't need to update their software. Endpoints that implement this spec will assume that the absence of ALPN means that there is no confidentiality. And I realize now that I never actually said that. That was extremely remiss of me... https://github.com/martinthomson/drafts/commit/21b84074a671bd From nobody Fri Apr 29 07:57: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 D0FCA12D0B8 for ; Fri, 29 Apr 2016 07:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.517 X-Spam-Level: X-Spam-Status: No, score=-115.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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.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 vhsxfC_HuSDL for ; Fri, 29 Apr 2016 07:57:27 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1391812D16A for ; Fri, 29 Apr 2016 07:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2596; q=dns/txt; s=iport; t=1461941846; x=1463151446; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3+yblBe1leyCPD8JZW6qDZ6sbZBCEG60XWqZasFEjK0=; b=MEKnB1qD6d+4kXshu+qBcBd1RkHfbT+RyrnOubdRWpP+rFhrq4HQQA6/ EgnLPGFx6+pKQBAJZFurHGljEomwiAMo/ukG1tNLkrCLqgTuKRd9ba8Xj O5SFWrwG2xKQprPkmWjZ05CSM4Vsv8aoBLXy6I93/Zbwk0K/0A1ntxdxv Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQATdiNX/5BdJa1dgzhTfQa5awENg?= =?us-ascii?q?XYXC4UkSgKBKjgUAQEBAQEBAWUnhEEBAQEDAQEBAWsLBQsCAQgYLicLJQIEDgW?= =?us-ascii?q?IIggOxC0BAQEBAQEBAQEBAQEBAQEBAQEBAQERBIgXCIJOhD2DK4IrBZgTAYV7i?= =?us-ascii?q?BuBZ4d2hTSPLwEeAQFCg2tsiAJ/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,552,1454976000"; d="scan'208";a="265896777" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Apr 2016 14:57:10 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u3TEvAmG015646 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Apr 2016 14:57:10 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 29 Apr 2016 10:57:10 -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.1104.009; Fri, 29 Apr 2016 10:57:10 -0400 From: "Cullen Jennings (fluffy)" To: Harald Tveit Alvestrand Thread-Topic: [rtcweb] Clarification in draft-ietf-rtcweb-transports-11 Thread-Index: AQHRoidnJpCOBA6OL0yIUrnna1wLIQ== Date: Fri, 29 Apr 2016 14:57:10 +0000 Message-ID: <06096FC8-AD0F-4C9F-9334-A95F981A7EB5@cisco.com> References: <56B847E2.8060109@alvestrand.no> In-Reply-To: <56B847E2.8060109@alvestrand.no> 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.20.249.165] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [rtcweb] Clarification in draft-ietf-rtcweb-transports-11 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, 29 Apr 2016 14:57:33 -0000 Github says this was fixed in version -10 - See https://github.com/rtcweb-w= g/rtcweb-transport/issues/12 But it does not seem to be in the -10 draft or latest draft so I'm wonderin= g if it got lost along the way somewhere.=20 > On Feb 8, 2016, at 12:46 AM, Harald Alvestrand wro= te: >=20 > This seems reasonable. >=20 > Filed https://github.com/rtcweb-wg/rtcweb-transport/issues/12 so as to no= t forget. >=20 >>=20 >>=20 >> On Wed, Feb 3, 2016 at 7:16 AM, Cullen Jennings wrote: >> I think we need to make the ALPN a bit more explicit. We agreed to inclu= de the ALPN header so that a proxy knows it might receive video packet rate= s tunnelled across it. However the text on this is not 100% clear. Right no= w it says >>=20 >> If it does so, it MUST support the "ALPN" header as >> specified in [RFC7639], >>=20 >> But some people have posted out including this header is optional in 763= 9 so there might be some ubiquity here about what is meant. I think we shou= ld change the word =93support=94 to =93include=94 to make it clear this nee= ds to be sent to the proxy so that it would read >>=20 >> If it does so, it MUST include the "ALPN" header as >> specified in [RFC7639], >>=20 >> I believe that correctly reflects what we intended on this. There is no = requirement for the proxy to understand or do anything with this header. Ol= d proxies will just ignore it and cary on as if it was not there. >>=20 >> I wouldn't have a problem with this if it were restricted to browsers. H= owever, >> we don't want to careful about retroactively branding endpoints which ar= en't >> browsers but can talk to WebRTC clients as noncompliant. Maybe this >> is like codecs where they are "WebRTC Compatible"? >>=20 >> -Ekr >>=20 >> Cullen >>=20 >> (with my individual contributor hat on) >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >>=20 >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 > --=20 > Surveillance is pervasive. Go Dark. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Apr 29 08:17: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 4722C12B062 for ; Fri, 29 Apr 2016 08:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.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 5T6zExuyZCWM for ; Fri, 29 Apr 2016 08:17:11 -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 3C6E412D0AA for ; Fri, 29 Apr 2016 08:17:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5BF047C7F36; Fri, 29 Apr 2016 17:17:09 +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 6PXDlVJzuwqx; Fri, 29 Apr 2016 17:17:07 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:9cb2:7a2a:8f4:70fa] (unknown [IPv6:2001:470:de0a:1:9cb2:7a2a:8f4:70fa]) by mork.alvestrand.no (Postfix) with ESMTPSA id C2BFC7C7F35; Fri, 29 Apr 2016 17:17:07 +0200 (CEST) To: "Cullen Jennings (fluffy)" References: <56B847E2.8060109@alvestrand.no> <06096FC8-AD0F-4C9F-9334-A95F981A7EB5@cisco.com> From: Harald Alvestrand Message-ID: <57237AF3.8050800@alvestrand.no> Date: Fri, 29 Apr 2016 17:17:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <06096FC8-AD0F-4C9F-9334-A95F981A7EB5@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "" Subject: Re: [rtcweb] Clarification in draft-ietf-rtcweb-transports-11 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, 29 Apr 2016 15:17:14 -0000 Den 29. april 2016 16:57, skrev Cullen Jennings (fluffy): > > Github says this was fixed in version -10 - See https://github.com/rtcweb-wg/rtcweb-transport/issues/12 > > But it does not seem to be in the -10 draft or latest draft so I'm wondering if it got lost along the way somewhere. You're right. I reopened the issue. > > > >> On Feb 8, 2016, at 12:46 AM, Harald Alvestrand wrote: >> >> This seems reasonable. >> >> Filed https://github.com/rtcweb-wg/rtcweb-transport/issues/12 so as to not forget. >> >>> >>> >>> On Wed, Feb 3, 2016 at 7:16 AM, Cullen Jennings wrote: >>> I think we need to make the ALPN a bit more explicit. We agreed to include the ALPN header so that a proxy knows it might receive video packet rates tunnelled across it. However the text on this is not 100% clear. Right now it says >>> >>> If it does so, it MUST support the "ALPN" header as >>> specified in [RFC7639], >>> >>> But some people have posted out including this header is optional in 7639 so there might be some ubiquity here about what is meant. I think we should change the word “support” to “include” to make it clear this needs to be sent to the proxy so that it would read >>> >>> If it does so, it MUST include the "ALPN" header as >>> specified in [RFC7639], >>> >>> I believe that correctly reflects what we intended on this. There is no requirement for the proxy to understand or do anything with this header. Old proxies will just ignore it and cary on as if it was not there. >>> >>> I wouldn't have a problem with this if it were restricted to browsers. However, >>> we don't want to careful about retroactively branding endpoints which aren't >>> browsers but can talk to WebRTC clients as noncompliant. Maybe this >>> is like codecs where they are "WebRTC Compatible"? >>> >>> -Ekr >>> >>> Cullen >>> >>> (with my individual contributor hat on) >>> >>> >>> _______________________________________________ >>> 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 >> >> >> -- >> Surveillance is pervasive. Go Dark. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >