From nobody Mon May 2 13:58:59 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDFF12D18F for ; Mon, 2 May 2016 13:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 pxjM6LZjrfR8 for ; Mon, 2 May 2016 13:58:56 -0700 (PDT) Received: from bongo.tulip.relay.mailchannels.net (bongo.tulip.relay.mailchannels.net [23.83.218.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 402A012D518 for ; Mon, 2 May 2016 13:58:54 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id AB87B20482 for ; Mon, 2 May 2016 20:58:50 +0000 (UTC) Received: from r2-chicago.webserversystems.com (ip-10-229-11-165.us-west-2.compute.internal [10.229.11.165]) by relay.mailchannels.net (Postfix) with ESMTPA id 0CCF820432 for ; Mon, 2 May 2016 20:58:49 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.120.5.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.6.11); Mon, 02 May 2016 20:58:50 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1462222730227:807540602 X-MC-Ingress-Time: 1462222730227 Received: from pool-71-162-135-19.phlapa.fios.verizon.net ([71.162.135.19]:60287 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from ) id 1axKvZ-000CSV-0j for rtcweb@ietf.org; Mon, 02 May 2016 15:58:49 -0500 References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <571F229C.6090303@goodadvice.pages.de> To: rtcweb@ietf.org From: Randell Jesup Message-ID: Date: Mon, 2 May 2016 16:59:42 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <571F229C.6090303@goodadvice.pages.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AuthUser: randell@jesup.org 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: Mon, 02 May 2016 20:58:58 -0000 On 4/26/2016 4:11 AM, Philipp Hancke wrote: > 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. Definitely not new, nor (as you state) requiring webrtc in any manner. > 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? My only concern is not wanting to publish a blueprint for attacks (even if known to some). Perhaps irrelevant. -- Randell Jesup -- rjesup a t mozilla d o t com Please please please don't email randell-ietf@jesup.org! Way too much spam From nobody Tue May 3 19:40:46 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 96D5912D173; Tue, 3 May 2016 19:40:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504024043.8242.33067.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 19:40:43 -0700 Archived-At: Cc: draft-ietf-rtcweb-alpn@ietf.org, turners@ieca.com, rtcweb@ietf.org, rtcweb-chairs@ietf.org Subject: [rtcweb] Ben Campbell's Yes 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: Wed, 04 May 2016 02:40:43 -0000 Ben Campbell has entered the following ballot position for draft-ietf-rtcweb-alpn-03: 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-alpn/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Should I-D.ietf-rtcweb-security-arch be a normative reference, due to the citation in section 4? From nobody Tue May 3 20:23:42 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 4EA4712D85D; Tue, 3 May 2016 20:23:35 -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 GPq27dew8guk; Tue, 3 May 2016 20:23:33 -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 25B8512D74B; Tue, 3 May 2016 20:23:33 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id u185so48414235iod.3; Tue, 03 May 2016 20:23:33 -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=WimKkK65ZD3cvGB9ghSCJgUaSv/byEmE+zjv85cJibQ=; b=hbTSr7fx4ZW4HfygvVFgE8cEFq5i7+W6YvpdREt9AIteVRS0/OzmFZcprf++aPqMaU UVRm/8Va2z+WF3x/btnnbwbEFU8Edxd3rANZRxygBCB2d5qFhUvrjDhGizNqPCmuOP94 HSb4y08dSAISFx4blIIWdg78EWaOtk3ToF6N8/mPvfx4HP9dhs7aQosd9hDAT87KrO6z ri9octtHcuadq45FpikH86uKnSN4DXc2tR4xyHbKv2UpSgRqd0fnYsUW1dDpMN6sAHZi 5orFIO/WqVQLbVit7shXvm4kMDcvdtEZpcvYdSTP1H9N3mcTWsFvcY07Tugs1YDY6/ik OGGQ== 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=WimKkK65ZD3cvGB9ghSCJgUaSv/byEmE+zjv85cJibQ=; b=kydYi3e4PIWGwdJhch7iukZpFI11OqQgJnU1twDyQ/AyEgZMBH/8bzy8NDBqpFQ2Ny 4e61DCIYFJkWqZUL+BLK4G70q6dAv81R95mewFZ4m9SI5hp46LOfpmFgCISWbUS9tZZX e/YeYacsnxTwHWuiowUIu/bRwW8iYYj0MmcnmrN8KPPafMSUoZwovH4Zd4rjZzyQacmG 3Fe767tLtPRuq5I18iSzM9UMQ+8av/IFmUGb7jsrDvS47+Er+iUyLbV4VW0eRBFXkkug TajVmEjNr4Wv4x3pLzJ7VUoFaRJ3W6lR/Tfsm5/4cOt9coJ3KxVciBdoRWJR97iWhhtL zRkg== X-Gm-Message-State: AOPr4FUprwaNL4ZE+Vx6dKIoO58O5CD+1pHmQN4KHgvAWbr/ZuxrpYXVSudtfWnqKohdocy9BzqJVzlvTY9VHw== MIME-Version: 1.0 X-Received: by 10.107.59.85 with SMTP id i82mr7079810ioa.108.1462332212531; Tue, 03 May 2016 20:23:32 -0700 (PDT) Received: by 10.36.43.82 with HTTP; Tue, 3 May 2016 20:23:32 -0700 (PDT) In-Reply-To: <20160504024043.8242.33067.idtracker@ietfa.amsl.com> References: <20160504024043.8242.33067.idtracker@ietfa.amsl.com> Date: Wed, 4 May 2016 13:23:32 +1000 Message-ID: From: Martin Thomson To: Ben Campbell 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] Ben Campbell's Yes 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: Wed, 04 May 2016 03:23:35 -0000 On 4 May 2016 at 12:40, Ben Campbell wrote: > Should I-D.ietf-rtcweb-security-arch be a normative reference, due to the > citation in section 4? That was intended largely as a "such as", would be clearer if it were changed to: Peer authentication, such as that provided by Section X of [I-D.ietf...arch], ... From nobody Tue May 3 20:28: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 77BD812D7BA; Tue, 3 May 2016 20:28:51 -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 hGkHCZcCqF6P; Tue, 3 May 2016 20:28:50 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FE4912B05E; Tue, 3 May 2016 20:28:50 -0700 (PDT) Received: from [10.0.1.18] (cpe-70-119-246-39.tx.res.rr.com [70.119.246.39]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u443SabS017983 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 3 May 2016 22:28:37 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-246-39.tx.res.rr.com [70.119.246.39] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Martin Thomson" Date: Tue, 03 May 2016 22:28:36 -0500 Message-ID: In-Reply-To: References: <20160504024043.8242.33067.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: draft-ietf-rtcweb-alpn@ietf.org, Sean Turner , "rtcweb@ietf.org" , The IESG , rtcweb-chairs@ietf.org Subject: Re: [rtcweb] Ben Campbell's Yes 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: Wed, 04 May 2016 03:28:51 -0000 On 3 May 2016, at 22:23, Martin Thomson wrote: > On 4 May 2016 at 12:40, Ben Campbell wrote: >> Should I-D.ietf-rtcweb-security-arch be a normative reference, due to >> the >> citation in section 4? > > That was intended largely as a "such as", would be clearer if it were > changed to: Peer authentication, such as that provided by Section X of > [I-D.ietf...arch], ... Possibly--but do you expect this to be a situation where a webrtc peer can pick from any number of available peer authentication mechanisms in addition to what is in security-arch, or is this pretty much it? From nobody Tue May 3 20:42: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 D5EA912D7AD; Tue, 3 May 2016 20:42:47 -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 fCyqBZtFDyFD; Tue, 3 May 2016 20:42:39 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001: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 20C5412B02F; Tue, 3 May 2016 20:42:39 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id d62so42486826iof.2; Tue, 03 May 2016 20:42:39 -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=G1m7tmXw6dwbuSZdHOTEEXIRp4Fl7iOHdup5GbwwyEE=; b=YsAui7eE8YCXe6KsmBl7tKTWoI5Dquak9ly1YggeprO4G7ETKWzI/FwWJJRQIk63ga u3fz7BiKrtQ1r4pY3YZS81to0TJmLpiiVRJQVUz7x1bXLX773Pt4axojgXcjwqQ3qLP2 mF090VlRannu3F74h2f7arm1neccA/gnYRsiNt+xkHd2FRLnWqadf50RYWvfx5ZDOVfK +lcbhS2mhFhKEA97CnVG/T/g7/vJoDgwFp/+cETe/EGSR/p6+Yof7z1lm6K7+G5vJLQP Y1fXxYJmLnzJJJ94CTcUXvUCme/ZcVdKMhlEmT+Tr2/bumaG8LOtFNiYQs8nqOwnVnla ZWnA== 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=G1m7tmXw6dwbuSZdHOTEEXIRp4Fl7iOHdup5GbwwyEE=; b=l4NXchWeVcZa0ccsgd1wZOI/J59W5djr3rOcLuLs3mk0RlrnK2IiO1nTN1N61A/koA 6rLzITAZisR3zPf5j4oncZ5qh5BNfwBYhEgmokgB43heqLTvD3bukayZG64/VCGUUHx4 iDw7KBjdX1GxtNixTic9n8aPPkjCNeqgySnY/FR0b678Kjd++01aEPtYoduMSlQJNaql xRm65PoX7C3NAee2eHP07wGjRdH0QsaCc4F4q4/f6KA79fz2Oh4t3xzEprLTwalFvgZl RCGh2BTTKZM5ErFgAiVJlz/Vh1cEQ7RaFhragLGf1yBUrQHjjYx2Q0b7cQ3xCPGYKwyT D2og== X-Gm-Message-State: AOPr4FWQY/GWTUDZ8NLv7c8vdttoX1n6FOVn4kp2Rvpw/JWBcFyFBb19Z4QUfkTh4cCC6Q+7yMGzCjXMrXykeQ== MIME-Version: 1.0 X-Received: by 10.107.136.76 with SMTP id k73mr7997902iod.100.1462333358320; Tue, 03 May 2016 20:42:38 -0700 (PDT) Received: by 10.36.43.82 with HTTP; Tue, 3 May 2016 20:42:38 -0700 (PDT) In-Reply-To: References: <20160504024043.8242.33067.idtracker@ietfa.amsl.com> Date: Wed, 4 May 2016 13:42:38 +1000 Message-ID: From: Martin Thomson To: Ben Campbell 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] Ben Campbell's Yes 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: Wed, 04 May 2016 03:42:48 -0000 On 4 May 2016 at 13:28, Ben Campbell wrote: > On 3 May 2016, at 22:23, Martin Thomson wrote: > >> On 4 May 2016 at 12:40, Ben Campbell wrote: >>> >>> Should I-D.ietf-rtcweb-security-arch be a normative reference, due to the >>> citation in section 4? >> >> >> That was intended largely as a "such as", would be clearer if it were >> changed to: Peer authentication, such as that provided by Section X of >> [I-D.ietf...arch], ... > > > Possibly--but do you expect this to be a situation where a webrtc peer can > pick from any number of available peer authentication mechanisms in addition > to what is in security-arch, or is this pretty much it? That's the right question. It's the latter, so let's just elevate this to normative. It might be that this blocks publication, but think that the world can do without another RFC for a little longer. From nobody Wed May 4 00:32: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 6091712B00C; Wed, 4 May 2016 00:32:06 -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: <20160504073206.8206.5033.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 00:32:06 -0700 Archived-At: Cc: draft-ietf-rtcweb-alpn@ietf.org, turners@ieca.com, rtcweb@ietf.org, rtcweb-chairs@ietf.org Subject: [rtcweb] Stephen Farrell'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: Wed, 04 May 2016 07:32:06 -0000 Stephen Farrell 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: ---------------------------------------------------------------------- - I suspect the term "confidential" as used here will turn out to mislead or confuse some folks. The meaning is clear if one reads the draft, but of course many people will just read some stackexchange answer. It's probably too late to try change that unless someone has a good term beginning with "c" to use for c-werbrtc. The potential for confusion I think will be that the other label might be assumed to not use a good confidentiality mechanism on the wire, so folks might get concerned that e.g. their DataChannel stuff can be read by a middlebox. (I just mention this in case the concern is either new or has been bubbling up in the WG, feel entirely free to ignore me if you want.) - I forget how the screen sharing issue for WebRTC was resolved. In any case, do the handling of screen sharing and c-webrtc interact? Do you need to explain that there's some non-browser "access" (origination really) of media on the screen-sharer's machine? - "clever arrangement of mirrors" - that is a nice way to explain the futility of DRM :-) From nobody Wed May 4 07:36: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 4A5E212D510; Wed, 4 May 2016 07:36:50 -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 bVj5QgMoqVJE; Wed, 4 May 2016 07:36:48 -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 77F5912B051; Wed, 4 May 2016 07:36:44 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id d62so55766486iof.2; Wed, 04 May 2016 07:36: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; bh=D9b5QGtWSGMJY/Z6ZOJpuvIegA9twLXt4SJZabv7P9M=; b=USo8eRmKnBljwlrfhDw2x7QxyYtZNOkKas/cRbsv1RkRSPPsOGdA52V1niojTxrczZ FVUz5vLEQEeC/14HAoPvGJnSmm1ZU2Wwj40W0GHaaYuO9bNKw0AHI/45BKD49NT3OmMd 5FFZ3nPmOCvQpBBH+P0QeloUkmKnpHHJBIBSJnqmWBia4ykQSVrZ/5IFK6JaasJKb1V2 BKsSBpCzg6GTFK10wXLDdIqz14thmnO9EgzAHdB6Tn4Ex/5FJNw4H1BFZ+XvMgzxaP/k qfPN+Vb8j+BeJtqici55K4UKVOD/JzFOLDnOXCed31wQy+rkThbzWm+g1FIWTuzYHrd1 gXZw== 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=D9b5QGtWSGMJY/Z6ZOJpuvIegA9twLXt4SJZabv7P9M=; b=IHilvO8FNU5G1K27DShAmSv0WhveYSuoXW3uzpCnDi+vfwLfiIL1OWZ1h/9DE0qxwR q/Wfvk4iivzjyLxR5u7W1cGBwdLi6fk6dURkPa/+uDOcJCZFrQy/+X5z7cH07Xipd3kO fLTXE/xT4tAyW2b0+7WV9Q04LL0fBqhWOrdGr5ZfqjXy1qg1mM9gBYjOfhuzK1r2voMi pUUgo92hxdGmuBc8dSbJIWTbdFL24P84549h7OgFEWBz6eq6wwkgDw490STqm9ePhQbV ItU/A0mvboOBdhDfQQZT1iJKWv3f7/z7U300g2clhetYfq0z5dk7QPPQf8eFclLjbqnH WatQ== X-Gm-Message-State: AOPr4FVFjPBmz3L59lc84uDMX8YOF1kKKPXqs0dsQdK//DZxELKIoE858rHMqdQzLYSjb0EUWgNm/fIp8KypoQ== MIME-Version: 1.0 X-Received: by 10.107.161.140 with SMTP id k134mr11603326ioe.190.1462372603808; Wed, 04 May 2016 07:36:43 -0700 (PDT) Received: by 10.36.43.82 with HTTP; Wed, 4 May 2016 07:36:43 -0700 (PDT) In-Reply-To: <20160504073206.8206.5033.idtracker@ietfa.amsl.com> References: <20160504073206.8206.5033.idtracker@ietfa.amsl.com> Date: Thu, 5 May 2016 00:36:43 +1000 Message-ID: From: Martin Thomson To: Stephen Farrell 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] Stephen Farrell'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: Wed, 04 May 2016 14:36:50 -0000 On 4 May 2016 at 17:32, Stephen Farrell wrote: > - I suspect the term "confidential" as used here will turn out > to mislead or confuse some folks. The meaning is clear if one > reads the draft, but of course many people will just read some > stackexchange answer. It's probably too late to try change > that unless someone has a good term beginning with "c" to use > for c-werbrtc. The potential for confusion I think will be > that the other label might be assumed to not use a good > confidentiality mechanism on the wire, so folks might get > concerned that e.g. their DataChannel stuff can be read by a > middlebox. (I just mention this in case the concern is > either new or has been bubbling up in the WG, feel entirely > free to ignore me if you want.) Alissa raised the same point in her review. I believe that the conclusion was what we have. I agree that as a very selective confidentiality, it's potentially misleading. In practice, this is a feature that will require really good understanding of how this all fits together, so I'm not concerned about readership misunderstanding. > - I forget how the screen sharing issue for WebRTC was > resolved. In any case, do the handling of screen sharing and > c-webrtc interact? Do you need to explain that there's some > non-browser "access" (origination really) of media on the > screen-sharer's machine? Screen sharing looks the same as other media in this regard. Of course, screen sharing is still basically inaccessible in browsers due to the huge problems it engenders. From nobody Wed May 4 08:29:27 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47AA12D7DD; Wed, 4 May 2016 08:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.317 X-Spam-Level: X-Spam-Status: No, score=-5.317 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 cODbhANrvtEU; Wed, 4 May 2016 08:29:23 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 9C53112D606; Wed, 4 May 2016 08:26:18 -0700 (PDT) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u44FQG12027709 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 May 2016 11:26:17 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com u44FQG12027709 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1462375577; bh=6bWoWI62Iy8SzNYmHxuxdzjog4I=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=Oj34W6/pmOBNUqPVtmLhGlIuztgh59uNtVTjRCXCg3f8IZvEucPBIMPudN3Z3MQKW oVljulhuw4k/cO/3a97W/8WyX28LrS6dzWr+4PiUx0DVUN2aTBSKukLs0BI/AuCX66 bCq83qiM7dY+4snnLI2Z8e8GmMT445w+26uXIaOM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com u44FQG12027709 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd52.lss.emc.com (RSA Interceptor); Wed, 4 May 2016 11:26:03 -0400 Received: from MXHUB106.corp.emc.com (MXHUB106.corp.emc.com [10.253.58.23]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u44FQB4s013708 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 May 2016 11:26:11 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.9]) by MXHUB106.corp.emc.com ([10.253.58.23]) with mapi id 14.03.0266.001; Wed, 4 May 2016 11:26:10 -0400 From: "Black, David" To: "tsvwg@ietf.org" , "rtcweb@ietf.org" Thread-Topic: Diffserv QoS for Video Thread-Index: AdGmGT33m8jIoXrlTv+NljAQLxjzlw== Date: Wed, 4 May 2016 15:26:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.96.50.112] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Black, David" Subject: [rtcweb] Diffserv QoS for Video 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, 04 May 2016 15:29:26 -0000 Greetings, I write as the shepherd for the WebRTC QoS draft (draft-ietf-tsvwg-rtcweb-q= os). IETF Last Call on this draft uncovered an issue that appears to also requir= e changes in the Web RTC transports draft (draft-ietf-rtcweb-transports). The Web RTC draft specifies different Diffserv Codepoints (DSCPs) for use = with Interactive vs. Non-Interactive Video (with or without audio in both cases)= : https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-5 The IETF LC issue is: How does an implementer determine whether video is interactive vs. non-interactive? The answer (unexpected to at least me) is that this can't be done for curre= nt WebRTC - all video has to be treated as interactive because there's no API support to distinguish interactive video from non-interactive video. That doesn't appear to be stated anywhere obvious, and a TSVWG draft seems like the wrong place to do so.=20 Hence, this message contains initial proposed changes to both the WebRTC Transports draft and WebRTC QoS draft to resolve this issue without removin= g any of the DSCPs currently specified for video in the WebRTC QoS draft. We should resolve this within the next few days, as the WebRTC QoS draft is (finally!) on the IESG telechat agenda for May 19. --- WebRTC Transports draft - proposed changes In Section 4 Media Prioritization, after the following existing text: For media, a "media flow", which can be an "audio flow" or a "video flow", is what [RFC7656] calls a "media source", which results in a "source RTP stream" and one or more "redundancy RTP streams". This specification does not describe prioritization between the RTP streams that come from a single "media source". Add a new paragraph: All media flows in WebRTC are assumed to be interactive; there is no browser API support for non-interactive media, aside from sending non-interactive media content via the data channel. This ought to cite a W3C reference for the WebRTC API - the following appears plausible: [W3C.WD-webrtc-20120209] Bergkvist, A., Burnett, D., Jennings, C., and A. Narayanan, "WebRTC 1.0: Real-time Communication Between Browsers", World Wide Web Consortium WD WD-webrtc- 20120209, February 2012, . =20 -- WebRTC QoS draft - proposed changes In Section 5 DSCP Mappings, after the following existing text: The browser SHOULD first select the flow type of the flow. Within the flow type, the relative importance of the flow SHOULD be used to select the appropriate DSCP value. Add a new paragraph: The current WebRTC browser API does not support non-interactive video; all video is assumed to be interactive [I-D.ietf-rtcweb-transport= s]. Browsers MUST NOT use the DSCP mappings for Non-Interactive Video in Table 1. Non-browser implementations of WebRTC MAY use the DSCP mappings for Non-Interactive Video in Table 1 for video that is known to not be interactive, e.g., all video in a video playback applica= tion based on a custom implementation of the WebRTC protocols would not be interactive. ------ Comments are welcome - as noted, above, we should resolve this in the next few days in order to avoid pulling the WebRTC QoS draft off of the May 19 IESG telechat agenda. Please reply to both the TSVWG and RTCWEB lists, as we need a coherent solution across both drafts. I want to thank Colin Perkins for suggesting the video playback example. Thanks, --David (as WebRTC QoS draft shepherd) From nobody Wed May 4 12:00:51 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 5A36B12DA75; Wed, 4 May 2016 12:00:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504190049.8242.41952.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 12:00:49 -0700 Archived-At: Cc: draft-ietf-rtcweb-alpn@ietf.org, turners@ieca.com, rtcweb@ietf.org, rtcweb-chairs@ietf.org Subject: [rtcweb] Kathleen Moriarty'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: Wed, 04 May 2016 19:00:49 -0000 Kathleen Moriarty 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: ---------------------------------------------------------------------- I agree with Stephen's comments on the word confidentiality, but can't think of an alternate word. I think text describing how this is limited would be helpful in the introduction. The clearest (at least to me) description of what is meant by confidentiality doesn't appear until the security considerations section. From nobody Wed May 4 13:28: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 205D812D6E0; Wed, 4 May 2016 13:28: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 7nilIg6tboF7; Wed, 4 May 2016 13:28:29 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 1110212D6D1; Wed, 4 May 2016 13:28:29 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id 77so28917803pfv.2; Wed, 04 May 2016 13:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=tVQX6LhuXWEN4YyU9zElXs5AGQmP5z61QTXgwA1u5X4=; b=y2UxQlYwkxGgLWQxi0SN1O306dQacLMnDM0PH2Dmx9BAB9eX6xXDdy4NiFMDskYIil 52yviwVgh80KI9YTRKGwxhYvT1RY4bz932V/Btrppd+ajuFlfbu5puIFtXBnUhUZikm2 K+fjcpJ4DZnkguyi4pseNhZ1+crgPbLRJlWfTRkF5PJlB44egYJfBiiq3gtodcDGpmzA xIanKemF/2duzMsfWrtNV72F9WHT6Zt9bmJ9mvqXMjhlewcWeyxD8eelabHCn91GRY9D vjgOyS5ZG7roZLQlywTYckwbsNb8FcVjMydQGCCRyWZWIzAVLWsCxbSZ8OZJIm1vPhJD h3lw== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=tVQX6LhuXWEN4YyU9zElXs5AGQmP5z61QTXgwA1u5X4=; b=ZZOklgaCKL82EiH5qV27wqZsv1fdX9e039OmHKR0TOEfB8Mr1z4Rs2IvETsJ1Rql13 JhMdvh+ch2wZujkMNCyENq3G2mFUZgMyFRcUY7hoNuT1k8IwtktKk45MC52TDo/Hs63B Lhk39/ich/N1k6lSyo4m0n+X1QYyZ/kNgAKtv3zzbGS/qNtKOBcWjNXRqb7+QCO5FyIy a5a1LpHUf0F7eX+VsoTnlrnSu/Nxewl0s0NmAlKP3B7++cTMqlTutA1TDyhjKx0nb3kL LKgyvtkKwxQfVgxsvjh/FtoXKJmk0hzaQCvoc7zYrqIWrN64wggW8PC3I5RFPA02xA4j kcEQ== X-Gm-Message-State: AOPr4FXhb33FR3XtN0x5DjGjXOG7/mesGEyEjlCBr+tkJLNBy4n51dx360YEXevn+cvbCg== X-Received: by 10.98.102.74 with SMTP id a71mr14850998pfc.139.1462393708564; Wed, 04 May 2016 13:28:28 -0700 (PDT) Received: from ?IPv6:2406:e007:5671:1:28cc:dc4c:9703:6781? ([2406:e007:5671:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id zn7sm8086543pac.41.2016.05.04.13.28.24 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2016 13:28:26 -0700 (PDT) To: "Black, David" , "tsvwg@ietf.org" , "rtcweb@ietf.org" References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <7ebc2ca5-c10f-f85e-2b6f-0d685c87f187@gmail.com> Date: Thu, 5 May 2016 08:28:28 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] [tsvwg] Diffserv QoS for Video 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, 04 May 2016 20:28:31 -0000 I fear I have an up-level question: what is the definition of "interactive"? draft-ietf-tsvwg-rtcweb-qos doesn't define it, presumably because it was assumed to be obvious, but thinking about David's suggestions, I decided that it isn't so obvious. https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-4 says: The following are the inputs provided by the WebRTC application to the browser: o Flow Type: The browser provides this input as it knows if the flow is audio, interactive video with or without audio, non-interactive video with or without audio, or data. Firstly, I'm puzzled by the apparent contradiction between the first sentence (in which the app provides input to the browser) and the second sentence (in which to the browser provides input to something else). Then, is it clear how the browser "knows" this? If David's statement below about the API is correct, the browser actually cannot "provide this input" as stated in the above quotation. Or I am confused. Finally, why is audio not also subdivided into interactive and non-interactive? As far as I can see, both are logically possible. Regards Brian On 05/05/2016 03:26, Black, David wrote: > Greetings, > > I write as the shepherd for the WebRTC QoS draft (draft-ietf-tsvwg-rtcweb-qos). > IETF Last Call on this draft uncovered an issue that appears to also require > changes in the Web RTC transports draft (draft-ietf-rtcweb-transports). > > The Web RTC draft specifies different Diffserv Codepoints (DSCPs) for use with > Interactive vs. Non-Interactive Video (with or without audio in both cases): > https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-5 > > The IETF LC issue is: How does an implementer determine whether video is > interactive vs. non-interactive? > > The answer (unexpected to at least me) is that this can't be done for current > WebRTC - all video has to be treated as interactive because there's no API > support to distinguish interactive video from non-interactive video. That > doesn't appear to be stated anywhere obvious, and a TSVWG draft seems > like the wrong place to do so. > > Hence, this message contains initial proposed changes to both the WebRTC > Transports draft and WebRTC QoS draft to resolve this issue without removing > any of the DSCPs currently specified for video in the WebRTC QoS draft. > > We should resolve this within the next few days, as the WebRTC QoS draft is > (finally!) on the IESG telechat agenda for May 19. > > --- WebRTC Transports draft - proposed changes > > In Section 4 Media Prioritization, after the following existing text: > > For media, a "media flow", which can be an "audio flow" or a "video > flow", is what [RFC7656] calls a "media source", which results in a > "source RTP stream" and one or more "redundancy RTP streams". This > specification does not describe prioritization between the RTP > streams that come from a single "media source". > > Add a new paragraph: > > All media flows in WebRTC are assumed to be interactive; there is > no browser API support for non-interactive media, aside from sending > non-interactive media content via the data channel. > > This ought to cite a W3C reference for the WebRTC API - the following > appears plausible: > > [W3C.WD-webrtc-20120209] > Bergkvist, A., Burnett, D., Jennings, C., and A. > Narayanan, "WebRTC 1.0: Real-time Communication Between > Browsers", World Wide Web Consortium WD WD-webrtc- > 20120209, February 2012, > . > > -- WebRTC QoS draft - proposed changes > > In Section 5 DSCP Mappings, after the following existing text: > > The browser SHOULD first select the flow type of the flow. Within > the flow type, the relative importance of the flow SHOULD be used to > select the appropriate DSCP value. > > Add a new paragraph: > > The current WebRTC browser API does not support non-interactive > video; all video is assumed to be interactive [I-D.ietf-rtcweb-transports]. > Browsers MUST NOT use the DSCP mappings for Non-Interactive Video > in Table 1. Non-browser implementations of WebRTC MAY use the > DSCP mappings for Non-Interactive Video in Table 1 for video that is > known to not be interactive, e.g., all video in a video playback application > based on a custom implementation of the WebRTC protocols would not > be interactive. > > ------ > > Comments are welcome - as noted, above, we should resolve this in > the next few days in order to avoid pulling the WebRTC QoS draft off > of the May 19 IESG telechat agenda. Please reply to both the TSVWG and > RTCWEB lists, as we need a coherent solution across both drafts. > > I want to thank Colin Perkins for suggesting the video playback example. > > Thanks, --David (as WebRTC QoS draft shepherd) > > From nobody Wed May 4 16:02: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 57E2E12D5A3; Wed, 4 May 2016 16:02:05 -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 JcrHPedI4uRx; Wed, 4 May 2016 16:02:02 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0AD12D932; Wed, 4 May 2016 16:02:01 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id o133so5934292vka.0; Wed, 04 May 2016 16:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EGKgZyGBuuctKE6RR1PKbdadHrFYnUAV7hH0Yi6IzjY=; b=sXzRSoaKlPNmiEwAnSGEWS9tcYq9OQYyqQjIu0FgTt2cKxSNVGhpSv3JVGBTvV6vwK AuWRvpTr569LX4on9xf4OuZD82eWs3v7pBvQ7vbekNgIJSMoO2WU7PF2/Or+wImei2Gy CZmyVbaOKC1cvJBucakzl7ZJuD0PpluOqcCsDQBclhkE0C7/WOaY8YFlDrXyw5DB1uZD fmfRKwSNeM1bpbB2pKRasdshah1ZVUhahRNMRRTVt6VCXlBKGNVicLEwpLUTcyhEf4bs QUtPvc9loBgk72O+I8POub6cGqBmwzLvutnW5iPKa0YKC3fUG3lcb6vhUqjlmJXD8WfC gYJw== 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=EGKgZyGBuuctKE6RR1PKbdadHrFYnUAV7hH0Yi6IzjY=; b=lTVZwFAlESigfVcPBVTTc1/mqyyo3qZi/EBXjf3f1n5vzZ0H1+d52+9pX4tdInZLEO Wx3ewQnpDCPGuv58fsyUU5vlBYf0r0ybpNa7Hm5f5zW3FEOcLtMrGmraN/8GSRUJ1Stk azwEt5e9UMIsIlpPL8R/K0mGzw2F0xi30MIKPFYOPSWb9z0WNVU/M5sBC56W75a4hGL2 mZqUJZMIIVm66au1oxIlb8kvVV/e7AJ4d1kM1o3ot5xvJQf2DV7GO9+LYKCfsNC/2Izs bXVLXfY2GwvFjydi0ZkqvLl2zsCc3PQOL52L+9gkD+h/ZwOlL7BBvZzmb/D1M74L8XV5 3Nfw== X-Gm-Message-State: AOPr4FWj/4WwYTCFjM5nnFhbPMLD2oNdeU9tqPUF1/85pHWl7nb1dfn1Tim/qQJU+ovFF1OGPU3SGUB/o/n7tg== X-Received: by 10.176.69.148 with SMTP id u20mr7612309uau.9.1462402921020; Wed, 04 May 2016 16:02:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.0.46 with HTTP; Wed, 4 May 2016 16:01:41 -0700 (PDT) In-Reply-To: <7ebc2ca5-c10f-f85e-2b6f-0d685c87f187@gmail.com> References: <7ebc2ca5-c10f-f85e-2b6f-0d685c87f187@gmail.com> From: Bernard Aboba Date: Wed, 4 May 2016 16:01:41 -0700 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=94eb2c11bee8a0430c05320c36a4 Archived-At: Cc: "Black, David" , "rtcweb@ietf.org" , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] Diffserv QoS for Video 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, 04 May 2016 23:02:05 -0000 --94eb2c11bee8a0430c05320c36a4 Content-Type: text/plain; charset=UTF-8 Brian Carpenter said: "Then, is it clear how the browser "knows" this?" [BA] The application explicitly provides information to the browser by setting the RTCRtpEncodingParameters.priority attribute via the sender.setParameters() API: dictionary RTCRtpEncodingParameters { unsigned long ssrc ; RTCRtpRtxParameters rtx ; RTCRtpFecParameters fec ; boolean active ; RTCPriorityType priority ; unsigned long maxBitrate ; unsigned long maxFramerate ; DOMString rid ; double scaleResolutionDownBy = 1.0; }; The Priority and QoS Model is described in the latest WebRTC 1.0 Editor's draft (http://w3c.github.io/webrtc-pc/) Section 4.10: 4.10 Priority and QoS Model Many applications have multiple media flows of the same data type and often some of the flows are more important than others. WebRTC uses the priority and Quality of Service (QoS) framework described in [RTCWEB-TRANSPORT] and [ TSVWG-RTCWEB-QOS] to provide priority and DSCP marking for packets that will help provide QoS in some networking environments. The priority setting can be used to indicate the relative priority of various flows. The priority API allows the JavaScript applications to tell the browser whether a particular media flow is high, medium, low or of very low importance to the application by setting the priorityproperty of RTCRtpEncodingParameters objects to one of the following values. 4.10.1 RTCPriorityType Enum enum RTCPriorityType { "very-low ", "low ", "medium ", "high " }; On Wed, May 4, 2016 at 1:28 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > I fear I have an up-level question: what is the definition of > "interactive"? > > draft-ietf-tsvwg-rtcweb-qos doesn't define it, presumably because it was > assumed to be obvious, but thinking about David's suggestions, I decided > that it isn't so obvious. > > https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-4 says: > > The following are the inputs provided by the WebRTC application to > the browser: > > o Flow Type: The browser provides this input as it knows if the flow > is audio, interactive video with or without audio, non-interactive > video with or without audio, or data. > > Firstly, I'm puzzled by the apparent contradiction between the first > sentence (in which the app provides input to the browser) and the second > sentence (in which to the browser provides input to something else). > > Then, is it clear how the browser "knows" this? If David's statement below > about the API is correct, the browser actually cannot "provide this input" > as stated in the above quotation. Or I am confused. > > Finally, why is audio not also subdivided into interactive and > non-interactive? As far as I can see, both are logically possible. > > Regards > Brian > > On 05/05/2016 03:26, Black, David wrote: > > Greetings, > > > > I write as the shepherd for the WebRTC QoS draft > (draft-ietf-tsvwg-rtcweb-qos). > > IETF Last Call on this draft uncovered an issue that appears to also > require > > changes in the Web RTC transports draft (draft-ietf-rtcweb-transports). > > > > The Web RTC draft specifies different Diffserv Codepoints (DSCPs) for > use with > > Interactive vs. Non-Interactive Video (with or without audio in both > cases): > > https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-5 > > > > The IETF LC issue is: How does an implementer determine whether video is > > interactive vs. non-interactive? > > > > The answer (unexpected to at least me) is that this can't be done for > current > > WebRTC - all video has to be treated as interactive because there's no > API > > support to distinguish interactive video from non-interactive video. > That > > doesn't appear to be stated anywhere obvious, and a TSVWG draft seems > > like the wrong place to do so. > > > > Hence, this message contains initial proposed changes to both the WebRTC > > Transports draft and WebRTC QoS draft to resolve this issue without > removing > > any of the DSCPs currently specified for video in the WebRTC QoS draft. > > > > We should resolve this within the next few days, as the WebRTC QoS draft > is > > (finally!) on the IESG telechat agenda for May 19. > > > > --- WebRTC Transports draft - proposed changes > > > > In Section 4 Media Prioritization, after the following existing text: > > > > For media, a "media flow", which can be an "audio flow" or a "video > > flow", is what [RFC7656] calls a "media source", which results in a > > "source RTP stream" and one or more "redundancy RTP streams". This > > specification does not describe prioritization between the RTP > > streams that come from a single "media source". > > > > Add a new paragraph: > > > > All media flows in WebRTC are assumed to be interactive; there is > > no browser API support for non-interactive media, aside from sending > > non-interactive media content via the data channel. > > > > This ought to cite a W3C reference for the WebRTC API - the following > > appears plausible: > > > > [W3C.WD-webrtc-20120209] > > Bergkvist, A., Burnett, D., Jennings, C., and A. > > Narayanan, "WebRTC 1.0: Real-time Communication Between > > Browsers", World Wide Web Consortium WD WD-webrtc- > > 20120209, February 2012, > > . > > > > -- WebRTC QoS draft - proposed changes > > > > In Section 5 DSCP Mappings, after the following existing text: > > > > The browser SHOULD first select the flow type of the flow. Within > > the flow type, the relative importance of the flow SHOULD be used to > > select the appropriate DSCP value. > > > > Add a new paragraph: > > > > The current WebRTC browser API does not support non-interactive > > video; all video is assumed to be interactive > [I-D.ietf-rtcweb-transports]. > > Browsers MUST NOT use the DSCP mappings for Non-Interactive Video > > in Table 1. Non-browser implementations of WebRTC MAY use the > > DSCP mappings for Non-Interactive Video in Table 1 for video that is > > known to not be interactive, e.g., all video in a video playback > application > > based on a custom implementation of the WebRTC protocols would not > > be interactive. > > > > ------ > > > > Comments are welcome - as noted, above, we should resolve this in > > the next few days in order to avoid pulling the WebRTC QoS draft off > > of the May 19 IESG telechat agenda. Please reply to both the TSVWG and > > RTCWEB lists, as we need a coherent solution across both drafts. > > > > I want to thank Colin Perkins for suggesting the video playback example. > > > > Thanks, --David (as WebRTC QoS draft shepherd) > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --94eb2c11bee8a0430c05320c36a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Brian Carpenter said:=C2=A0

"Then, is it clear how the browser "knows&q= uot; this?"

[BA] The application expli= citly provides information to the browser by setting the RTCRtpEncodingPara= meters.priority attribute via the sender.setParameters() API:=C2=A0

dictionary RTCRtpEncodingParameters {
             unsigned long       ssrc;
             RTCRtpRtxParameters rtx;
             RTCRtpFecParameters fec;
             boolean             active;
             RTCPriorityType     priority;
             unsigned long       maxBitrate;
             unsigned long       maxFramerate;<=
/span>
             DOMString           rid;
             double              scaleResolutionD=
ownBy =3D 1.0;
};

The Priority and QoS Model is desc= ribed in the latest WebRTC 1.0 Editor's draft (http://w3c.github.io/webrtc-pc/) = Section 4.10:=C2=A0

4.10=C2= =A0Priority and QoS Model

Many applications have multiple media flows of the s= ame data type and often some of the flows are more important than others. W= ebRTC uses the priority and Quality of Service (QoS) framework described in= [RTCWEB-TRANSPORT] and [TSVWG-RTCWEB-QOS] to pro= vide priority and DSCP marking for packets that will help provide QoS in so= me networking environments. The priority setting can be used to indicate th= e relative priority of various flows. The priority API allows the JavaScrip= t applications to tell the browser whether a particular media flow is high,= medium, low or of very low importance to the application by setting the=C2= =A0priorityproperty = of=C2=A0RTCRtpEncodingParameters=C2=A0objects to one of the= following values.

4.10.1=C2=A0RTCPriorityType= Enum


enum RTCPriorityType {
    "very-low=
",
    "low"=
,
    "medium=
",
    "high&quo=
t;
};

On Wed, May 4, 2016 at 1:28 PM, Brian E Carpenter <bria= n.e.carpenter@gmail.com> wrote:
I fear I have an up-level question: what is the definition of "in= teractive"?

draft-ietf-tsvwg-rtcweb-qos doesn't define it, presumably because it wa= s
assumed to be obvious, but thinking about David's suggestions, I decide= d
that it isn't so obvious.

https://tools.ietf.org/html/draf= t-ietf-tsvwg-rtcweb-qos-15#section-4 says:

=C2=A0 =C2=A0The following are the inputs provided by the WebRTC applicatio= n to
=C2=A0 =C2=A0the browser:

=C2=A0 =C2=A0o=C2=A0 Flow Type: The browser provides this input as it knows= if the flow
=C2=A0 =C2=A0 =C2=A0 is audio, interactive video with or without audio, non= -interactive
=C2=A0 =C2=A0 =C2=A0 video with or without audio, or data.

Firstly, I'm puzzled by the apparent contradiction between the first sentence (in which the app provides input to the browser) and the second sentence (in which to the browser provides input to something else).

Then, is it clear how the browser "knows" this? If David's st= atement below
about the API is correct, the browser actually cannot "provide this in= put"
as stated in the above quotation. Or I am confused.

Finally, why is audio not also subdivided into interactive and
non-interactive? As far as I can see, both are logically possible.

Regards
=C2=A0 =C2=A0Brian

On 05/05/2016 03:26, Black, David wrote:
> Greetings,
>
> I write as the shepherd for the WebRTC QoS draft (draft-ietf-tsvwg-rtc= web-qos).
> IETF Last Call on this draft uncovered an issue that appears to also r= equire
> changes in the Web RTC transports draft (draft-ietf-rtcweb-transports)= .
>
> The Web RTC draft=C2=A0 specifies different Diffserv Codepoints (DSCPs= ) for use with
> Interactive vs. Non-Interactive Video (with or without audio in both c= ases):
> https://tools.ietf.org/html= /draft-ietf-tsvwg-rtcweb-qos-15#section-5
>
> The IETF LC issue is: How does an implementer determine whether video = is
> interactive vs. non-interactive?
>
> The answer (unexpected to at least me) is that this can't be done = for current
> WebRTC - all video has to be treated as interactive because there'= s no API
> support to distinguish interactive video from non-interactive video.= =C2=A0 That
> doesn't appear to be stated anywhere obvious, and a TSVWG draft se= ems
> like the wrong place to do so.
>
> Hence, this message contains initial proposed changes to both the WebR= TC
> Transports draft and WebRTC QoS draft to resolve this issue without re= moving
> any of the DSCPs currently specified for video in the WebRTC QoS draft= .
>
> We should resolve this within the next few days, as the WebRTC QoS dra= ft is
> (finally!) on the IESG telechat agenda for May 19.
>
> --- WebRTC Transports draft - proposed changes
>
> In Section 4 Media Prioritization, after the following existing text:<= br> >
>=C2=A0 =C2=A0 For media, a "media flow", which can be an &quo= t;audio flow" or a "video
>=C2=A0 =C2=A0 flow", is what [RFC7656] calls a "media source&= quot;, which results in a
>=C2=A0 =C2=A0 "source RTP stream" and one or more "redun= dancy RTP streams".=C2=A0 This
>=C2=A0 =C2=A0 specification does not describe prioritization between th= e RTP
>=C2=A0 =C2=A0 streams that come from a single "media source".=
>
> Add a new paragraph:
>
>=C2=A0 =C2=A0 All media flows in WebRTC are assumed to be interactive; = there is
>=C2=A0 =C2=A0 no browser API support for non-interactive media, aside f= rom sending
>=C2=A0 =C2=A0 non-interactive media content via the data channel.
>
> This ought to cite a W3C reference for the WebRTC API - the following<= br> > appears plausible:
>
>=C2=A0 =C2=A0 [W3C.WD-webrtc-20120209]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Bergkvist, A., B= urnett, D., Jennings, C., and A.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Narayanan, "= ;WebRTC 1.0: Real-time Communication Between
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Browsers", = World Wide Web Consortium WD WD-webrtc-
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A020120209, Februa= ry 2012,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.w3.org/TR/2012/WD-webrtc-20120209>.
>
> -- WebRTC QoS draft - proposed changes
>
> In Section 5 DSCP Mappings, after the following existing text:
>
>=C2=A0 =C2=A0 The browser SHOULD first select the flow type of the flow= .=C2=A0 Within
>=C2=A0 =C2=A0 the flow type, the relative importance of the flow SHOULD= be used to
>=C2=A0 =C2=A0 select the appropriate DSCP value.
>
> Add a new paragraph:
>
>=C2=A0 =C2=A0 The current WebRTC browser API does not support non-inter= active
>=C2=A0 =C2=A0 video; all video is assumed to be interactive [I-D.ietf-r= tcweb-transports].
>=C2=A0 =C2=A0 Browsers MUST NOT use the DSCP mappings for Non-Interacti= ve Video
>=C2=A0 =C2=A0 in Table 1.=C2=A0 Non-browser implementations of WebRTC M= AY use the
>=C2=A0 =C2=A0 DSCP mappings for Non-Interactive Video in Table 1 for vi= deo that is
>=C2=A0 =C2=A0 known to not be interactive, e.g., all video in a video p= layback application
>=C2=A0 =C2=A0 based on a custom implementation of the WebRTC protocols = would not
>=C2=A0 =C2=A0 be interactive.
>
> ------
>
> Comments are welcome - as noted, above,=C2=A0 we should resolve this i= n
> the next few days in order to avoid pulling the WebRTC QoS draft off > of the May 19 IESG telechat agenda. Please reply to both the TSVWG and=
> RTCWEB lists, as we need=C2=A0 a coherent solution across both drafts.=
>
> I want to thank Colin Perkins for suggesting the video playback exampl= e.
>
> Thanks, --David (as WebRTC QoS draft shepherd)
>
>

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

--94eb2c11bee8a0430c05320c36a4-- From nobody Wed May 4 17:37: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 AFDE412D675; Wed, 4 May 2016 17:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiutF6H5fwRM; Wed, 4 May 2016 17:36:55 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::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 3C03612D535; Wed, 4 May 2016 17:36:55 -0700 (PDT) Received: by mail-pa0-x233.google.com with SMTP id xk12so29842616pac.0; Wed, 04 May 2016 17:36:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=MFwvFrQhdZ665fmLf47yEBQ3PbJK3MB0vM+m8etYCT8=; b=VNiNt81EAeOqHV+DpA6CX+lr5APjYRc870e1mzdWmxppKPQi43Ogam8upwSx8mqwTY b/JdguOqwNNo4Un197fg2jTmSt55h3VSvy+QjreZ7Hn2yIlIRxXUKuCuQ9cLFpMBFdVy prT0ZC1cQLr4Cf2hzcXbi/e0LTBMwHZUxRmkxu6JuWUSoRXLnazL2AUArRGT6fuyYcYf jr+Yy4cOjEkoUS9P4SKH/NB8iHV5IaTvlSp6V7Aoo0n+VdnNDYG4O2U5Fp5KlONcVKCq MthAgQiJ0cbKxdWU+UFaQzIR2kDd8OMGmkM1nSyDKvlkD80SVPPr9HibiJIPap6n8myv WHWw== 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:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=MFwvFrQhdZ665fmLf47yEBQ3PbJK3MB0vM+m8etYCT8=; b=WrduxyO/YNPFm/+Ww9I/80zHP06AVtI/y1MmkvimxEW3VXs9M0C8CcQfVffJ63WZUi L4gRQHtG8miTV0X1AxbtvIduHjDaDxLs3OMR2bZksXNpVm+8pajHItjn/8WxqTXQqV5N rKCo3PZparrM5023EbkXxVCFc7Y2kxRYmb35UxDWHy9Jrcw/jnz4icYCr6t3WQQ+64+K VqqfjBGogFZR383Fal6MTFn8Ys3QxW5pcyKgcKxwWHRba3zfsiiY31zOa1VRGXM4Y8r0 7LVPIPlvoeQcSEx9N5V7FUm2bJa5mZkf9iF3eC71q+hi6KfWlP2woWiVzVX2hQORYbw2 5+fA== X-Gm-Message-State: AOPr4FUIJ7f0TT6ixY7X4dbtPRLDmJkXPhUd0kDUDiTnyA7+PLzrLeRw/HohWCDSsglvMg== X-Received: by 10.67.3.200 with SMTP id by8mr16087131pad.13.1462408614810; Wed, 04 May 2016 17:36:54 -0700 (PDT) Received: from ?IPv6:2406:e007:5671:1:28cc:dc4c:9703:6781? ([2406:e007:5671:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id f16sm8699346pfj.71.2016.05.04.17.36.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2016 17:36:53 -0700 (PDT) To: Bernard Aboba References: <7ebc2ca5-c10f-f85e-2b6f-0d685c87f187@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 5 May 2016 12:36:58 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "Black, David" , "rtcweb@ietf.org" , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] Diffserv QoS for Video 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, 05 May 2016 00:36:57 -0000 Thanks Bernard. All the same, I think the phrasing I quoted at https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-4 is problematic; it implies that there's a Boolean property "interactive" which clearly is not supported in the encoding parameters. Regards Brian On 05/05/2016 11:01, Bernard Aboba wrote: > Brian Carpenter said: > > "Then, is it clear how the browser "knows" this?" > > [BA] The application explicitly provides information to the browser by setting the RTCRtpEncodingParameters.priority attribute > via the sender.setParameters() API: > > dictionary RTCRtpEncodingParameters { unsigned long ssrc ; > |RTCRtpRtxParameters| rtx ; |RTCRtpFecParameters| fec > ; boolean active > ; |RTCPriorityType| priority > ; unsigned long maxBitrate > ; unsigned long maxFramerate > ; DOMString rid > ; double scaleResolutionDownBy > = 1.0; }; > > > The Priority and QoS Model is described in the latest WebRTC 1.0 Editor's draft (http://w3c.github.io/webrtc-pc/) Section 4.10: > > 4.10 Priority and QoS Model > > Many applications have multiple media flows of the same data type and often some of the flows are more important than others. > WebRTC uses the priority and Quality of Service (QoS) framework described in [RTCWEB-TRANSPORT] and [TSVWG-RTCWEB-QOS] to > provide priority and DSCP marking for packets that will help provide QoS in some networking environments. The priority setting > can be used to indicate the relative priority of various flows. The priority API allows the JavaScript applications to tell the > browser whether a particular media flow is high, medium, low or of very low importance to the application by setting > the |priority|property of ||RTCRtpEncodingParameters|| objects to one of the following values. > > > 4.10.1 RTCPriorityType Enum > > > enum RTCPriorityType { > "very-low ", > "low ", > "medium ", > "high " > }; > > > On Wed, May 4, 2016 at 1:28 PM, Brian E Carpenter > wrote: > > I fear I have an up-level question: what is the definition of "interactive"? > > draft-ietf-tsvwg-rtcweb-qos doesn't define it, presumably because it was > assumed to be obvious, but thinking about David's suggestions, I decided > that it isn't so obvious. > > https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-4 says: > > The following are the inputs provided by the WebRTC application to > the browser: > > o Flow Type: The browser provides this input as it knows if the flow > is audio, interactive video with or without audio, non-interactive > video with or without audio, or data. > > Firstly, I'm puzzled by the apparent contradiction between the first > sentence (in which the app provides input to the browser) and the second > sentence (in which to the browser provides input to something else). > > Then, is it clear how the browser "knows" this? If David's statement below > about the API is correct, the browser actually cannot "provide this input" > as stated in the above quotation. Or I am confused. > > Finally, why is audio not also subdivided into interactive and > non-interactive? As far as I can see, both are logically possible. > > Regards > Brian > > On 05/05/2016 03:26, Black, David wrote: > > Greetings, > > > > I write as the shepherd for the WebRTC QoS draft (draft-ietf-tsvwg-rtcweb-qos). > > IETF Last Call on this draft uncovered an issue that appears to also require > > changes in the Web RTC transports draft (draft-ietf-rtcweb-transports). > > > > The Web RTC draft specifies different Diffserv Codepoints (DSCPs) for use with > > Interactive vs. Non-Interactive Video (with or without audio in both cases): > > https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-5 > > > > The IETF LC issue is: How does an implementer determine whether video is > > interactive vs. non-interactive? > > > > The answer (unexpected to at least me) is that this can't be done for current > > WebRTC - all video has to be treated as interactive because there's no API > > support to distinguish interactive video from non-interactive video. That > > doesn't appear to be stated anywhere obvious, and a TSVWG draft seems > > like the wrong place to do so. > > > > Hence, this message contains initial proposed changes to both the WebRTC > > Transports draft and WebRTC QoS draft to resolve this issue without removing > > any of the DSCPs currently specified for video in the WebRTC QoS draft. > > > > We should resolve this within the next few days, as the WebRTC QoS draft is > > (finally!) on the IESG telechat agenda for May 19. > > > > --- WebRTC Transports draft - proposed changes > > > > In Section 4 Media Prioritization, after the following existing text: > > > > For media, a "media flow", which can be an "audio flow" or a "video > > flow", is what [RFC7656] calls a "media source", which results in a > > "source RTP stream" and one or more "redundancy RTP streams". This > > specification does not describe prioritization between the RTP > > streams that come from a single "media source". > > > > Add a new paragraph: > > > > All media flows in WebRTC are assumed to be interactive; there is > > no browser API support for non-interactive media, aside from sending > > non-interactive media content via the data channel. > > > > This ought to cite a W3C reference for the WebRTC API - the following > > appears plausible: > > > > [W3C.WD-webrtc-20120209] > > Bergkvist, A., Burnett, D., Jennings, C., and A. > > Narayanan, "WebRTC 1.0: Real-time Communication Between > > Browsers", World Wide Web Consortium WD WD-webrtc- > > 20120209, February 2012, > > . > > > > -- WebRTC QoS draft - proposed changes > > > > In Section 5 DSCP Mappings, after the following existing text: > > > > The browser SHOULD first select the flow type of the flow. Within > > the flow type, the relative importance of the flow SHOULD be used to > > select the appropriate DSCP value. > > > > Add a new paragraph: > > > > The current WebRTC browser API does not support non-interactive > > video; all video is assumed to be interactive [I-D.ietf-rtcweb-transports]. > > Browsers MUST NOT use the DSCP mappings for Non-Interactive Video > > in Table 1. Non-browser implementations of WebRTC MAY use the > > DSCP mappings for Non-Interactive Video in Table 1 for video that is > > known to not be interactive, e.g., all video in a video playback application > > based on a custom implementation of the WebRTC protocols would not > > be interactive. > > > > ------ > > > > Comments are welcome - as noted, above, we should resolve this in > > the next few days in order to avoid pulling the WebRTC QoS draft off > > of the May 19 IESG telechat agenda. Please reply to both the TSVWG and > > RTCWEB lists, as we need a coherent solution across both drafts. > > > > I want to thank Colin Perkins for suggesting the video playback example. > > > > Thanks, --David (as WebRTC QoS draft shepherd) > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > From nobody Wed May 4 18:41: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 156CA12D1CD; Wed, 4 May 2016 18:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 MBA26yzp3MX0; Wed, 4 May 2016 18:41:31 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 872D112D1BD; Wed, 4 May 2016 18:41:31 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id o133so9252079vka.0; Wed, 04 May 2016 18:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jvky9l5WWGJsTk3HZkE5+dAhTxDC4XV8+NR2OMq6qUM=; b=hULzixnX1eaS8GLeIf3n5stgrW7tuZQBdcVIgG38++898nH1n1f/Ix0wVTGLIFWHGr u357gGY/0ILduFrMD5Bq8VmDF9+FPe2s2dck+HxhYVEPvYG+b4MpvmUZUWDzX+NI8K3N DiDVqUbrelNQU5Pim/NftcvPVbkcMLQxDDLqTxT+JqnbJj+T19Ft5c0PosURxvbmWsoP JUY/ve6NQfftMyat/2alIzmp9hcHpSMqd7g9KbbpAaZ5QPKeBywoK4+/FTsIMTulaVPU WxYFiXW88EmFj9XEDiqJ/iPx2zGUzFnvPjbs0Vcsz1yLPTUzG2Wb0XopcRSG/V8EDoUB 6jhA== 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=jvky9l5WWGJsTk3HZkE5+dAhTxDC4XV8+NR2OMq6qUM=; b=H/YGxLqXUaCyCnifETsHVjF2F0zqniwE6Myo5rtYM9IY3g2QRpnm4Gksz6S04pfWav nWzv6Fc1grTP1gdFQGLY7SDb6itP7VTR5b/iQdfK2Z/qeMXrfIW2NoFSwX4AH1NExAr0 Z58dEP7KOUJqF5T9SgM4YhPn6v6/apSQIeDwKrcxhyLbwTPDfMn0MGYwq3Nwu/bGwpiV eMQWQD3spj6Zu0aVmtCfH2ayqLj1vxdIcxPTDf9jFeozCUQu+cOjeCeAwmiwP9xCZLlM Rm3B4JvGVtO4ZhWctDF9frRbU7ZFSj5WFhNYGP2QPBx2bOWZcdMKW3aXjR14HO/KlFyb eNfg== X-Gm-Message-State: AOPr4FXO++4C42OIRSr0AS3bikTWcy4f/oLQgZxuxxlaT7znv7OSeLwXBvAOe7BBEmTQi/El6q7FzsyPrnN6+w== X-Received: by 10.176.5.38 with SMTP id 35mr7598060uax.116.1462412490362; Wed, 04 May 2016 18:41:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.0.46 with HTTP; Wed, 4 May 2016 18:41:10 -0700 (PDT) In-Reply-To: References: <7ebc2ca5-c10f-f85e-2b6f-0d685c87f187@gmail.com> From: Bernard Aboba Date: Wed, 4 May 2016 18:41:10 -0700 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=94eb2c12541800d71f05320e7161 Archived-At: Cc: "Black, David" , "rtcweb@ietf.org" , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] Diffserv QoS for Video 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, 05 May 2016 01:41:35 -0000 --94eb2c12541800d71f05320e7161 Content-Type: text/plain; charset=UTF-8 Brian said: "All the same, I think the phrasing I quoted at https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-4 is problematic; it implies that there's a Boolean property "interactive" which clearly is not supported in the encoding parameters." [BA] Overall, I'm not clear that this thread is asking the right questions, or making correct statements about the existing API. To my mind, the real question is whether a "non-interactive" marking/priority would deliver anything useful to application developers, not whether the API could support it. The encoding parameters can be used to allow an application to specify a priority attribute. If a "non-interactive" marking and associated priority attribute were to be defined, the current API could allow applications to specify that. So citing a 4-year old version of the WebRTC 1.0 specification as justification for the lack of API functionality doesn't make sense to me. Since the browser just does what it is told to do by the application, whether the browser "knows" whether the media is interactive or not also does not matter. The real question is whether a "non-interactive" marking/priority setting would be useful to application developers. Uni-directional communications (e.g. "sendonly", "recvonly") is supported within WebRTC. Would those kind of flows benefit from a "non-interactive" marking? In most cases, I suspect that in general it would not be useful (a possible exception might be use of SVC codecs protecting only the base layer with FEC/RTX). It is conceivable that an application might want to attach a track to a sender that isn't obtained from getUserMedia() (see: http://w3c.github.io/mediacapture-main/) or getDisplayMedia() (see https://w3c.github.io/mediacapture-screen-share/). Again, the question is whether a "non-interactive" marking/priority would be helpful in those cases. I suspect the answer to that is also "no" for similar reasons. On Wed, May 4, 2016 at 5:36 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Thanks Bernard. > > All the same, I think the phrasing I quoted at > https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-4 > is problematic; it implies that there's a Boolean property "interactive" > which clearly is not supported in the encoding parameters. > > Regards > Brian > > On 05/05/2016 11:01, Bernard Aboba wrote: > > Brian Carpenter said: > > > > "Then, is it clear how the browser "knows" this?" > > > > [BA] The application explicitly provides information to the browser by > setting the RTCRtpEncodingParameters.priority attribute > > via the sender.setParameters() API: > > > > dictionary RTCRtpEncodingParameters { unsigned long ssrc < > http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-ssrc>; > > |RTCRtpRtxParameters| rtx < > http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-rtx>; > |RTCRtpFecParameters| fec > > ; > boolean active > > ; > |RTCPriorityType| priority > > ; > unsigned long maxBitrate > > < > http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-maxBitrate>; > unsigned long maxFramerate > > < > http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-maxFramerate>; > DOMString rid > > ; > double scaleResolutionDownBy > > < > http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-scaleResolutionDownBy> > = 1.0; }; > > > > > > The Priority and QoS Model is described in the latest WebRTC 1.0 > Editor's draft (http://w3c.github.io/webrtc-pc/) Section 4.10: > > > > 4.10 Priority and QoS Model > > > > Many applications have multiple media flows of the same data type and > often some of the flows are more important than others. > > WebRTC uses the priority and Quality of Service (QoS) framework > described in [RTCWEB-TRANSPORT] and [TSVWG-RTCWEB-QOS] to > > provide priority and DSCP marking for packets that will help provide QoS > in some networking environments. The priority setting > > can be used to indicate the relative priority of various flows. The > priority API allows the JavaScript applications to tell the > > browser whether a particular media flow is high, medium, low or of very > low importance to the application by setting > > the |priority|property of ||RTCRtpEncodingParameters|| objects to one of > the following values. > > > > > > 4.10.1 RTCPriorityType Enum > > > > > > enum RTCPriorityType { > > "very-low < > http://w3c.github.io/webrtc-pc/#idl-def-RTCPriorityType.very-low>", > > "low ", > > "medium < > http://w3c.github.io/webrtc-pc/#idl-def-RTCPriorityType.medium>", > > "high >" > > }; > > > > > > On Wed, May 4, 2016 at 1:28 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com > wrote: > > > > I fear I have an up-level question: what is the definition of > "interactive"? > > > > draft-ietf-tsvwg-rtcweb-qos doesn't define it, presumably because it > was > > assumed to be obvious, but thinking about David's suggestions, I > decided > > that it isn't so obvious. > > > > https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-4 > says: > > > > The following are the inputs provided by the WebRTC application to > > the browser: > > > > o Flow Type: The browser provides this input as it knows if the > flow > > is audio, interactive video with or without audio, > non-interactive > > video with or without audio, or data. > > > > Firstly, I'm puzzled by the apparent contradiction between the first > > sentence (in which the app provides input to the browser) and the > second > > sentence (in which to the browser provides input to something else). > > > > Then, is it clear how the browser "knows" this? If David's statement > below > > about the API is correct, the browser actually cannot "provide this > input" > > as stated in the above quotation. Or I am confused. > > > > Finally, why is audio not also subdivided into interactive and > > non-interactive? As far as I can see, both are logically possible. > > > > Regards > > Brian > > > > On 05/05/2016 03:26, Black, David wrote: > > > Greetings, > > > > > > I write as the shepherd for the WebRTC QoS draft > (draft-ietf-tsvwg-rtcweb-qos). > > > IETF Last Call on this draft uncovered an issue that appears to > also require > > > changes in the Web RTC transports draft > (draft-ietf-rtcweb-transports). > > > > > > The Web RTC draft specifies different Diffserv Codepoints (DSCPs) > for use with > > > Interactive vs. Non-Interactive Video (with or without audio in > both cases): > > > > https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-5 > > > > > > The IETF LC issue is: How does an implementer determine whether > video is > > > interactive vs. non-interactive? > > > > > > The answer (unexpected to at least me) is that this can't be done > for current > > > WebRTC - all video has to be treated as interactive because > there's no API > > > support to distinguish interactive video from non-interactive > video. That > > > doesn't appear to be stated anywhere obvious, and a TSVWG draft > seems > > > like the wrong place to do so. > > > > > > Hence, this message contains initial proposed changes to both the > WebRTC > > > Transports draft and WebRTC QoS draft to resolve this issue > without removing > > > any of the DSCPs currently specified for video in the WebRTC QoS > draft. > > > > > > We should resolve this within the next few days, as the WebRTC QoS > draft is > > > (finally!) on the IESG telechat agenda for May 19. > > > > > > --- WebRTC Transports draft - proposed changes > > > > > > In Section 4 Media Prioritization, after the following existing > text: > > > > > > For media, a "media flow", which can be an "audio flow" or a > "video > > > flow", is what [RFC7656] calls a "media source", which results > in a > > > "source RTP stream" and one or more "redundancy RTP streams". > This > > > specification does not describe prioritization between the RTP > > > streams that come from a single "media source". > > > > > > Add a new paragraph: > > > > > > All media flows in WebRTC are assumed to be interactive; there > is > > > no browser API support for non-interactive media, aside from > sending > > > non-interactive media content via the data channel. > > > > > > This ought to cite a W3C reference for the WebRTC API - the > following > > > appears plausible: > > > > > > [W3C.WD-webrtc-20120209] > > > Bergkvist, A., Burnett, D., Jennings, C., and A. > > > Narayanan, "WebRTC 1.0: Real-time Communication > Between > > > Browsers", World Wide Web Consortium WD WD-webrtc- > > > 20120209, February 2012, > > > . > > > > > > -- WebRTC QoS draft - proposed changes > > > > > > In Section 5 DSCP Mappings, after the following existing text: > > > > > > The browser SHOULD first select the flow type of the flow. > Within > > > the flow type, the relative importance of the flow SHOULD be > used to > > > select the appropriate DSCP value. > > > > > > Add a new paragraph: > > > > > > The current WebRTC browser API does not support non-interactive > > > video; all video is assumed to be interactive > [I-D.ietf-rtcweb-transports]. > > > Browsers MUST NOT use the DSCP mappings for Non-Interactive > Video > > > in Table 1. Non-browser implementations of WebRTC MAY use the > > > DSCP mappings for Non-Interactive Video in Table 1 for video > that is > > > known to not be interactive, e.g., all video in a video > playback application > > > based on a custom implementation of the WebRTC protocols would > not > > > be interactive. > > > > > > ------ > > > > > > Comments are welcome - as noted, above, we should resolve this in > > > the next few days in order to avoid pulling the WebRTC QoS draft > off > > > of the May 19 IESG telechat agenda. Please reply to both the TSVWG > and > > > RTCWEB lists, as we need a coherent solution across both drafts. > > > > > > I want to thank Colin Perkins for suggesting the video playback > example. > > > > > > Thanks, --David (as WebRTC QoS draft shepherd) > > > > > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > --94eb2c12541800d71f05320e7161 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Brian said:=C2=A0

"All the same, I think the phrasing I quoted athtt= ps://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-4
is problematic; i= t implies that there's a Boolean property "interactive"
which= clearly is not supported in the encoding parameters."

[BA] Overall, I'm not clear that this thread is asking= the right questions, or making correct statements about the existing API.= =C2=A0 To my mind, the real question is whether a "non-interactive&quo= t; marking/priority would deliver anything useful to application developers= , not whether the API could support it.=C2=A0

The = encoding parameters can be used to allow an application to specify a priori= ty attribute.=C2=A0 If a "non-interactive" marking and associated= priority attribute were to be defined, the current API could allow applica= tions to specify that.=C2=A0 So citing a 4-year old version of the WebRTC 1= .0 specification as justification for the lack of API functionality doesn&#= 39;t make sense to me. =C2=A0 Since the browser just does what it is told t= o do by the application, whether the browser "knows" whether the = media is interactive or not also does not matter.=C2=A0

The real question is whether a =C2=A0"non-interactive" mark= ing/priority setting would be useful to application developers.=C2=A0
=

Uni-directional communications (e.g. "sendonly&quo= t;, "recvonly") is supported within WebRTC.=C2=A0 Would those kin= d of flows benefit from a "non-interactive" marking? In most case= s, I suspect that in general it would not be useful (a possible exception m= ight be use of SVC codecs protecting only the base layer with FEC/RTX). =C2= =A0

It is conceivable that an application might wa= nt to attach a track to a sender that isn't obtained from getUserMedia(= ) (see: http://w3c.gith= ub.io/mediacapture-main/) or getDisplayMedia() (see=C2=A0https://w3c.github.io/mediac= apture-screen-share/).=C2=A0 Again, the question is whether a "non= -interactive" marking/priority would be helpful in those cases.=C2=A0 = I suspect the answer to that is also "no" for similar reasons.=C2= =A0

On= Wed, May 4, 2016 at 5:36 PM, Brian E Carpenter <brian.e.carpent= er@gmail.com> wrote:
Thanks= Bernard.

All the same, I think the phrasing I quoted at
https://tools.ietf.org/html/draf= t-ietf-tsvwg-rtcweb-qos-15#section-4
is problematic; it implies that there's a Boolean property "intera= ctive"
which clearly is not supported in the encoding parameters.

Regards
=C2=A0 =C2=A0Brian

On 05/05/2016 11:01, Bernard Aboba wrote:
> Brian Carpenter said:
>
> "Then, is it clear how the browser "knows" this?"<= br> >
> [BA] The application explicitly provides information to the browser by= setting the RTCRtpEncodingParameters.priority attribute
> via the sender.setParameters() API:
>
> dictionary RTCRtpEncodingParameters { unsigned long ssrc <http://w3c.github.io/webrtc-pc/#widl= -RTCRtpEncodingParameters-ssrc>;
> |RTCRtpRtxParameters| rtx <= http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-rtx>; = |RTCRtpFecParameters| fec
> <http://w3c.github.io/webrt= c-pc/#widl-RTCRtpEncodingParameters-fec>; boolean active
> <http://w3c.github.io/we= brtc-pc/#widl-RTCRtpEncodingParameters-active>; |RTCPriorityType| pr= iority
> <http://w3c.github.io/= webrtc-pc/#widl-RTCRtpEncodingParameters-priority>; unsigned long ma= xBitrate
> <http://w3c.github.i= o/webrtc-pc/#widl-RTCRtpEncodingParameters-maxBitrate>; unsigned lon= g maxFramerate
> <http://w3c.github= .io/webrtc-pc/#widl-RTCRtpEncodingParameters-maxFramerate>; DOMStrin= g rid
> <http://w3c.github.io/webrt= c-pc/#widl-RTCRtpEncodingParameters-rid>; double scaleResolutionDown= By
> <http://w= 3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-scaleResolutionDownBy= > =3D 1.0; };
>
>
> The Priority and QoS Model is described in the latest WebRTC 1.0 Edito= r's draft (http://w3c.github.io/webrtc-pc/) Section 4.10:
>
> 4.10 Priority and QoS Model
>
> Many applications have multiple media flows of the same data type and = often some of the flows are more important than others.
> WebRTC uses the priority and Quality of Service (QoS) framework descri= bed in [RTCWEB-TRANSPORT] and [TSVWG-RTCWEB-QOS] to
> provide priority and DSCP marking for packets that will help provide Q= oS in some networking environments. The priority setting
> can be used to indicate the relative priority of various flows. The pr= iority API allows the JavaScript applications to tell the
> browser whether a particular media flow is high, medium, low or of ver= y low importance to the application by setting
> the |priority|property of ||RTCRtpEncodingParameters|| objects = to one of the following values.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A04.10.1 RTCPriorityType Enum
>
>
> enum RTCPriorityType {
>=C2=A0 =C2=A0 =C2=A0"very-low <http://w3c.github.io/webrtc-pc/#idl-def-RTCPriorityType.very-= low>",
>=C2=A0 =C2=A0 =C2=A0"low <htt= p://w3c.github.io/webrtc-pc/#idl-def-RTCPriorityType.low>",
>=C2=A0 =C2=A0 =C2=A0"medium <http://w3c.github.io/webrtc-pc/#idl-def-RTCPriorityType.medium>&q= uot;,
>=C2=A0 =C2=A0 =C2=A0"high <h= ttp://w3c.github.io/webrtc-pc/#idl-def-RTCPriorityType.high>" > };
>
>
> On Wed, May 4, 2016 at 1:28 PM, Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:<= a href=3D"mailto:brian.e.carpenter@gmail.com">brian.e.carpenter@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0I fear I have an up-level question: what is the def= inition of "interactive"?
>
>=C2=A0 =C2=A0 =C2=A0draft-ietf-tsvwg-rtcweb-qos doesn't define it, = presumably because it was
>=C2=A0 =C2=A0 =C2=A0assumed to be obvious, but thinking about David'= ;s suggestions, I decided
>=C2=A0 =C2=A0 =C2=A0that it isn't so obvious.
>
>=C2=A0 =C2=A0 =C2=A0https://= tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-4 says:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 The following are the inputs provided by th= e WebRTC application to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 the browser:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 o=C2=A0 Flow Type: The browser provides thi= s input as it knows if the flow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is audio, interactive video wi= th or without audio, non-interactive
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0video with or without audio, o= r data.
>
>=C2=A0 =C2=A0 =C2=A0Firstly, I'm puzzled by the apparent contradict= ion between the first
>=C2=A0 =C2=A0 =C2=A0sentence (in which the app provides input to the br= owser) and the second
>=C2=A0 =C2=A0 =C2=A0sentence (in which to the browser provides input to= something else).
>
>=C2=A0 =C2=A0 =C2=A0Then, is it clear how the browser "knows"= this? If David's statement below
>=C2=A0 =C2=A0 =C2=A0about the API is correct, the browser actually cann= ot "provide this input"
>=C2=A0 =C2=A0 =C2=A0as stated in the above quotation. Or I am confused.=
>
>=C2=A0 =C2=A0 =C2=A0Finally, why is audio not also subdivided into inte= ractive and
>=C2=A0 =C2=A0 =C2=A0non-interactive? As far as I can see, both are logi= cally possible.
>
>=C2=A0 =C2=A0 =C2=A0Regards
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Brian
>
>=C2=A0 =C2=A0 =C2=A0On 05/05/2016 03:26, Black, David wrote:
>=C2=A0 =C2=A0 =C2=A0> Greetings,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I write as the shepherd for the WebRTC QoS dra= ft (draft-ietf-tsvwg-rtcweb-qos).
>=C2=A0 =C2=A0 =C2=A0> IETF Last Call on this draft uncovered an issu= e that appears to also require
>=C2=A0 =C2=A0 =C2=A0> changes in the Web RTC transports draft (draft= -ietf-rtcweb-transports).
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The Web RTC draft=C2=A0 specifies different Di= ffserv Codepoints (DSCPs) for use with
>=C2=A0 =C2=A0 =C2=A0> Interactive vs. Non-Interactive Video (with or= without audio in both cases):
>=C2=A0 =C2=A0 =C2=A0> htt= ps://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-5
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The IETF LC issue is: How does an implementer = determine whether video is
>=C2=A0 =C2=A0 =C2=A0> interactive vs. non-interactive?
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The answer (unexpected to at least me) is that= this can't be done for current
>=C2=A0 =C2=A0 =C2=A0> WebRTC - all video has to be treated as intera= ctive because there's no API
>=C2=A0 =C2=A0 =C2=A0> support to distinguish interactive video from = non-interactive video.=C2=A0 That
>=C2=A0 =C2=A0 =C2=A0> doesn't appear to be stated anywhere obvio= us, and a TSVWG draft seems
>=C2=A0 =C2=A0 =C2=A0> like the wrong place to do so.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Hence, this message contains initial proposed = changes to both the WebRTC
>=C2=A0 =C2=A0 =C2=A0> Transports draft and WebRTC QoS draft to resol= ve this issue without removing
>=C2=A0 =C2=A0 =C2=A0> any of the DSCPs currently specified for video= in the WebRTC QoS draft.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> We should resolve this within the next few day= s, as the WebRTC QoS draft is
>=C2=A0 =C2=A0 =C2=A0> (finally!) on the IESG telechat agenda for May= 19.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> --- WebRTC Transports draft - proposed changes=
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> In Section 4 Media Prioritization, after the f= ollowing existing text:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 For media, a "media flow&quo= t;, which can be an "audio flow" or a "video
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 flow", is what [RFC7656] cal= ls a "media source", which results in a
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 "source RTP stream" and= one or more "redundancy RTP streams".=C2=A0 This
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 specification does not describe p= rioritization between the RTP
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 streams that come from a single &= quot;media source".
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Add a new paragraph:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 All media flows in WebRTC are ass= umed to be interactive; there is
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 no browser API support for non-in= teractive media, aside from sending
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 non-interactive media content via= the data channel.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> This ought to cite a W3C reference for the Web= RTC API - the following
>=C2=A0 =C2=A0 =C2=A0> appears plausible:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 [W3C.WD-webrtc-20120209]
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Bergkvist, A., Burnett, D., Jennings, C., and A.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Narayanan, "WebRTC 1.0: Real-time Communication Between
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Browsers", World Wide Web Consortium WD WD-webrtc-
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A020120209, February 2012,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0<http://www.w3.org/TR/2012/WD-webrtc-20120= 209>.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> -- WebRTC QoS draft - proposed changes
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> In Section 5 DSCP Mappings, after the followin= g existing text:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 The browser SHOULD first select t= he flow type of the flow.=C2=A0 Within
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 the flow type, the relative impor= tance of the flow SHOULD be used to
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 select the appropriate DSCP value= .
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Add a new paragraph:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 The current WebRTC browser API do= es not support non-interactive
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 video; all video is assumed to be= interactive [I-D.ietf-rtcweb-transports].
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 Browsers MUST NOT use the DSCP ma= ppings for Non-Interactive Video
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 in Table 1.=C2=A0 Non-browser imp= lementations of WebRTC MAY use the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 DSCP mappings for Non-Interactive= Video in Table 1 for video that is
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 known to not be interactive, e.g.= , all video in a video playback application
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 based on a custom implementation = of the WebRTC protocols would not
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 be interactive.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> ------
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Comments are welcome - as noted, above,=C2=A0 = we should resolve this in
>=C2=A0 =C2=A0 =C2=A0> the next few days in order to avoid pulling th= e WebRTC QoS draft off
>=C2=A0 =C2=A0 =C2=A0> of the May 19 IESG telechat agenda. Please rep= ly to both the TSVWG and
>=C2=A0 =C2=A0 =C2=A0> RTCWEB lists, as we need=C2=A0 a coherent solu= tion across both drafts.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I want to thank Colin Perkins for suggesting t= he video playback example.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Thanks, --David (as WebRTC QoS draft shepherd)=
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0rtcweb mailing list
>=C2=A0 =C2=A0 =C2=A0rtcw= eb@ietf.org <mailto:rtcweb@ietf.o= rg>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/lis= tinfo/rtcweb
>
>

--94eb2c12541800d71f05320e7161-- From nobody Wed May 4 21:30:19 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E90912D533; Wed, 4 May 2016 21:30:17 -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 pRaj81GZeLnF; Wed, 4 May 2016 21:30:14 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::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 A985212D0A6; Wed, 4 May 2016 21:30:14 -0700 (PDT) Received: by mail-pa0-x22d.google.com with SMTP id r5so32493151pag.1; Wed, 04 May 2016 21:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=dtKHShRCIb6vCkY+ZkdcFhmnYARUweuYJ92yOZlpTBM=; b=adlShSlxjSBB6XebmSFweW6IMnv7Yu2NOFPlSaHHM8bzZPi2BrSf544tktbaYgsp1Z yb8raZ/vGzgstu7HbBDvqfrvAwo5ZzCTFo9CTnhkRn1LTcAm6K29uNqqZROlB9I7g5ER RULjcdpsotAq2lnBRNS20zreMqs08feMQLJuJZWoSjPijQLJ/cJcuP3CAQZ7GFDGvUBF 7HloPYDMd1obW3qI9jLW3rzeSDVu1vh5e740d11SO7cyrBEcbQSdAyARu/O647Ftejeg 044uiFZQYTGoxUErf3GSxNdWLTd3sEesAXXwjjGSbrBoknxtfhxJKzLS93yVqIWazsV5 G3CQ== 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:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=dtKHShRCIb6vCkY+ZkdcFhmnYARUweuYJ92yOZlpTBM=; b=bj8UzaI4cd5dInNoZaacYrwuFbpQo6lsByFG5jDG+jdZ9FvDkXBwqD+V7e/qqWyMqT B9Z8kH3DHtAYkkzCZikfm7uF9x0mtQY2xXry5g6azBYAqGcrpgFNRZGUAraOPA7jfoIb 2Iqdo3f2w4sT1QD3e6z59U10Syc2Dj36BUPP8RndfkfuKIk7M6Vpyow5L3VnC4l7MRdb BC/PD5GC3QtD6p1tAFTvbTiqLCHLI+EUAQpDCMGxLnPeHNr+THGt+wGKM9z1DvOvatyg 2sQu6jaf3kmbiV88m7I5qzP+ehAH3kC5d3EmVbcF25EZuvR4DFcCBKaCIMWQDseUARQK CqAg== X-Gm-Message-State: AOPr4FVTTzFeYEBKvnlu5SzBLKVC5qZ/tJV8GzGz/a8I6rZDI1n+o/kix4hh3l4T98mbKw== X-Received: by 10.66.230.195 with SMTP id ta3mr17529343pac.150.1462422614203; Wed, 04 May 2016 21:30:14 -0700 (PDT) Received: from ?IPv6:2406:e007:5671:1:28cc:dc4c:9703:6781? ([2406:e007:5671:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id w187sm9565402pfw.50.2016.05.04.21.30.10 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2016 21:30:12 -0700 (PDT) To: Bernard Aboba References: <7ebc2ca5-c10f-f85e-2b6f-0d685c87f187@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <94d47bb7-3d58-5d3c-1c4d-06840d172b79@gmail.com> Date: Thu, 5 May 2016 16:30:17 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "Black, David" , "rtcweb@ietf.org" , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] Diffserv QoS for Video 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, 05 May 2016 04:30:17 -0000 > To my mind, the real > question is whether a "non-interactive" marking/priority would deliver > anything useful to application developers, Absolutely. As I understand things, a media stream in an interactive session has one requirement that is definitely more stringent than for a non-interactive session: lower latency. So the question is how to ensure that the most suitable DSCP is chosen to achieve the required latency. But that takes us back to https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-5 where by some magic the code needs to know the flow type. This is why trying to compress the subtleties of QoS into a "priority" parameter is bound to fail. I don't understand how https://tools.ietf.org/html/draft-ietf-rtcweb-transports-12#section-4.2 is going to work without extending the API. Regards Brian On 05/05/2016 13:41, Bernard Aboba wrote: > Brian said: > > "All the same, I think the phrasing I quoted at > https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-4 > is problematic; it implies that there's a Boolean property "interactive" > which clearly is not supported in the encoding parameters." > > [BA] Overall, I'm not clear that this thread is asking the right questions, > or making correct statements about the existing API. To my mind, the real > question is whether a "non-interactive" marking/priority would deliver > anything useful to application developers, not whether the API could > support it. > > The encoding parameters can be used to allow an application to specify a > priority attribute. If a "non-interactive" marking and associated priority > attribute were to be defined, the current API could allow applications to > specify that. So citing a 4-year old version of the WebRTC 1.0 > specification as justification for the lack of API functionality doesn't > make sense to me. Since the browser just does what it is told to do by > the application, whether the browser "knows" whether the media is > interactive or not also does not matter. > > The real question is whether a "non-interactive" marking/priority setting > would be useful to application developers. > > Uni-directional communications (e.g. "sendonly", "recvonly") is supported > within WebRTC. Would those kind of flows benefit from a "non-interactive" > marking? In most cases, I suspect that in general it would not be useful (a > possible exception might be use of SVC codecs protecting only the base > layer with FEC/RTX). > > It is conceivable that an application might want to attach a track to a > sender that isn't obtained from getUserMedia() (see: > http://w3c.github.io/mediacapture-main/) or getDisplayMedia() (see > https://w3c.github.io/mediacapture-screen-share/). Again, the question is > whether a "non-interactive" marking/priority would be helpful in those > cases. I suspect the answer to that is also "no" for similar reasons. > > On Wed, May 4, 2016 at 5:36 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> Thanks Bernard. >> >> All the same, I think the phrasing I quoted at >> https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-4 >> is problematic; it implies that there's a Boolean property "interactive" >> which clearly is not supported in the encoding parameters. >> >> Regards >> Brian >> >> On 05/05/2016 11:01, Bernard Aboba wrote: >>> Brian Carpenter said: >>> >>> "Then, is it clear how the browser "knows" this?" >>> >>> [BA] The application explicitly provides information to the browser by >> setting the RTCRtpEncodingParameters.priority attribute >>> via the sender.setParameters() API: >>> >>> dictionary RTCRtpEncodingParameters { unsigned long ssrc < >> http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-ssrc>; >>> |RTCRtpRtxParameters| rtx < >> http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-rtx>; >> |RTCRtpFecParameters| fec >>> ; >> boolean active >>> ; >> |RTCPriorityType| priority >>> ; >> unsigned long maxBitrate >>> < >> http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-maxBitrate>; >> unsigned long maxFramerate >>> < >> http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-maxFramerate>; >> DOMString rid >>> ; >> double scaleResolutionDownBy >>> < >> http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-scaleResolutionDownBy> >> = 1.0; }; >>> >>> >>> The Priority and QoS Model is described in the latest WebRTC 1.0 >> Editor's draft (http://w3c.github.io/webrtc-pc/) Section 4.10: >>> >>> 4.10 Priority and QoS Model >>> >>> Many applications have multiple media flows of the same data type and >> often some of the flows are more important than others. >>> WebRTC uses the priority and Quality of Service (QoS) framework >> described in [RTCWEB-TRANSPORT] and [TSVWG-RTCWEB-QOS] to >>> provide priority and DSCP marking for packets that will help provide QoS >> in some networking environments. The priority setting >>> can be used to indicate the relative priority of various flows. The >> priority API allows the JavaScript applications to tell the >>> browser whether a particular media flow is high, medium, low or of very >> low importance to the application by setting >>> the |priority|property of ||RTCRtpEncodingParameters|| objects to one of >> the following values. >>> >>> >>> 4.10.1 RTCPriorityType Enum >>> >>> >>> enum RTCPriorityType { >>> "very-low < >> http://w3c.github.io/webrtc-pc/#idl-def-RTCPriorityType.very-low>", >>> "low ", >>> "medium < >> http://w3c.github.io/webrtc-pc/#idl-def-RTCPriorityType.medium>", >>> "high >> " >>> }; >>> >>> >>> On Wed, May 4, 2016 at 1:28 PM, Brian E Carpenter < >> brian.e.carpenter@gmail.com > wrote: >>> >>> I fear I have an up-level question: what is the definition of >> "interactive"? >>> >>> draft-ietf-tsvwg-rtcweb-qos doesn't define it, presumably because it >> was >>> assumed to be obvious, but thinking about David's suggestions, I >> decided >>> that it isn't so obvious. >>> >>> https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-4 >> says: >>> >>> The following are the inputs provided by the WebRTC application to >>> the browser: >>> >>> o Flow Type: The browser provides this input as it knows if the >> flow >>> is audio, interactive video with or without audio, >> non-interactive >>> video with or without audio, or data. >>> >>> Firstly, I'm puzzled by the apparent contradiction between the first >>> sentence (in which the app provides input to the browser) and the >> second >>> sentence (in which to the browser provides input to something else). >>> >>> Then, is it clear how the browser "knows" this? If David's statement >> below >>> about the API is correct, the browser actually cannot "provide this >> input" >>> as stated in the above quotation. Or I am confused. >>> >>> Finally, why is audio not also subdivided into interactive and >>> non-interactive? As far as I can see, both are logically possible. >>> >>> Regards >>> Brian >>> >>> On 05/05/2016 03:26, Black, David wrote: >>> > Greetings, >>> > >>> > I write as the shepherd for the WebRTC QoS draft >> (draft-ietf-tsvwg-rtcweb-qos). >>> > IETF Last Call on this draft uncovered an issue that appears to >> also require >>> > changes in the Web RTC transports draft >> (draft-ietf-rtcweb-transports). >>> > >>> > The Web RTC draft specifies different Diffserv Codepoints (DSCPs) >> for use with >>> > Interactive vs. Non-Interactive Video (with or without audio in >> both cases): >>> > >> https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-5 >>> > >>> > The IETF LC issue is: How does an implementer determine whether >> video is >>> > interactive vs. non-interactive? >>> > >>> > The answer (unexpected to at least me) is that this can't be done >> for current >>> > WebRTC - all video has to be treated as interactive because >> there's no API >>> > support to distinguish interactive video from non-interactive >> video. That >>> > doesn't appear to be stated anywhere obvious, and a TSVWG draft >> seems >>> > like the wrong place to do so. >>> > >>> > Hence, this message contains initial proposed changes to both the >> WebRTC >>> > Transports draft and WebRTC QoS draft to resolve this issue >> without removing >>> > any of the DSCPs currently specified for video in the WebRTC QoS >> draft. >>> > >>> > We should resolve this within the next few days, as the WebRTC QoS >> draft is >>> > (finally!) on the IESG telechat agenda for May 19. >>> > >>> > --- WebRTC Transports draft - proposed changes >>> > >>> > In Section 4 Media Prioritization, after the following existing >> text: >>> > >>> > For media, a "media flow", which can be an "audio flow" or a >> "video >>> > flow", is what [RFC7656] calls a "media source", which results >> in a >>> > "source RTP stream" and one or more "redundancy RTP streams". >> This >>> > specification does not describe prioritization between the RTP >>> > streams that come from a single "media source". >>> > >>> > Add a new paragraph: >>> > >>> > All media flows in WebRTC are assumed to be interactive; there >> is >>> > no browser API support for non-interactive media, aside from >> sending >>> > non-interactive media content via the data channel. >>> > >>> > This ought to cite a W3C reference for the WebRTC API - the >> following >>> > appears plausible: >>> > >>> > [W3C.WD-webrtc-20120209] >>> > Bergkvist, A., Burnett, D., Jennings, C., and A. >>> > Narayanan, "WebRTC 1.0: Real-time Communication >> Between >>> > Browsers", World Wide Web Consortium WD WD-webrtc- >>> > 20120209, February 2012, >>> > . >>> > >>> > -- WebRTC QoS draft - proposed changes >>> > >>> > In Section 5 DSCP Mappings, after the following existing text: >>> > >>> > The browser SHOULD first select the flow type of the flow. >> Within >>> > the flow type, the relative importance of the flow SHOULD be >> used to >>> > select the appropriate DSCP value. >>> > >>> > Add a new paragraph: >>> > >>> > The current WebRTC browser API does not support non-interactive >>> > video; all video is assumed to be interactive >> [I-D.ietf-rtcweb-transports]. >>> > Browsers MUST NOT use the DSCP mappings for Non-Interactive >> Video >>> > in Table 1. Non-browser implementations of WebRTC MAY use the >>> > DSCP mappings for Non-Interactive Video in Table 1 for video >> that is >>> > known to not be interactive, e.g., all video in a video >> playback application >>> > based on a custom implementation of the WebRTC protocols would >> not >>> > be interactive. >>> > >>> > ------ >>> > >>> > Comments are welcome - as noted, above, we should resolve this in >>> > the next few days in order to avoid pulling the WebRTC QoS draft >> off >>> > of the May 19 IESG telechat agenda. Please reply to both the TSVWG >> and >>> > RTCWEB lists, as we need a coherent solution across both drafts. >>> > >>> > I want to thank Colin Perkins for suggesting the video playback >> example. >>> > >>> > Thanks, --David (as WebRTC QoS draft shepherd) >>> > >>> > >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >> > From nobody Thu May 5 04:02: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 2D66212D13A; Thu, 5 May 2016 04:02:43 -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 BEB0JWUeAbpS; Thu, 5 May 2016 04:02:38 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87F0112B048; Thu, 5 May 2016 04:02:37 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-a9-572b284acdbf Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 2F.00.27088.A482B275; Thu, 5 May 2016 13:02:34 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0248.002; Thu, 5 May 2016 13:02:34 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Brian E Carpenter , "Black, David" , "tsvwg@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] [tsvwg] Diffserv QoS for Video Thread-Index: AdGmGT33m8jIoXrlTv+NljAQLxjzlw== Date: Thu, 5 May 2016 11:02:33 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B375232B2@ESESSMB209.ericsson.se> References: <7ebc2ca5-c10f-f85e-2b6f-0d685c87f187@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGbHdRtdLQzvcYP9ceYu2i/uYLLYeXstu sfZfO7vFsTd32RxYPI4cmc3isXPWXXaPJUt+MgUwR3HZpKTmZJalFunbJXBlfJo/haVgs1FF 9695jA2MHRpdjJwcEgImEsf/L2eHsMUkLtxbz9bFyMUhJHCEUeL2ryeMEM5iRomti9pZQKrY BAIltu5bAFYlIrCUUWLbuglg7cJAo07uvMcGYosImErsuj6dGcLWk5j3exJYDYuAisTatnlg cV4BX4lTh1ZBrWtglJgxt48RJMEIdMf3U2uYQGxmAXGJW0/mM0HcJyCxZM95ZghbVOLl43+s ELaSxNrD21kg6vUkbkydwgZha0ssW/gaapmgxMmZT1gmMIrMQjJ2FpKWWUhaZiFpWcDIsopR tDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMGYObvltsIPx5XPHQ4wCHIxKPLwKK7XChVgTy4or cw8xSnAwK4nwMqpqhwvxpiRWVqUW5ccXleakFh9ilOZgURLn9X+pGC4kkJ5YkpqdmlqQWgST ZeLglGpg5HFbVqBg6D7Nt0Lh9cmcCTLOnzLj+zsTFk3efENm3qTnCe7nY7iNT50+KcDvUyN/ q3/CUc3tLhzpaW837f6buVs6dXPJx5y9UekGTzjUXxRvXbtUZr2QnV/TUmPvtKOXXDfkhHuo LLFaaRzPd3PF59odd05cOaWTs2zP908qJy873H4kIjRlsxJLcUaioRZzUXEiABKTL+qVAgAA Archived-At: Subject: Re: [rtcweb] [tsvwg] Diffserv QoS for Video 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, 05 May 2016 11:02:43 -0000 On 04/05/16 22:28, Brian E Carpenter wrote:=0A= > I fear I have an up-level question: what is the definition of "interactiv= e"?=0A= >=0A= > draft-ietf-tsvwg-rtcweb-qos doesn't define it, presumably because it was= =0A= > assumed to be obvious, but thinking about David's suggestions, I decided= =0A= > that it isn't so obvious.=0A= >=0A= > https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-4 says= :=0A= >=0A= > The following are the inputs provided by the WebRTC application to=0A= > the browser:=0A= >=0A= > o Flow Type: The browser provides this input as it knows if the flow= =0A= > is audio, interactive video with or without audio, non-interactive= =0A= > video with or without audio, or data.=0A= >=0A= > Firstly, I'm puzzled by the apparent contradiction between the first=0A= > sentence (in which the app provides input to the browser) and the second= =0A= > sentence (in which to the browser provides input to something else).=0A= =0A= The sentences contradict, but with the API defined the second sentence =0A= is true.=0A= =0A= >=0A= > Then, is it clear how the browser "knows" this? If David's statement belo= w=0A= > about the API is correct, the browser actually cannot "provide this input= "=0A= > as stated in the above quotation. Or I am confused.=0A= =0A= There is no browser API to define if the video (or audio) is interactive = =0A= or not, and the reason is that we've dealt only with interactive flows.=0A= =0A= I've heard people talk about more robust flows with higher latency for =0A= situations like lectures and so on, but that is not part of WebRTC 1.0 =0A= (the API standard).=0A= =0A= >=0A= > Finally, why is audio not also subdivided into interactive and=0A= > non-interactive? As far as I can see, both are logically possible.=0A= >=0A= > Regards=0A= > Brian=0A= >=0A= > On 05/05/2016 03:26, Black, David wrote:=0A= >> Greetings,=0A= >>=0A= >> I write as the shepherd for the WebRTC QoS draft (draft-ietf-tsvwg-rtcwe= b-qos).=0A= >> IETF Last Call on this draft uncovered an issue that appears to also req= uire=0A= >> changes in the Web RTC transports draft (draft-ietf-rtcweb-transports).= =0A= >>=0A= >> The Web RTC draft specifies different Diffserv Codepoints (DSCPs) for u= se with=0A= >> Interactive vs. Non-Interactive Video (with or without audio in both cas= es):=0A= >> https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-5=0A= >>=0A= >> The IETF LC issue is: How does an implementer determine whether video is= =0A= >> interactive vs. non-interactive?=0A= >>=0A= >> The answer (unexpected to at least me) is that this can't be done for cu= rrent=0A= >> WebRTC - all video has to be treated as interactive because there's no A= PI=0A= >> support to distinguish interactive video from non-interactive video. Th= at=0A= >> doesn't appear to be stated anywhere obvious, and a TSVWG draft seems=0A= >> like the wrong place to do so.=0A= >>=0A= >> Hence, this message contains initial proposed changes to both the WebRTC= =0A= >> Transports draft and WebRTC QoS draft to resolve this issue without remo= ving=0A= >> any of the DSCPs currently specified for video in the WebRTC QoS draft.= =0A= >>=0A= >> We should resolve this within the next few days, as the WebRTC QoS draft= is=0A= >> (finally!) on the IESG telechat agenda for May 19.=0A= >>=0A= >> --- WebRTC Transports draft - proposed changes=0A= >>=0A= >> In Section 4 Media Prioritization, after the following existing text:=0A= >>=0A= >> For media, a "media flow", which can be an "audio flow" or a "video= =0A= >> flow", is what [RFC7656] calls a "media source", which results in a= =0A= >> "source RTP stream" and one or more "redundancy RTP streams". This= =0A= >> specification does not describe prioritization between the RTP=0A= >> streams that come from a single "media source".=0A= >>=0A= >> Add a new paragraph:=0A= >>=0A= >> All media flows in WebRTC are assumed to be interactive; there is=0A= >> no browser API support for non-interactive media, aside from sending= =0A= >> non-interactive media content via the data channel.=0A= >>=0A= >> This ought to cite a W3C reference for the WebRTC API - the following=0A= >> appears plausible:=0A= >>=0A= >> [W3C.WD-webrtc-20120209]=0A= >> Bergkvist, A., Burnett, D., Jennings, C., and A.=0A= >> Narayanan, "WebRTC 1.0: Real-time Communication Between= =0A= >> Browsers", World Wide Web Consortium WD WD-webrtc-=0A= >> 20120209, February 2012,=0A= >> .=0A= >>=0A= >> -- WebRTC QoS draft - proposed changes=0A= >>=0A= >> In Section 5 DSCP Mappings, after the following existing text:=0A= >>=0A= >> The browser SHOULD first select the flow type of the flow. Within= =0A= >> the flow type, the relative importance of the flow SHOULD be used to= =0A= >> select the appropriate DSCP value.=0A= >>=0A= >> Add a new paragraph:=0A= >>=0A= >> The current WebRTC browser API does not support non-interactive=0A= >> video; all video is assumed to be interactive [I-D.ietf-rtcweb-trans= ports].=0A= >> Browsers MUST NOT use the DSCP mappings for Non-Interactive Video=0A= >> in Table 1. Non-browser implementations of WebRTC MAY use the=0A= >> DSCP mappings for Non-Interactive Video in Table 1 for video that is= =0A= >> known to not be interactive, e.g., all video in a video playback app= lication=0A= >> based on a custom implementation of the WebRTC protocols would not= =0A= >> be interactive.=0A= >>=0A= >> ------=0A= >>=0A= >> Comments are welcome - as noted, above, we should resolve this in=0A= >> the next few days in order to avoid pulling the WebRTC QoS draft off=0A= >> of the May 19 IESG telechat agenda. Please reply to both the TSVWG and= =0A= >> RTCWEB lists, as we need a coherent solution across both drafts.=0A= >>=0A= >> I want to thank Colin Perkins for suggesting the video playback example.= =0A= >>=0A= >> Thanks, --David (as WebRTC QoS draft shepherd)=0A= >>=0A= >>=0A= >=0A= > _______________________________________________=0A= > rtcweb mailing list=0A= > rtcweb@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= =0A= From nobody Thu May 5 10:47:23 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 EA5C812D6E7; Thu, 5 May 2016 10:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, 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=packetizer.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 98-pt3gp6QlH; Thu, 5 May 2016 10:47:16 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 A333812D1DA; Thu, 5 May 2016 10:47:16 -0700 (PDT) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u45HlCc0014379 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 May 2016 13:47:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1462470433; bh=P5mnqPL/9iEJyk8DBffLQ+DjsH9qoVHT128uBOge7H0=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=qb7nOo9g8SwnDZLFpDU+cP5NMmUiiqCFaxxsUVm7Ea2GrJkT7JMCNWp3MWSMVD2G5 7oAfvWvHN6qnfHMh/zmmZ/h3962yVDRacfxtMhiIMqRhrevqsymRhnRjjcXbPKDafK eJD5E3+DzVATXJGPb7lx5iQ5q52PUo50P96Zp4vo= From: "Paul E. Jones" To: "Brian E Carpenter" , "Black, David" , "tsvwg@ietf.org" , "rtcweb@ietf.org" Date: Thu, 05 May 2016 17:47:24 +0000 Message-Id: In-Reply-To: <7ebc2ca5-c10f-f85e-2b6f-0d685c87f187@gmail.com> User-Agent: eM_Client/6.0.24928.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.16 (dublin.packetizer.com [10.137.60.122]); Thu, 05 May 2016 13:47:13 -0400 (EDT) Archived-At: Subject: Re: [rtcweb] [tsvwg] Diffserv QoS for Video X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Paul E. Jones" List-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, 05 May 2016 17:47:19 -0000 Brian, >I fear I have an up-level question: what is the definition of=20 >"interactive"? That comes from RFC 4594, which comes from G.1010. >draft-ietf-tsvwg-rtcweb-qos doesn't define it, presumably because it=20 >was >assumed to be obvious, but thinking about David's suggestions, I=20 >decided >that it isn't so obvious. > >https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-4=20 >says: > > The following are the inputs provided by the WebRTC application to > the browser: > > o Flow Type: The browser provides this input as it knows if the=20 >flow > is audio, interactive video with or without audio,=20 >non-interactive > video with or without audio, or data. This paragraph has been modified during the course of discussions during= =20 LC. The text now reads: Flow Type: The application provides this input because it knows if the flow is audio, interactive video with or without audio, non-interactive video with or without audio, or data. For audio that is associated with a video flow, the flow type of the associated video MAY be used instead of the associated audio type. >Firstly, I'm puzzled by the apparent contradiction between the first >sentence (in which the app provides input to the browser) and the=20 >second >sentence (in which to the browser provides input to something else). This should have been "application", as it's providing this input to the= =20 browser, in spite of the fact that the current API does not allow the=20 application to indicate interactive or not. >Then, is it clear how the browser "knows" this? If David's statement=20 >below >about the API is correct, the browser actually cannot "provide this=20 >input" >as stated in the above quotation. Or I am confused. Yeah, the browser would not know. At present, it can only assume it's=20 interactive based on the fact it is an RTP video and audio flow. >Finally, why is audio not also subdivided into interactive and >non-interactive? As far as I can see, both are logically possible. For WebRTC, audio alone is "interactive" in nature (which is why it's=20 marked EF). However, if one is sending audio and video it makes sense=20 to mark them both same way to get the same PHB and hopefully have them=20 queued in the same buffers along the path. Sending audio as EF and=20 possibly having a PHB that results in packets arriving much faster than=20 corresponding video packets marked as AF42 is not at all helpful for=20 applications that have to synchronize the audio and video flows. I can think of examples of potentially non-interactive video (e.g.,=20 whiteboard, app sharing, or presentation video). Likewise, if audio is=20 sent with a presentation video it would make sense for the audio to be=20 marked similarly to the corresponding video. Paul From nobody Thu May 5 13:21:40 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 C105512D119; Thu, 5 May 2016 13:21:36 -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.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160505202136.26807.21954.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2016 13:21:36 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-alpn-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 20:21:37 -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-04.txt Pages : 7 Date : 2016-05-05 Abstract: This document specifies two Application Layer Protocol Negotiation (ALPN) labels for use with Web Real-Time Communications (WebRTC). The "webrtc" label identifies regular WebRTC communications: a DTLS session that is used establish keys for Secure Real-time Transport Protocol (SRTP) or to establish data channels using SCTP over DTLS. The "c-webrtc" label describes the same protocol, but the peers also agree to maintain the confidentiality of the media by not sharing it with other 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-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-alpn-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 6 09:41: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 1EE7A12D13A; Fri, 6 May 2016 09:41:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160506164126.26301.71310.idtracker@ietfa.amsl.com> Date: Fri, 06 May 2016 09:41:26 -0700 Archived-At: Cc: rtcweb@ietf.org, rtcweb-chairs@ietf.org Subject: [rtcweb] rtcweb - New Meeting Session Request for IETF 96 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, 06 May 2016 16:41:26 -0000 A new meeting session request has just been submitted by Ted Hardie, a Chair of the rtcweb working group. --------------------------------------------------------- Working Group Name: Real-Time Communication in WEB-browsers Area Name: Applications and Real-Time Area Session Requester: Ted Hardie Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 100 Conflicts to Avoid: First Priority: tls rmcat aqm avtcore avtext clue dispatch httpbis stir acme mmusic payload sipcore perc Second Priority: dprive tcpinc straw tsvwg tsvarea ace uta netvc capport Third Priority: insipid irtfopen ianaplan dane opsawg Special Requests: There are two possible BoFs that we need to add as First priority conflicts: SPUD and QUIC (if approved). thanks, Ted --------------------------------------------------------- From nobody Fri May 6 18:13:54 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC3912D0AE; Fri, 6 May 2016 18:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.317 X-Spam-Level: X-Spam-Status: No, score=-5.317 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 tga4pdJJ1KlF; Fri, 6 May 2016 18:13:49 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 BB17812B014; Fri, 6 May 2016 18:13:48 -0700 (PDT) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u471DkBn024318 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 May 2016 21:13:47 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u471DkBn024318 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1462583627; bh=kBVxpHyXiNlH0R3f6sfsICm1gUM=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=PPERISL2ROAYHVat3Aiod3fJ8lpR6IhpJ/O48MIhnbqsZFdNWGmvrovvFE0Pbb65E 0OAeQ+n31ba1+be3UI06h0+SfiIooHr/iXOv2MZGyGFSqHrb0VNeYx832RClNyPfWj 29e+TK8R1vHmggYDflK/cJNI5mbV7Pi6kgYeX8EQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u471DkBn024318 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd53.lss.emc.com (RSA Interceptor); Fri, 6 May 2016 21:13:23 -0400 Received: from MXHUB220.corp.emc.com (MXHUB220.corp.emc.com [10.253.68.90]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u471DU0F014832 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 6 May 2016 21:13:30 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.9]) by MXHUB220.corp.emc.com ([10.253.68.90]) with mapi id 14.03.0266.001; Fri, 6 May 2016 21:13:30 -0400 From: "Black, David" To: "tsvwg@ietf.org" , "rtcweb@ietf.org" Thread-Topic: Diffserv QoS for Video - summary Thread-Index: AdGn/aTXCbReDyBzSX2UbV32jIffJg== Date: Sat, 7 May 2016 01:13:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.35.178] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Black, David" Subject: [rtcweb] Diffserv QoS for Video - summary 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, 07 May 2016 01:13:51 -0000 Many thanks for the productive comments - I'm replying to my own message in= an attempt to summarize the discussion and what ought to be done to the dr= afts as a result. -- [A] Brian Carpenter asked: what is the definition of "interactive"? Paul Jones answered: from RFC 4594, which comes from G.1010. IMHO, both drafts should cite RFC 4594 and G.1010 for this discussion and d= efinition. -- [B] Brian Carpenter asked about whether the WebRTC API supports a parame= ter to distinguish interactive video from non-interactive video. The definitive answer from a number of sources (e.g., Stefan H=E5kansson) i= s "No." There is additional text in the tsvwg-rtcweb-qos draft that will = need to be revised to align with this answer (e.g., for WebRTC, there is no= input to the browser to distinguish interactive vs. non-interactive video = and the browser SHOULD NOT try to do so on its own). -- [C] Bernard Aboba wondered whether a "non-interactive" marking/priority= would deliver anything useful to application developers independent of whe= ther or not it's supported in the WebRTC API.. My perception is that the answer here is "Yes" which leads to leaving the N= on-Interactive Video flow type in the tsvwg-rtcweb-qos draft, but making it= clear that use of Web RTC via the browser API currently does not (and cann= ot) use that flow type. -- [D] Finally, Brian Carpenter asked about non-interactive audio: Finally, why is audio not also subdivided into interactive and non-interactive? As far as I can see, both are logically possible. I believe the answer is a lack of interest combined with absence of support= in WebRTC "running code". Further comments? Absent further discussion, I'll work offline with the draft authors on text= changes for both drafts in accordance with this summary. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Wednesday, May 04, 2016 11:26 AM > To: tsvwg@ietf.org; rtcweb@ietf.org > Cc: Black, David > Subject: Diffserv QoS for Video >=20 > Greetings, >=20 > I write as the shepherd for the WebRTC QoS draft (draft-ietf-tsvwg-rtcweb= -qos). > IETF Last Call on this draft uncovered an issue that appears to also requ= ire > changes in the Web RTC transports draft (draft-ietf-rtcweb-transports). >=20 > The Web RTC draft specifies different Diffserv Codepoints (DSCPs) for us= e with > Interactive vs. Non-Interactive Video (with or without audio in both case= s): > https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-5 >=20 > The IETF LC issue is: How does an implementer determine whether video is > interactive vs. non-interactive? >=20 > The answer (unexpected to at least me) is that this can't be done for cur= rent > WebRTC - all video has to be treated as interactive because there's no AP= I > support to distinguish interactive video from non-interactive video. Tha= t > doesn't appear to be stated anywhere obvious, and a TSVWG draft seems > like the wrong place to do so. >=20 > Hence, this message contains initial proposed changes to both the WebRTC > Transports draft and WebRTC QoS draft to resolve this issue without remov= ing > any of the DSCPs currently specified for video in the WebRTC QoS draft. >=20 > We should resolve this within the next few days, as the WebRTC QoS draft = is > (finally!) on the IESG telechat agenda for May 19. >=20 > --- WebRTC Transports draft - proposed changes >=20 > In Section 4 Media Prioritization, after the following existing text: >=20 > For media, a "media flow", which can be an "audio flow" or a "video > flow", is what [RFC7656] calls a "media source", which results in a > "source RTP stream" and one or more "redundancy RTP streams". This > specification does not describe prioritization between the RTP > streams that come from a single "media source". >=20 > Add a new paragraph: >=20 > All media flows in WebRTC are assumed to be interactive; there is > no browser API support for non-interactive media, aside from sending > non-interactive media content via the data channel. >=20 > This ought to cite a W3C reference for the WebRTC API - the following > appears plausible: >=20 > [W3C.WD-webrtc-20120209] > Bergkvist, A., Burnett, D., Jennings, C., and A. > Narayanan, "WebRTC 1.0: Real-time Communication Between > Browsers", World Wide Web Consortium WD WD-webrtc- > 20120209, February 2012, > . >=20 > -- WebRTC QoS draft - proposed changes >=20 > In Section 5 DSCP Mappings, after the following existing text: >=20 > The browser SHOULD first select the flow type of the flow. Within > the flow type, the relative importance of the flow SHOULD be used to > select the appropriate DSCP value. >=20 > Add a new paragraph: >=20 > The current WebRTC browser API does not support non-interactive > video; all video is assumed to be interactive [I-D.ietf-rtcweb-transpo= rts]. > Browsers MUST NOT use the DSCP mappings for Non-Interactive Video > in Table 1. Non-browser implementations of WebRTC MAY use the > DSCP mappings for Non-Interactive Video in Table 1 for video that is > known to not be interactive, e.g., all video in a video playback appli= cation > based on a custom implementation of the WebRTC protocols would not > be interactive. >=20 > ------ >=20 > Comments are welcome - as noted, above, we should resolve this in > the next few days in order to avoid pulling the WebRTC QoS draft off > of the May 19 IESG telechat agenda. Please reply to both the TSVWG and > RTCWEB lists, as we need a coherent solution across both drafts. >=20 > I want to thank Colin Perkins for suggesting the video playback example. >=20 > Thanks, --David (as WebRTC QoS draft shepherd) From nobody Mon May 9 00:36:44 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D21E12D09B; Mon, 9 May 2016 00:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 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, 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 2D4395CK725V; Mon, 9 May 2016 00:36:39 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5658B12B067; Mon, 9 May 2016 00:36:38 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail41.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 09 May 2016 09:36:13 +0200 X-IronPort-AV: E=Sophos;i="5.24,600,1454972400"; d="scan'208";a="452103119" Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 09 May 2016 09:34:27 +0200 Received: from HE111642.emea1.cds.t-internal.com ([10.134.93.11]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 9 May 2016 09:34:25 +0200 From: To: Date: Mon, 9 May 2016 09:34:25 +0200 Thread-Topic: [tsvwg] Diffserv QoS for Video Thread-Index: AdGm9jIMXNj2btk+TaWuaehCfFfCHgCy88OQ Message-ID: <828773FE19B05B4581311493A046E85E6ECC3084D0@HE111642.emea1.cds.t-internal.com> References: <7ebc2ca5-c10f-f85e-2b6f-0d685c87f187@gmail.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: david.black@emc.com, rtcweb@ietf.org, brian.e.carpenter@gmail.com, tsvwg@ietf.org Subject: Re: [rtcweb] [tsvwg] Diffserv QoS for Video 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, 09 May 2016 07:36:41 -0000 SGkgUGF1bCwNCg0KSSd2ZSB0YWxrZWQgd2l0aCBhdWRpby92aWRlbyBleHBlcnRzIG9mIERldXRz Y2hlIFRlbGVrb20gYW5kIHRoZXkgdG9vIGZhdm9yZWQgd2hhdCB5b3UgcmVjb21tZW5kIGJlbG93 OiB0cmFuc3BvcnQgYXVkaW8gYW5kIHZpZGVvIGJ5IHRoZSBzYW1lIHF1ZXVlLiBZb3VyIHN0YXRl bWVudCBiZWxvdyBob3dldmVyIHN0b3BzIHRoZXJlIGFuZCB0aGUgZHJhZnQgdGV4dCBkb2Vzbid0 IGNsYXJpZnkgdGhlIGlzc3VlOg0KDQpJZiB0aGVyZSdzIGludGVyYWN0aXZlIHZpZGVvIHdpdGgg YXVkaW8sIHRoZW4gdGhleSBib3RoIHNob3VsZCBiZSBtYXJrZWQgZm9yIHRoZSBzYW1lIFBIQiB3 aGljaCBpczoNCi0gRUYgPw0KLSBBRjQ/IExpa2UgQUY0MSBBdWRpbywgQUY0MiBWaWRlbyAoQUY0 MyBpbiBhZGRpdGlvbiwgaWYgUCBvciBCIGZyYW1lcyBhcmUgdG8gcmVjZWl2ZSBhIGxvd2VyIHBy aW9yaXR5IC8gDQogIGhpZ2hlciBkcm9wIHByZWNlZGVuY2UgUEhCKT8NCg0KSSBwZXJzb25hbGx5 IHByZWZlciBBRjQgaWYgYXVkaW8gYW5kIHZpZGVvIGFyZSB0byBiZSB0cmFuc3BvcnRlZCBpbiB0 aGUgc2FtZSBxdWV1ZS4NCg0KSSdkIGFsc28gYXNrIGZvciB0aGUgZHJhZnQgdGV4dCB0byBiZSBj bGVhciBhYm91dCB0aGUgaXNzdWUgd2hlbiB0byBtYXJrIGF1ZGlvIGJ5IHRoZSBFRiBQSEIuIE15 IHVuZGVyc3RhbmRpbmcgYWZ0ZXIgcmVhZGluZyB5b3VyIHN0YXRlbWVudCBiZWxvdyBpczogQXVk aW8gbWFya2VkIEVGIGlmIHRoZXJlJ3Mgbm8gdmlkZW8gZmxvdyBvbmx5Lg0KDQouLi4NCkJDPkZp bmFsbHksIHdoeSBpcyBhdWRpbyBub3QgYWxzbyBzdWJkaXZpZGVkIGludG8gaW50ZXJhY3RpdmUg YW5kIA0KQkM+bm9uLWludGVyYWN0aXZlPyBBcyBmYXIgYXMgSSBjYW4gc2VlLCBib3RoIGFyZSBs b2dpY2FsbHkgcG9zc2libGUuDQoNCltQSl0gRm9yIFdlYlJUQywgYXVkaW8gYWxvbmUgaXMgImlu dGVyYWN0aXZlIiBpbiBuYXR1cmUgKHdoaWNoIGlzIA0KICB3aHkgaXQncyBtYXJrZWQgRUYpLiAg SG93ZXZlciwgaWYgb25lIGlzIHNlbmRpbmcgYXVkaW8gYW5kIHZpZGVvIA0KICBpdCBtYWtlcyBz ZW5zZSB0byBtYXJrIHRoZW0gYm90aCBzYW1lIHdheSB0byBnZXQgdGhlIHNhbWUgUEhCIGFuZCAN CiAgaG9wZWZ1bGx5IGhhdmUgdGhlbSBxdWV1ZWQgaW4gdGhlIHNhbWUgYnVmZmVycyBhbG9uZyB0 aGUgcGF0aC4gIA0KICBTZW5kaW5nIGF1ZGlvIGFzIEVGIGFuZCBwb3NzaWJseSBoYXZpbmcgYSBQ SEIgdGhhdCByZXN1bHRzIGluIA0KICBwYWNrZXRzIGFycml2aW5nIG11Y2ggZmFzdGVyIHRoYW4g Y29ycmVzcG9uZGluZyB2aWRlbyBwYWNrZXRzIA0KICBtYXJrZWQgYXMgQUY0MiBpcyBub3QgYXQg YWxsIGhlbHBmdWwgZm9yIGFwcGxpY2F0aW9ucyB0aGF0IGhhdmUgDQogIHRvIHN5bmNocm9uaXpl IHRoZSBhdWRpbyBhbmQgdmlkZW8gZmxvd3MuDQouLi4NCg0KICBQYXVsDQoNCg0KUmVnYXJkcywg DQoNClJ1ZWRpZ2VyDQoNCg== From nobody Mon May 9 12:04: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 5D20612D602; Mon, 9 May 2016 12:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, 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=packetizer.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 JZCSR3Tpm6Sv; Mon, 9 May 2016 12:03:38 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 74DFF12D5F6; Mon, 9 May 2016 12:03:11 -0700 (PDT) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u49J34C6000812 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 May 2016 15:03:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1462820586; bh=hOS+Dsr/FoVT+ouwnWQwfgLgt/X0XA/fPlZ1aHtkgso=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=JF0QCv8oOGGLnro3032dp4d8Q1Cao2LadoBh8iES1cZcnikMGBR1rF/sosIaop1u7 Ib6VTtBneQpTU1TwzyvQMjJZUHnbotKPcbyx4axMKEUvvrr6K2REB4oCGI33tb6yMU dC7r4aY7C6RrD9dXgTePIm4jK03wUglTJK8NBroA= From: "Paul E. Jones" To: Ruediger.Geib@telekom.de Date: Mon, 09 May 2016 19:03:10 +0000 Message-Id: In-Reply-To: <828773FE19B05B4581311493A046E85E6ECC3084D0@HE111642.emea1.cds.t-internal.com> User-Agent: eM_Client/6.0.24928.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.16 (dublin.packetizer.com [10.137.60.122]); Mon, 09 May 2016 15:03:06 -0400 (EDT) Archived-At: Cc: david.black@emc.com, rtcweb@ietf.org, brian.e.carpenter@gmail.com, tsvwg@ietf.org Subject: Re: [rtcweb] [tsvwg] Diffserv QoS for Video X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Paul E. Jones" List-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, 09 May 2016 19:03:41 -0000 Ruediger, Perhaps an example might be helpful. How about I add this text for=20 illustrative purposes? To illustrate the use of the above table, let us assume the application assigns a priority of "medium" to audio and video flows. Given that assumption, if the application wishes to send only audio then packets would be marked EF. However, if the application wishes to send both interactive video and audio, then audio and video packets would both be marked as AF42 or AF43. The intent is to ensure that when both audio and video are being sent together that they receive similar per-hop behavior. This doesn't get into the preference for AF42 vs. AF43. If it were me,=20 I'd mark all audio as AF42 and only key video frames as AF42. All=20 predictive frames would be sent with an AF43 marking. I might even take= =20 it a step further and classify all audio as "high". However, I've seen=20 a tremendous amount of debate on this before, so I'd prefer to not go=20 too far in dictating audio markings vs. video. I do think most people=20 generally agree about at least ensuring the class is the same, otherwise= =20 the wildly different PHB introduces skew between A/V packet arrival,=20 thus inflating the size of buffers managing the A/V streams. However,=20 we do not want to dictate that audio should be treated significantly=20 better than audio. For deaf users, for example, the audio really isn't=20 important at all. That is perhaps an extreme example, but it=20 nonetheless highlights why we should be cautious about exactly what we=20 normatively mandate. Paul ------ Original Message ------ From: Ruediger.Geib@telekom.de To: paulej@packetizer.com Cc: brian.e.carpenter@gmail.com; david.black@emc.com; tsvwg@ietf.org;=20 rtcweb@ietf.org Sent: 5/9/2016 3:34:25 AM Subject: AW: [tsvwg] Diffserv QoS for Video >Hi Paul, > >I've talked with audio/video experts of Deutsche Telekom and they too=20 >favored what you recommend below: transport audio and video by the same= =20 >queue. Your statement below however stops there and the draft text=20 >doesn't clarify the issue: > >If there's interactive video with audio, then they both should be=20 >marked for the same PHB which is: >- EF ? >- AF4? Like AF41 Audio, AF42 Video (AF43 in addition, if P or B frames=20 >are to receive a lower priority / > higher drop precedence PHB)? > >I personally prefer AF4 if audio and video are to be transported in the= =20 >same queue. > >I'd also ask for the draft text to be clear about the issue when to=20 >mark audio by the EF PHB. My understanding after reading your statement= =20 >below is: Audio marked EF if there's no video flow only. > >... >BC>Finally, why is audio not also subdivided into interactive and >BC>non-interactive? As far as I can see, both are logically possible. > >[PJ] For WebRTC, audio alone is "interactive" in nature (which is > why it's marked EF). However, if one is sending audio and video > it makes sense to mark them both same way to get the same PHB and > hopefully have them queued in the same buffers along the path. > Sending audio as EF and possibly having a PHB that results in > packets arriving much faster than corresponding video packets > marked as AF42 is not at all helpful for applications that have > to synchronize the audio and video flows. >... > > Paul > > >Regards, > >Ruediger > From nobody Mon May 9 13:31: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 7330B12D12A for ; Mon, 9 May 2016 13:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 2lIrnoGOMoZ8 for ; Mon, 9 May 2016 13:31:33 -0700 (PDT) Received: from smtp145.dfw.emailsrvr.com (smtp145.dfw.emailsrvr.com [67.192.241.145]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B980312B032 for ; Mon, 9 May 2016 13:31:33 -0700 (PDT) Received: from smtp31.relay.dfw1a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp31.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id E191B380440 for ; Mon, 9 May 2016 16:31:32 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp31.relay.dfw1a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id AC0C8380424 for ; Mon, 9 May 2016 16:31:32 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Mon, 09 May 2016 16:31:32 -0400 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1D53717F-3679-4E9C-B612-FA75BFF13032@iii.ca> Date: Mon, 9 May 2016 14:31:34 -0600 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [rtcweb] RTCWeb and STIR 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, 09 May 2016 20:31:35 -0000 I've been looking at how WebRTC Identity and STIR work together and put = together a worked out example at=20 http://www.ietf.org/id/draft-jennings-stir-rtcweb-identity-00.txt It does not propose any significant changes to WebRTC but it does point = at a few syntax changes that might make things easier.=20 Probably the key change for RTCWeb would be to unify the syntax we use = for DTLS-SRTP fingerprints.=20= From nobody Mon May 9 23:57: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 9653612B04F; Mon, 9 May 2016 23:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 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, 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 xSxeRVzsjc7L; Mon, 9 May 2016 23:57:02 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F23512B029; Mon, 9 May 2016 23:57:00 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail31.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 10 May 2016 08:56:57 +0200 X-IronPort-AV: E=Sophos;i="5.24,604,1454972400"; d="scan'208";a="877421609" Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 10 May 2016 08:56:57 +0200 Received: from HE111642.emea1.cds.t-internal.com ([10.134.93.11]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 10 May 2016 08:56:57 +0200 From: To: Date: Tue, 10 May 2016 08:56:55 +0200 Thread-Topic: AW: [tsvwg] Diffserv QoS for Video Thread-Index: AdGqJXH8NYneSPGYSR6kcmK6JqvclgAXrIyg Message-ID: <828773FE19B05B4581311493A046E85E6ECC4090FD@HE111642.emea1.cds.t-internal.com> References: <828773FE19B05B4581311493A046E85E6ECC3084D0@HE111642.emea1.cds.t-internal.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: david.black@emc.com, rtcweb@ietf.org, brian.e.carpenter@gmail.com, tsvwg@ietf.org Subject: Re: [rtcweb] [tsvwg] Diffserv QoS for Video 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, 10 May 2016 06:57:04 -0000 SGkgUGF1bCwNCg0KSSB0aGluayB3ZSBhZ3JlZSwgdGhhdCBhdWRpbyBhbmQgdmlkZW8gZnJhbWVz LCBpZiBib3RoIGFyZSBwYXJ0IG9mIHRoZSBzYW1lIChpbnRlcmFjdGl2ZSkgbWVkaWEgZmxvdyBz aG91bGQgYmUgdHJhbnNwb3J0ZWQgYnkgdGhlIHNhbWUgUEhCIFtQSl0gb3IgdGhlIHNhbWUgcXVl dWUgW1JHXS4gVGhlIGxhdHRlciBpcyBlbnN1cmVkLCBpZiB0aGUgc2FtZSBQSEIgaXMgcGlja2Vk IGZvciBhdWRpbyBhbmQgdmlkZW8uIFRvIG1lIHRoZSB0ZXh0IG9mIHRoZSBkcmFmdCBzbyBmYXIg ZG9lc24ndCBleHByZXNzIHRoYXQgYm90aCBhdWRpbyBhbmQgdmlkZW8gYXJlIHN1cHBvc2VkIHRv IHVzZSBhbiAiSW50ZXJhY3RpdmUgVmlkZW8uLi4iIFBIQiwgaWYgYm90aCBhcmUgcHJlc2VudC4g SSdkIHByZWZlciB0byBoYXZlIHRleHQgd2l0aCBhIG5vbiBiaW5kaW5nIHN0YW5kYXJkIHJlcXVp cmVtZW50IHNheWluZyAgDQoNCiAgICAgSG93ZXZlciwgaWYgdGhlIGFwcGxpY2F0aW9uIHdpc2hl cyB0byBzZW5kIGJvdGggaW50ZXJhY3RpdmUgDQogICAgIHZpZGVvIGFuZCBhdWRpbywgaXQgaXMg UkVDT01NRU5ERUQgdG8gdHJhbnNwb3J0IGF1ZGlvIA0KICAgICBhbmQgdmlkZW8gcGFja2V0cyBi eSB0aGUgc2FtZSBwZXIgaG9wIGJlaGF2aW9yLiBGb3IgZXhhbXBsZSwgDQogICAgIGF1ZGlvIGFu ZCB2aWRlbyBwYWNrZXRzIHdvdWxkIGJvdGggYmUgbWFya2VkIGFzIEFGNDIgb3INCiAgICAgQUY0 My4gDQoNCkkgZG9uJ3QgaW5zaXN0IG9uIGRlc2NyaXB0aXZlIHRleHQgcHJvcG9zaW5nIHRvIHRy YW5zcG9ydCBhdWRpbyBieSBhbiBBRjQgUEhCIG9mZmVyaW5nIGEgbG93ZXIgZHJvcCByYXRpbyB0 aGFuIHRoYXQgdXNlZCB0byB0cmFuc3BvcnQgdmlkZW8uIE15IGF1ZGlvL3ZpZGVvIGV4cGVydHMg c3VwcG9ydCB0aGlzIGFuZCBJJ20gcHJldHR5IHN1cmUsIHRoYXQgYWxzbyBDaXNjbyByZXByZXNl bnRhdGl2ZXMgbWVudGlvbmVkIHRoYXQgYXVkaW8gcXVhbGl0eSByYW5rcyBhYm92ZSB2aWRlbyBx dWFsaXR5IGluIHRlbGVwcmVzZW5jZSBzZXNzaW9ucy4NCg0KUmVnYXJkcywNCg0KUnVlZGlnZXIN Cg0KDQotLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQpWb246IFBhdWwgRS4gSm9u ZXMgW21haWx0bzpwYXVsZWpAcGFja2V0aXplci5jb21dIA0KR2VzZW5kZXQ6IE1vbnRhZywgOS4g TWFpIDIwMTYgMjE6MDMNCkFuOiBHZWliLCBSw7xkaWdlcg0KQ2M6IGJyaWFuLmUuY2FycGVudGVy QGdtYWlsLmNvbTsgZGF2aWQuYmxhY2tAZW1jLmNvbTsgdHN2d2dAaWV0Zi5vcmc7IHJ0Y3dlYkBp ZXRmLm9yZw0KQmV0cmVmZjogUmU6IEFXOiBbdHN2d2ddIERpZmZzZXJ2IFFvUyBmb3IgVmlkZW8N Cg0KUnVlZGlnZXIsDQoNClBlcmhhcHMgYW4gZXhhbXBsZSBtaWdodCBiZSBoZWxwZnVsLiAgSG93 IGFib3V0IEkgYWRkIHRoaXMgdGV4dCBmb3IgaWxsdXN0cmF0aXZlIHB1cnBvc2VzPw0KDQogICAg IFRvIGlsbHVzdHJhdGUgdGhlIHVzZSBvZiB0aGUgYWJvdmUgdGFibGUsIGxldCB1cyBhc3N1bWUg dGhlDQogICAgIGFwcGxpY2F0aW9uIGFzc2lnbnMgYSBwcmlvcml0eSBvZiAibWVkaXVtIiB0byBh dWRpbyBhbmQgdmlkZW8NCiAgICAgZmxvd3MuICBHaXZlbiB0aGF0IGFzc3VtcHRpb24sIGlmIHRo ZSBhcHBsaWNhdGlvbiB3aXNoZXMgdG8gc2VuZA0KICAgICBvbmx5IGF1ZGlvIHRoZW4gcGFja2V0 cyB3b3VsZCBiZSBtYXJrZWQgRUYuICBIb3dldmVyLCBpZiB0aGUNCiAgICAgYXBwbGljYXRpb24g d2lzaGVzIHRvIHNlbmQgYm90aCBpbnRlcmFjdGl2ZSB2aWRlbyBhbmQgYXVkaW8sDQogICAgIHRo ZW4gYXVkaW8gYW5kIHZpZGVvIHBhY2tldHMgd291bGQgYm90aCBiZSBtYXJrZWQgYXMgQUY0MiBv cg0KICAgICBBRjQzLiAgVGhlIGludGVudCBpcyB0byBlbnN1cmUgdGhhdCB3aGVuIGJvdGggYXVk aW8gYW5kIHZpZGVvDQogICAgIGFyZSBiZWluZyBzZW50IHRvZ2V0aGVyIHRoYXQgdGhleSByZWNl aXZlIHNpbWlsYXIgcGVyLWhvcA0KICAgICBiZWhhdmlvci4NCg0KVGhpcyBkb2Vzbid0IGdldCBp bnRvIHRoZSBwcmVmZXJlbmNlIGZvciBBRjQyIHZzLiBBRjQzLiBJZiBpdCB3ZXJlIG1lLCBJJ2Qg bWFyayBhbGwgYXVkaW8gYXMgQUY0MiBhbmQgb25seSBrZXkgdmlkZW8gZnJhbWVzIGFzIEFGNDIu ICBBbGwgcHJlZGljdGl2ZSBmcmFtZXMgd291bGQgYmUgc2VudCB3aXRoIGFuIEFGNDMgbWFya2lu Zy4gIEkgbWlnaHQgZXZlbiB0YWtlIGl0IGEgc3RlcCBmdXJ0aGVyIGFuZCBjbGFzc2lmeSBhbGwg YXVkaW8gYXMgImhpZ2giLiAgSG93ZXZlciwgSSd2ZSBzZWVuIGEgdHJlbWVuZG91cyBhbW91bnQg b2YgZGViYXRlIG9uIHRoaXMgYmVmb3JlLCBzbyBJJ2QgcHJlZmVyIHRvIG5vdCBnbyB0b28gZmFy IGluIGRpY3RhdGluZyBhdWRpbyBtYXJraW5ncyB2cy4gdmlkZW8uICBJIGRvIHRoaW5rIG1vc3Qg cGVvcGxlIGdlbmVyYWxseSBhZ3JlZSBhYm91dCBhdCBsZWFzdCBlbnN1cmluZyB0aGUgY2xhc3Mg aXMgdGhlIHNhbWUsIG90aGVyd2lzZSB0aGUgd2lsZGx5IGRpZmZlcmVudCBQSEIgaW50cm9kdWNl cyBza2V3IGJldHdlZW4gQS9WIHBhY2tldCBhcnJpdmFsLCB0aHVzIGluZmxhdGluZyB0aGUgc2l6 ZSBvZiBidWZmZXJzIG1hbmFnaW5nIHRoZSBBL1Ygc3RyZWFtcy4gIEhvd2V2ZXIsIHdlIGRvIG5v dCB3YW50IHRvIGRpY3RhdGUgdGhhdCBhdWRpbyBzaG91bGQgYmUgdHJlYXRlZCBzaWduaWZpY2Fu dGx5IGJldHRlciB0aGFuIGF1ZGlvLiAgRm9yIGRlYWYgdXNlcnMsIGZvciBleGFtcGxlLCB0aGUg YXVkaW8gcmVhbGx5IGlzbid0IGltcG9ydGFudCBhdCBhbGwuICBUaGF0IGlzIHBlcmhhcHMgYW4g ZXh0cmVtZSBleGFtcGxlLCBidXQgaXQgbm9uZXRoZWxlc3MgaGlnaGxpZ2h0cyB3aHkgd2Ugc2hv dWxkIGJlIGNhdXRpb3VzIGFib3V0IGV4YWN0bHkgd2hhdCB3ZSBub3JtYXRpdmVseSBtYW5kYXRl Lg0KDQpQYXVsDQoNCi0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLQ0KRnJvbTogUnVlZGln ZXIuR2VpYkB0ZWxla29tLmRlDQpUbzogcGF1bGVqQHBhY2tldGl6ZXIuY29tDQpDYzogYnJpYW4u ZS5jYXJwZW50ZXJAZ21haWwuY29tOyBkYXZpZC5ibGFja0BlbWMuY29tOyB0c3Z3Z0BpZXRmLm9y ZzsgcnRjd2ViQGlldGYub3JnDQpTZW50OiA1LzkvMjAxNiAzOjM0OjI1IEFNDQpTdWJqZWN0OiBB VzogW3RzdndnXSBEaWZmc2VydiBRb1MgZm9yIFZpZGVvDQoNCj5IaSBQYXVsLA0KPg0KPkkndmUg dGFsa2VkIHdpdGggYXVkaW8vdmlkZW8gZXhwZXJ0cyBvZiBEZXV0c2NoZSBUZWxla29tIGFuZCB0 aGV5IHRvbyANCj5mYXZvcmVkIHdoYXQgeW91IHJlY29tbWVuZCBiZWxvdzogdHJhbnNwb3J0IGF1 ZGlvIGFuZCB2aWRlbyBieSB0aGUgc2FtZSANCj5xdWV1ZS4gWW91ciBzdGF0ZW1lbnQgYmVsb3cg aG93ZXZlciBzdG9wcyB0aGVyZSBhbmQgdGhlIGRyYWZ0IHRleHQgDQo+ZG9lc24ndCBjbGFyaWZ5 IHRoZSBpc3N1ZToNCj4NCj5JZiB0aGVyZSdzIGludGVyYWN0aXZlIHZpZGVvIHdpdGggYXVkaW8s IHRoZW4gdGhleSBib3RoIHNob3VsZCBiZSANCj5tYXJrZWQgZm9yIHRoZSBzYW1lIFBIQiB3aGlj aCBpczoNCj4tIEVGID8NCj4tIEFGND8gTGlrZSBBRjQxIEF1ZGlvLCBBRjQyIFZpZGVvIChBRjQz IGluIGFkZGl0aW9uLCBpZiBQIG9yIEIgZnJhbWVzIA0KPmFyZSB0byByZWNlaXZlIGEgbG93ZXIg cHJpb3JpdHkgLw0KPiAgIGhpZ2hlciBkcm9wIHByZWNlZGVuY2UgUEhCKT8NCj4NCj5JIHBlcnNv bmFsbHkgcHJlZmVyIEFGNCBpZiBhdWRpbyBhbmQgdmlkZW8gYXJlIHRvIGJlIHRyYW5zcG9ydGVk IGluIHRoZSANCj5zYW1lIHF1ZXVlLg0KPg0KPkknZCBhbHNvIGFzayBmb3IgdGhlIGRyYWZ0IHRl eHQgdG8gYmUgY2xlYXIgYWJvdXQgdGhlIGlzc3VlIHdoZW4gdG8gDQo+bWFyayBhdWRpbyBieSB0 aGUgRUYgUEhCLiBNeSB1bmRlcnN0YW5kaW5nIGFmdGVyIHJlYWRpbmcgeW91ciBzdGF0ZW1lbnQg DQo+YmVsb3cgaXM6IEF1ZGlvIG1hcmtlZCBFRiBpZiB0aGVyZSdzIG5vIHZpZGVvIGZsb3cgb25s eS4NCj4NCj4uLi4NCj5CQz5GaW5hbGx5LCB3aHkgaXMgYXVkaW8gbm90IGFsc28gc3ViZGl2aWRl ZCBpbnRvIGludGVyYWN0aXZlIGFuZCANCj5CQz5ub24taW50ZXJhY3RpdmU/IEFzIGZhciBhcyBJ IGNhbiBzZWUsIGJvdGggYXJlIGxvZ2ljYWxseSBwb3NzaWJsZS4NCj4NCj5bUEpdIEZvciBXZWJS VEMsIGF1ZGlvIGFsb25lIGlzICJpbnRlcmFjdGl2ZSIgaW4gbmF0dXJlICh3aGljaCBpcw0KPiAg IHdoeSBpdCdzIG1hcmtlZCBFRikuICBIb3dldmVyLCBpZiBvbmUgaXMgc2VuZGluZyBhdWRpbyBh bmQgdmlkZW8NCj4gICBpdCBtYWtlcyBzZW5zZSB0byBtYXJrIHRoZW0gYm90aCBzYW1lIHdheSB0 byBnZXQgdGhlIHNhbWUgUEhCIGFuZA0KPiAgIGhvcGVmdWxseSBoYXZlIHRoZW0gcXVldWVkIGlu IHRoZSBzYW1lIGJ1ZmZlcnMgYWxvbmcgdGhlIHBhdGguDQo+ICAgU2VuZGluZyBhdWRpbyBhcyBF RiBhbmQgcG9zc2libHkgaGF2aW5nIGEgUEhCIHRoYXQgcmVzdWx0cyBpbg0KPiAgIHBhY2tldHMg YXJyaXZpbmcgbXVjaCBmYXN0ZXIgdGhhbiBjb3JyZXNwb25kaW5nIHZpZGVvIHBhY2tldHMNCj4g ICBtYXJrZWQgYXMgQUY0MiBpcyBub3QgYXQgYWxsIGhlbHBmdWwgZm9yIGFwcGxpY2F0aW9ucyB0 aGF0IGhhdmUNCj4gICB0byBzeW5jaHJvbml6ZSB0aGUgYXVkaW8gYW5kIHZpZGVvIGZsb3dzLg0K Pi4uLg0KPg0KPiAgIFBhdWwNCj4NCj4NCj5SZWdhcmRzLA0KPg0KPlJ1ZWRpZ2VyDQo+DQoNCg== From nobody Tue May 10 00: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 345AB12D0F6 for ; Tue, 10 May 2016 00:21:27 -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 7uvMVpOZq11j for ; Tue, 10 May 2016 00:21:25 -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 8053E12D0C0 for ; Tue, 10 May 2016 00:21:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5BB977C7C65 for ; Tue, 10 May 2016 09:21: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 bp8Q4y0Dyyeb for ; Tue, 10 May 2016 09:21:22 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:80f6:ea9b:212a:eb5a] (unknown [IPv6:2001:470:de0a:1:80f6:ea9b:212a:eb5a]) by mork.alvestrand.no (Postfix) with ESMTPSA id 3681D7C7C5F for ; Tue, 10 May 2016 09:21:22 +0200 (CEST) To: rtcweb@ietf.org References: <1D53717F-3679-4E9C-B612-FA75BFF13032@iii.ca> From: Harald Alvestrand Message-ID: <57318BF1.4050006@alvestrand.no> Date: Tue, 10 May 2016 09:21: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: <1D53717F-3679-4E9C-B612-FA75BFF13032@iii.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] RTCWeb and STIR 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, 10 May 2016 07:21:27 -0000 Den 09. mai 2016 22:31, skrev Cullen Jennings: > > > I've been looking at how WebRTC Identity and STIR work together and put together a worked out example at > > http://www.ietf.org/id/draft-jennings-stir-rtcweb-identity-00.txt > > It does not propose any significant changes to WebRTC but it does point at a few syntax changes that might make things easier. > > Probably the key change for RTCWeb would be to unify the syntax we use for DTLS-SRTP fingerprints. The fingerprint syntax comes from SDP/DTLS, not from RTCWeb, I believe. It might be best for STIR to either get with the party or propose an SDP change for DTLS. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Tue May 10 00:35:53 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 9A53812D18E; Tue, 10 May 2016 00:35:49 -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 t4l0NUyk6nS6; Tue, 10 May 2016 00:35:47 -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 C35E412B012; Tue, 10 May 2016 00:35:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id A60EC7C7C65; Tue, 10 May 2016 09:35:44 +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 7bhiuV4eO-a1; Tue, 10 May 2016 09:35:43 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:80f6:ea9b:212a:eb5a] (unknown [IPv6:2001:470:de0a:1:80f6:ea9b:212a:eb5a]) by mork.alvestrand.no (Postfix) with ESMTPSA id 0DA5A7C7C59; Tue, 10 May 2016 09:35:43 +0200 (CEST) To: Ruediger.Geib@telekom.de, paulej@packetizer.com References: <828773FE19B05B4581311493A046E85E6ECC3084D0@HE111642.emea1.cds.t-internal.com> <828773FE19B05B4581311493A046E85E6ECC4090FD@HE111642.emea1.cds.t-internal.com> From: Harald Alvestrand X-Enigmail-Draft-Status: N1110 Message-ID: <57318F4E.4080102@alvestrand.no> Date: Tue, 10 May 2016 09:35:42 +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: <828773FE19B05B4581311493A046E85E6ECC4090FD@HE111642.emea1.cds.t-internal.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [rtcweb] [tsvwg] Diffserv QoS for Video 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, 10 May 2016 07:35:49 -0000 FTR: I don't see such an agreement at all. On the contrary, my perception is that people want the ability to deliver audio with a lower loss probability and lower delay probability than video - it's more important to the conversation, and there are fewer things the recipient can do to hide the losses. If the sender chose to send them on separate flows, they shold have different DSCP markings. I believe this is what draft-ietf-tsvwg-rtcweb-qos-15 section 5 states, and I believe that this is what TSVWG has declared consensus on and wrote in the document that passed WG last call and is currently in "waiting for writeup" state. Changing this determination would, at minimum, require reopening the WG Last Call. And I'd object. Harald Den 10. mai 2016 08:56, skrev Ruediger.Geib@telekom.de: > Hi Paul, > > I think we agree, that audio and video frames, if both are part of the same (interactive) media flow should be transported by the same PHB [PJ] or the same queue [RG]. The latter is ensured, if the same PHB is picked for audio and video. To me the text of the draft so far doesn't express that both audio and video are supposed to use an "Interactive Video..." PHB, if both are present. I'd prefer to have text with a non binding standard requirement saying > > However, if the application wishes to send both interactive > video and audio, it is RECOMMENDED to transport audio > and video packets by the same per hop behavior. For example, > audio and video packets would both be marked as AF42 or > AF43. > > I don't insist on descriptive text proposing to transport audio by an AF4 PHB offering a lower drop ratio than that used to transport video. My audio/video experts support this and I'm pretty sure, that also Cisco representatives mentioned that audio quality ranks above video quality in telepresence sessions. > > Regards, > > Ruediger > > > -----Ursprüngliche Nachricht----- > Von: Paul E. Jones [mailto:paulej@packetizer.com] > Gesendet: Montag, 9. Mai 2016 21:03 > An: Geib, Rüdiger > Cc: brian.e.carpenter@gmail.com; david.black@emc.com; tsvwg@ietf.org; rtcweb@ietf.org > Betreff: Re: AW: [tsvwg] Diffserv QoS for Video > > Ruediger, > > Perhaps an example might be helpful. How about I add this text for illustrative purposes? > > To illustrate the use of the above table, let us assume the > application assigns a priority of "medium" to audio and video > flows. Given that assumption, if the application wishes to send > only audio then packets would be marked EF. However, if the > application wishes to send both interactive video and audio, > then audio and video packets would both be marked as AF42 or > AF43. The intent is to ensure that when both audio and video > are being sent together that they receive similar per-hop > behavior. > > This doesn't get into the preference for AF42 vs. AF43. If it were me, I'd mark all audio as AF42 and only key video frames as AF42. All predictive frames would be sent with an AF43 marking. I might even take it a step further and classify all audio as "high". However, I've seen a tremendous amount of debate on this before, so I'd prefer to not go too far in dictating audio markings vs. video. I do think most people generally agree about at least ensuring the class is the same, otherwise the wildly different PHB introduces skew between A/V packet arrival, thus inflating the size of buffers managing the A/V streams. However, we do not want to dictate that audio should be treated significantly better than audio. For deaf users, for example, the audio really isn't important at all. That is perhaps an extreme example, but it nonetheless highlights why we should be cautious about exactly what we normatively mandate. > > Paul > > ------ Original Message ------ > From: Ruediger.Geib@telekom.de > To: paulej@packetizer.com > Cc: brian.e.carpenter@gmail.com; david.black@emc.com; tsvwg@ietf.org; rtcweb@ietf.org > Sent: 5/9/2016 3:34:25 AM > Subject: AW: [tsvwg] Diffserv QoS for Video > >> Hi Paul, >> >> I've talked with audio/video experts of Deutsche Telekom and they too >> favored what you recommend below: transport audio and video by the same >> queue. Your statement below however stops there and the draft text >> doesn't clarify the issue: >> >> If there's interactive video with audio, then they both should be >> marked for the same PHB which is: >> - EF ? >> - AF4? Like AF41 Audio, AF42 Video (AF43 in addition, if P or B frames >> are to receive a lower priority / >> higher drop precedence PHB)? >> >> I personally prefer AF4 if audio and video are to be transported in the >> same queue. >> >> I'd also ask for the draft text to be clear about the issue when to >> mark audio by the EF PHB. My understanding after reading your statement >> below is: Audio marked EF if there's no video flow only. >> >> ... >> BC>Finally, why is audio not also subdivided into interactive and >> BC>non-interactive? As far as I can see, both are logically possible. >> >> [PJ] For WebRTC, audio alone is "interactive" in nature (which is >> why it's marked EF). However, if one is sending audio and video >> it makes sense to mark them both same way to get the same PHB and >> hopefully have them queued in the same buffers along the path. >> Sending audio as EF and possibly having a PHB that results in >> packets arriving much faster than corresponding video packets >> marked as AF42 is not at all helpful for applications that have >> to synchronize the audio and video flows. >> ... >> >> Paul >> >> >> Regards, >> >> Ruediger >> > From nobody Tue May 10 01:22: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 5820D12B074; Tue, 10 May 2016 01:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 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, 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 TDbu5l6CQoSf; Tue, 10 May 2016 01:22:00 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 771B6128874; Tue, 10 May 2016 01:21:58 -0700 (PDT) Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail91.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 10 May 2016 10:18:36 +0200 X-IronPort-AV: E=Sophos;i="5.24,604,1454972400"; d="scan'208";a="1059181812" Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 10 May 2016 10:18:31 +0200 Received: from HE111642.emea1.cds.t-internal.com ([10.134.93.11]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 10 May 2016 10:18:31 +0200 From: To: Date: Tue, 10 May 2016 10:18:30 +0200 Thread-Topic: [tsvwg] Diffserv QoS for Video Thread-Index: AdGqjqcAtUfKmRHmTSOs4NfsI9nIYQAARuzg Message-ID: <828773FE19B05B4581311493A046E85E6ECC409176@HE111642.emea1.cds.t-internal.com> References: <828773FE19B05B4581311493A046E85E6ECC3084D0@HE111642.emea1.cds.t-internal.com> <828773FE19B05B4581311493A046E85E6ECC4090FD@HE111642.emea1.cds.t-internal.com> <57318F4E.4080102@alvestrand.no> In-Reply-To: <57318F4E.4080102@alvestrand.no> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [rtcweb] [tsvwg] Diffserv QoS for Video 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, 10 May 2016 08:22:03 -0000 SGkgSGFyYWxkLA0KDQpXZSBzaG91bGQgYXZvaWQgdG8gcmUtb3BlbiBsYXN0IGNhbGwuIFRoYXQn cyBub3QgbXkgaW50ZW50Lg0KDQpJJ20gd29ya2luZyBvbiB0cmFuc3BvcnQgb25seSBhbmQgbXkg cnRjd2ViIGlucHV0IGlzIGRyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcy0xNS4gSXQgc3RhdGVz IGxpdHRsZSBmb3IgYXVkaWVuY2UgbGlrZSBtZSwgaWYgdGhlIHN1YmplY3QgaXMgYXVkaW8gYW5k IHZpZGVvIHJlbGF0ZWQgdG8gYSB0YWxraW5nIHBlcnNvbi4gSSB0aGluayB0aGUgcmVsZXZhbnQg c3RhdGVtZW50IGFyZSBsaW5lcyBpbiBhIHRhYmxlLiBJJ2QgYXBwcmVjaWF0ZSB0ZXh0IGhlbHBp bmcgd2l0aCB0aGUgaW50ZXJwcmV0YXRpb24gb2YgdGFibGUuIElmIHdlIGNhbid0IGFncmVlIG9u IHVzZWZ1bCB0ZXh0IC0gbGVhdmUgaXQgYXMgaXMuDQoNCkEgYmFja2JvbmUgc3VwcG9ydGluZyBS VFAgYmFzZWQgVFYgZGlzdHJpYnV0aW9uIHRlbmRzIHRvIGJlIGVuZ2luZWVyZWQgZm9yIHN1cHBv cnQgb2YgYW4gQUY0IGxpa2UgUW9TIGNsYXNzIGZvciBsb3cgbG9zcy4gSSB0aGluaywgdGVsZXBo b255IGNvZGVjcywgd2hvc2UgUlRQIHN0cmVhbXMgd2lsbCBiZSB0cmFuc3BvcnRlZCBieSBFRiwg YXJlIGFibGUgdG8gZGVhbCB3aXRoIGhpZ2hlciBwYWNrZXQgbG9zcywgdGhhbiBtdWx0aWNhc3Qg YmFzZWQgSVBUVi4gDQoNClRvIG1lLCBhbiBhdWRpbyBvciB0ZWxlcHJlc2VuY2UvdmlkZW9jb25m ZXJlbmNlIGNhbGwgd2l0aCBRb1MgcmVxdWlyZSBhZG1pc3Npb24gY29udHJvbC4gVGhpcyBlbnN1 cmVzIHRoYXQgdGhleSBhcmUgdHJhbnNwb3J0ZWQgd2l0aG91dCBxdWV1aW5nIG9yIGRyb3BzLg0K DQpJZiB0aGVyZSdzIGNvbmdlc3Rpb24gaG93ZXZlcjoNCg0KQW4gYXVkaW8gZmxvdyBtYXJrZWQg QUY0MSBzaG91bGQgZmFjZSBhIGxvd2VyIGRyb3AgcmF0ZSB0aGFuIGEgdmlkZW8gZmxvdyBtYXJr ZWQgQUY0MiBpbiB0aGUgY2FzZSBvZiBjb25nZXN0aW9uIGF0IGFuIG5ldHdvcmsgZWRnZSBub2Rl LiBUaGUgcGFja2V0cyBhcnJpdmUgaW4gdGhlIHNhbWUgb3JkZXIgYXMgdGhleSB3ZXJlIHNlbnQg KGluZGVwZW5kZW50IG9mIHRoZSBmbG93IHRoZXkgYmVsb25nIHRvKS4NCg0KQW4gRUYgbWFya2Vk IGF1ZGlvIGZsb3cgbWF5IGV4cGVyaWVuY2UgbG9zcyBldmVudHMgaW5kZXBlbmRlbnQgZnJvbSBh IHZpZGVvIGZsb3cgbWFya2VkIEFGNHguIEluIHRoZSBjYXNlIG9mIHF1ZXVpbmcsIG9uZSBvZiB0 aGUgZmxvd3Mgd2lsbCBiZSBlYXJsaWVyLiBJZiBib3RoIGFyZSB0cmFuc3BvcnRlZCBieSBRb1Mg Y2xhc3NlcyBvcHRpbWl6ZWQgZm9yIHJ0cC91ZHAgdHJhbnNwb3J0LCB0aGUgZGlmZmVyZW5jZSBp cyBhIGZldyBbbXNdIHBlciBjb25nZXN0aW9uIHBvaW50LiBJZiBvbmUgb2YgdGhlIHF1ZXVlcyBp cyBvcHRpbWl6ZWQgZm9yIGdlbmVyYWwgZGF0YSB0cmFuc3BvcnQsIHRoZSBkZWxheSBkaWZmZXJl bmNlIGlzIGxpa2VseSB0byBiZSBhIGRvdWJsZSBkaWdpdCBbbXNdIG51bWJlci4gVGhlIHBhY2tl dHMgb2YgZWFjaCBmbG93IGFycml2ZSBpbiBvcmRlciBhcyBzZW50LCB0aGUgcGFja2V0cyBvZiBv bmUgZmxvdyBhcmUgZGVsYXllZCBhZ2FpbnN0IHRob3NlIG9mIHRoZSBvdGhlci4NCg0KUmVnYXJk cywNCg0KUnVlZGlnZXINCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KVm9u OiBIYXJhbGQgQWx2ZXN0cmFuZCBbbWFpbHRvOmhhcmFsZEBhbHZlc3RyYW5kLm5vXSANCkdlc2Vu ZGV0OiBEaWVuc3RhZywgMTAuIE1haSAyMDE2IDA5OjM2DQpBbjogR2VpYiwgUsO8ZGlnZXI7IHBh dWxlakBwYWNrZXRpemVyLmNvbQ0KQ2M6IHJ0Y3dlYkBpZXRmLm9yZzsgdHN2d2dAaWV0Zi5vcmcN CkJldHJlZmY6IFJlOiBbdHN2d2ddIERpZmZzZXJ2IFFvUyBmb3IgVmlkZW8NCg0KRlRSOiBJIGRv bid0IHNlZSBzdWNoIGFuIGFncmVlbWVudCBhdCBhbGwuDQoNCk9uIHRoZSBjb250cmFyeSwgbXkg cGVyY2VwdGlvbiBpcyB0aGF0IHBlb3BsZSB3YW50IHRoZSBhYmlsaXR5IHRvIGRlbGl2ZXIgYXVk aW8gd2l0aCBhIGxvd2VyIGxvc3MgcHJvYmFiaWxpdHkgYW5kIGxvd2VyIGRlbGF5IHByb2JhYmls aXR5IHRoYW4gdmlkZW8gLSBpdCdzIG1vcmUgaW1wb3J0YW50IHRvIHRoZSBjb252ZXJzYXRpb24s IGFuZCB0aGVyZSBhcmUgZmV3ZXIgdGhpbmdzIHRoZSByZWNpcGllbnQgY2FuIGRvIHRvIGhpZGUg dGhlIGxvc3Nlcy4gSWYgdGhlIHNlbmRlciBjaG9zZSB0byBzZW5kIHRoZW0gb24gc2VwYXJhdGUg Zmxvd3MsIHRoZXkgc2hvbGQgaGF2ZSBkaWZmZXJlbnQgRFNDUCBtYXJraW5ncy4NCg0KSSBiZWxp ZXZlIHRoaXMgaXMgd2hhdCBkcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3MtMTUgc2VjdGlvbiA1 IHN0YXRlcywgYW5kIEkgYmVsaWV2ZSB0aGF0IHRoaXMgaXMgd2hhdCBUU1ZXRyBoYXMgZGVjbGFy ZWQgY29uc2Vuc3VzIG9uIGFuZCB3cm90ZSBpbiB0aGUgZG9jdW1lbnQgdGhhdCBwYXNzZWQgV0cg bGFzdCBjYWxsIGFuZCBpcyBjdXJyZW50bHkgaW4gIndhaXRpbmcgZm9yIHdyaXRldXAiIHN0YXRl Lg0KDQpDaGFuZ2luZyB0aGlzIGRldGVybWluYXRpb24gd291bGQsIGF0IG1pbmltdW0sIHJlcXVp cmUgcmVvcGVuaW5nIHRoZSBXRyBMYXN0IENhbGwuDQpBbmQgSSdkIG9iamVjdC4NCg0KSGFyYWxk DQoNCg0KRGVuIDEwLiBtYWkgMjAxNiAwODo1Niwgc2tyZXYgUnVlZGlnZXIuR2VpYkB0ZWxla29t LmRlOg0KPiBIaSBQYXVsLA0KPiANCj4gSSB0aGluayB3ZSBhZ3JlZSwgdGhhdCBhdWRpbyBhbmQg dmlkZW8gZnJhbWVzLCBpZiBib3RoIGFyZSBwYXJ0IG9mIHRoZSANCj4gc2FtZSAoaW50ZXJhY3Rp dmUpIG1lZGlhIGZsb3cgc2hvdWxkIGJlIHRyYW5zcG9ydGVkIGJ5IHRoZSBzYW1lIFBIQiANCj4g W1BKXSBvciB0aGUgc2FtZSBxdWV1ZSBbUkddLiBUaGUgbGF0dGVyIGlzIGVuc3VyZWQsIGlmIHRo ZSBzYW1lIFBIQiBpcyANCj4gcGlja2VkIGZvciBhdWRpbyBhbmQgdmlkZW8uIFRvIG1lIHRoZSB0 ZXh0IG9mIHRoZSBkcmFmdCBzbyBmYXIgZG9lc24ndCANCj4gZXhwcmVzcyB0aGF0IGJvdGggYXVk aW8gYW5kIHZpZGVvIGFyZSBzdXBwb3NlZCB0byB1c2UgYW4gIkludGVyYWN0aXZlIA0KPiBWaWRl by4uLiIgUEhCLCBpZiBib3RoIGFyZSBwcmVzZW50LiBJJ2QgcHJlZmVyIHRvIGhhdmUgdGV4dCB3 aXRoIGEgbm9uIA0KPiBiaW5kaW5nIHN0YW5kYXJkIHJlcXVpcmVtZW50IHNheWluZw0KPiANCj4g ICAgICBIb3dldmVyLCBpZiB0aGUgYXBwbGljYXRpb24gd2lzaGVzIHRvIHNlbmQgYm90aCBpbnRl cmFjdGl2ZSANCj4gICAgICB2aWRlbyBhbmQgYXVkaW8sIGl0IGlzIFJFQ09NTUVOREVEIHRvIHRy YW5zcG9ydCBhdWRpbyANCj4gICAgICBhbmQgdmlkZW8gcGFja2V0cyBieSB0aGUgc2FtZSBwZXIg aG9wIGJlaGF2aW9yLiBGb3IgZXhhbXBsZSwgDQo+ICAgICAgYXVkaW8gYW5kIHZpZGVvIHBhY2tl dHMgd291bGQgYm90aCBiZSBtYXJrZWQgYXMgQUY0MiBvcg0KPiAgICAgIEFGNDMuIA0KPiANCj4g SSBkb24ndCBpbnNpc3Qgb24gZGVzY3JpcHRpdmUgdGV4dCBwcm9wb3NpbmcgdG8gdHJhbnNwb3J0 IGF1ZGlvIGJ5IGFuIEFGNCBQSEIgb2ZmZXJpbmcgYSBsb3dlciBkcm9wIHJhdGlvIHRoYW4gdGhh dCB1c2VkIHRvIHRyYW5zcG9ydCB2aWRlby4gTXkgYXVkaW8vdmlkZW8gZXhwZXJ0cyBzdXBwb3J0 IHRoaXMgYW5kIEknbSBwcmV0dHkgc3VyZSwgdGhhdCBhbHNvIENpc2NvIHJlcHJlc2VudGF0aXZl cyBtZW50aW9uZWQgdGhhdCBhdWRpbyBxdWFsaXR5IHJhbmtzIGFib3ZlIHZpZGVvIHF1YWxpdHkg aW4gdGVsZXByZXNlbmNlIHNlc3Npb25zLg0KPiANCj4gUmVnYXJkcywNCj4gDQo+IFJ1ZWRpZ2Vy DQo+IA0KPiANCj4gLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KPiBWb246IFBh dWwgRS4gSm9uZXMgW21haWx0bzpwYXVsZWpAcGFja2V0aXplci5jb21dDQo+IEdlc2VuZGV0OiBN b250YWcsIDkuIE1haSAyMDE2IDIxOjAzDQo+IEFuOiBHZWliLCBSw7xkaWdlcg0KPiBDYzogYnJp YW4uZS5jYXJwZW50ZXJAZ21haWwuY29tOyBkYXZpZC5ibGFja0BlbWMuY29tOyB0c3Z3Z0BpZXRm Lm9yZzsgDQo+IHJ0Y3dlYkBpZXRmLm9yZw0KPiBCZXRyZWZmOiBSZTogQVc6IFt0c3Z3Z10gRGlm ZnNlcnYgUW9TIGZvciBWaWRlbw0KPiANCj4gUnVlZGlnZXIsDQo+IA0KPiBQZXJoYXBzIGFuIGV4 YW1wbGUgbWlnaHQgYmUgaGVscGZ1bC4gIEhvdyBhYm91dCBJIGFkZCB0aGlzIHRleHQgZm9yIGls bHVzdHJhdGl2ZSBwdXJwb3Nlcz8NCj4gDQo+ICAgICAgVG8gaWxsdXN0cmF0ZSB0aGUgdXNlIG9m IHRoZSBhYm92ZSB0YWJsZSwgbGV0IHVzIGFzc3VtZSB0aGUNCj4gICAgICBhcHBsaWNhdGlvbiBh c3NpZ25zIGEgcHJpb3JpdHkgb2YgIm1lZGl1bSIgdG8gYXVkaW8gYW5kIHZpZGVvDQo+ICAgICAg Zmxvd3MuICBHaXZlbiB0aGF0IGFzc3VtcHRpb24sIGlmIHRoZSBhcHBsaWNhdGlvbiB3aXNoZXMg dG8gc2VuZA0KPiAgICAgIG9ubHkgYXVkaW8gdGhlbiBwYWNrZXRzIHdvdWxkIGJlIG1hcmtlZCBF Ri4gIEhvd2V2ZXIsIGlmIHRoZQ0KPiAgICAgIGFwcGxpY2F0aW9uIHdpc2hlcyB0byBzZW5kIGJv dGggaW50ZXJhY3RpdmUgdmlkZW8gYW5kIGF1ZGlvLA0KPiAgICAgIHRoZW4gYXVkaW8gYW5kIHZp ZGVvIHBhY2tldHMgd291bGQgYm90aCBiZSBtYXJrZWQgYXMgQUY0MiBvcg0KPiAgICAgIEFGNDMu ICBUaGUgaW50ZW50IGlzIHRvIGVuc3VyZSB0aGF0IHdoZW4gYm90aCBhdWRpbyBhbmQgdmlkZW8N Cj4gICAgICBhcmUgYmVpbmcgc2VudCB0b2dldGhlciB0aGF0IHRoZXkgcmVjZWl2ZSBzaW1pbGFy IHBlci1ob3ANCj4gICAgICBiZWhhdmlvci4NCj4gDQo+IFRoaXMgZG9lc24ndCBnZXQgaW50byB0 aGUgcHJlZmVyZW5jZSBmb3IgQUY0MiB2cy4gQUY0My4gSWYgaXQgd2VyZSBtZSwgSSdkIG1hcmsg YWxsIGF1ZGlvIGFzIEFGNDIgYW5kIG9ubHkga2V5IHZpZGVvIGZyYW1lcyBhcyBBRjQyLiAgQWxs IHByZWRpY3RpdmUgZnJhbWVzIHdvdWxkIGJlIHNlbnQgd2l0aCBhbiBBRjQzIG1hcmtpbmcuICBJ IG1pZ2h0IGV2ZW4gdGFrZSBpdCBhIHN0ZXAgZnVydGhlciBhbmQgY2xhc3NpZnkgYWxsIGF1ZGlv IGFzICJoaWdoIi4gIEhvd2V2ZXIsIEkndmUgc2VlbiBhIHRyZW1lbmRvdXMgYW1vdW50IG9mIGRl YmF0ZSBvbiB0aGlzIGJlZm9yZSwgc28gSSdkIHByZWZlciB0byBub3QgZ28gdG9vIGZhciBpbiBk aWN0YXRpbmcgYXVkaW8gbWFya2luZ3MgdnMuIHZpZGVvLiAgSSBkbyB0aGluayBtb3N0IHBlb3Bs ZSBnZW5lcmFsbHkgYWdyZWUgYWJvdXQgYXQgbGVhc3QgZW5zdXJpbmcgdGhlIGNsYXNzIGlzIHRo ZSBzYW1lLCBvdGhlcndpc2UgdGhlIHdpbGRseSBkaWZmZXJlbnQgUEhCIGludHJvZHVjZXMgc2tl dyBiZXR3ZWVuIEEvViBwYWNrZXQgYXJyaXZhbCwgdGh1cyBpbmZsYXRpbmcgdGhlIHNpemUgb2Yg YnVmZmVycyBtYW5hZ2luZyB0aGUgQS9WIHN0cmVhbXMuICBIb3dldmVyLCB3ZSBkbyBub3Qgd2Fu dCB0byBkaWN0YXRlIHRoYXQgYXVkaW8gc2hvdWxkIGJlIHRyZWF0ZWQgc2lnbmlmaWNhbnRseSBi ZXR0ZXIgdGhhbiBhdWRpby4gIEZvciBkZWFmIHVzZXJzLCBmb3IgZXhhbXBsZSwgdGhlIGF1ZGlv IHJlYWxseSBpc24ndCBpbXBvcnRhbnQgYXQgYWxsLiAgVGhhdCBpcyBwZXJoYXBzIGFuIGV4dHJl bWUgZXhhbXBsZSwgYnV0IGl0IG5vbmV0aGVsZXNzIGhpZ2hsaWdodHMgd2h5IHdlIHNob3VsZCBi ZSBjYXV0aW91cyBhYm91dCBleGFjdGx5IHdoYXQgd2Ugbm9ybWF0aXZlbHkgbWFuZGF0ZS4NCj4g DQo+IFBhdWwNCj4gDQo+IC0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLQ0KPiBGcm9tOiBS dWVkaWdlci5HZWliQHRlbGVrb20uZGUNCj4gVG86IHBhdWxlakBwYWNrZXRpemVyLmNvbQ0KPiBD YzogYnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tOyBkYXZpZC5ibGFja0BlbWMuY29tOyB0c3Z3 Z0BpZXRmLm9yZzsgDQo+IHJ0Y3dlYkBpZXRmLm9yZw0KPiBTZW50OiA1LzkvMjAxNiAzOjM0OjI1 IEFNDQo+IFN1YmplY3Q6IEFXOiBbdHN2d2ddIERpZmZzZXJ2IFFvUyBmb3IgVmlkZW8NCj4gDQo+ PiBIaSBQYXVsLA0KPj4NCj4+IEkndmUgdGFsa2VkIHdpdGggYXVkaW8vdmlkZW8gZXhwZXJ0cyBv ZiBEZXV0c2NoZSBUZWxla29tIGFuZCB0aGV5IHRvbyANCj4+IGZhdm9yZWQgd2hhdCB5b3UgcmVj b21tZW5kIGJlbG93OiB0cmFuc3BvcnQgYXVkaW8gYW5kIHZpZGVvIGJ5IHRoZSANCj4+IHNhbWUg cXVldWUuIFlvdXIgc3RhdGVtZW50IGJlbG93IGhvd2V2ZXIgc3RvcHMgdGhlcmUgYW5kIHRoZSBk cmFmdCANCj4+IHRleHQgZG9lc24ndCBjbGFyaWZ5IHRoZSBpc3N1ZToNCj4+DQo+PiBJZiB0aGVy ZSdzIGludGVyYWN0aXZlIHZpZGVvIHdpdGggYXVkaW8sIHRoZW4gdGhleSBib3RoIHNob3VsZCBi ZSANCj4+IG1hcmtlZCBmb3IgdGhlIHNhbWUgUEhCIHdoaWNoIGlzOg0KPj4gLSBFRiA/DQo+PiAt IEFGND8gTGlrZSBBRjQxIEF1ZGlvLCBBRjQyIFZpZGVvIChBRjQzIGluIGFkZGl0aW9uLCBpZiBQ IG9yIEIgDQo+PiBmcmFtZXMgYXJlIHRvIHJlY2VpdmUgYSBsb3dlciBwcmlvcml0eSAvDQo+PiAg IGhpZ2hlciBkcm9wIHByZWNlZGVuY2UgUEhCKT8NCj4+DQo+PiBJIHBlcnNvbmFsbHkgcHJlZmVy IEFGNCBpZiBhdWRpbyBhbmQgdmlkZW8gYXJlIHRvIGJlIHRyYW5zcG9ydGVkIGluIA0KPj4gdGhl IHNhbWUgcXVldWUuDQo+Pg0KPj4gSSdkIGFsc28gYXNrIGZvciB0aGUgZHJhZnQgdGV4dCB0byBi ZSBjbGVhciBhYm91dCB0aGUgaXNzdWUgd2hlbiB0byANCj4+IG1hcmsgYXVkaW8gYnkgdGhlIEVG IFBIQi4gTXkgdW5kZXJzdGFuZGluZyBhZnRlciByZWFkaW5nIHlvdXIgDQo+PiBzdGF0ZW1lbnQg YmVsb3cgaXM6IEF1ZGlvIG1hcmtlZCBFRiBpZiB0aGVyZSdzIG5vIHZpZGVvIGZsb3cgb25seS4N Cj4+DQo+PiAuLi4NCj4+IEJDPkZpbmFsbHksIHdoeSBpcyBhdWRpbyBub3QgYWxzbyBzdWJkaXZp ZGVkIGludG8gaW50ZXJhY3RpdmUgYW5kIA0KPj4gQkM+bm9uLWludGVyYWN0aXZlPyBBcyBmYXIg YXMgSSBjYW4gc2VlLCBib3RoIGFyZSBsb2dpY2FsbHkgcG9zc2libGUuDQo+Pg0KPj4gW1BKXSBG b3IgV2ViUlRDLCBhdWRpbyBhbG9uZSBpcyAiaW50ZXJhY3RpdmUiIGluIG5hdHVyZSAod2hpY2gg aXMNCj4+ICAgd2h5IGl0J3MgbWFya2VkIEVGKS4gIEhvd2V2ZXIsIGlmIG9uZSBpcyBzZW5kaW5n IGF1ZGlvIGFuZCB2aWRlbw0KPj4gICBpdCBtYWtlcyBzZW5zZSB0byBtYXJrIHRoZW0gYm90aCBz YW1lIHdheSB0byBnZXQgdGhlIHNhbWUgUEhCIGFuZA0KPj4gICBob3BlZnVsbHkgaGF2ZSB0aGVt IHF1ZXVlZCBpbiB0aGUgc2FtZSBidWZmZXJzIGFsb25nIHRoZSBwYXRoLg0KPj4gICBTZW5kaW5n IGF1ZGlvIGFzIEVGIGFuZCBwb3NzaWJseSBoYXZpbmcgYSBQSEIgdGhhdCByZXN1bHRzIGluDQo+ PiAgIHBhY2tldHMgYXJyaXZpbmcgbXVjaCBmYXN0ZXIgdGhhbiBjb3JyZXNwb25kaW5nIHZpZGVv IHBhY2tldHMNCj4+ICAgbWFya2VkIGFzIEFGNDIgaXMgbm90IGF0IGFsbCBoZWxwZnVsIGZvciBh cHBsaWNhdGlvbnMgdGhhdCBoYXZlDQo+PiAgIHRvIHN5bmNocm9uaXplIHRoZSBhdWRpbyBhbmQg dmlkZW8gZmxvd3MuDQo+PiAuLi4NCj4+DQo+PiAgIFBhdWwNCj4+DQo+Pg0KPj4gUmVnYXJkcywN Cj4+DQo+PiBSdWVkaWdlcg0KPj4NCj4gDQo= From nobody Tue May 10 02:20:42 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 8EF1612D0F6; Tue, 10 May 2016 02:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.916 X-Spam-Level: X-Spam-Status: No, score=-7.916 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, 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 x4rqAnr_Jj0z; Tue, 10 May 2016 02:20:38 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0144512D09B; Tue, 10 May 2016 02:20:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DAAQB3JjFX/yYyC4ddGgEBAYJwK1V9Bq00i2IBDYF2HoVyAhyBHTgUAQEBAQEBAWUnhEEBAQEBAgESERE3AwIJDAQCAQgNBAQBAQMCBh0DAgICHxEUAQgIAgQBDQUIGodzAwsIAaN1ilCMSw2EKQEBAQEBAQEBAQEBAQEBAQEBAQEBARV8hSWES4JDgX4Vgmkrgi4Fl3ExAYV8hiUBhDCHH4VBh1iHYx4BAUKDa24BiAoBfgEBAQ X-IPAS-Result: A2DAAQB3JjFX/yYyC4ddGgEBAYJwK1V9Bq00i2IBDYF2HoVyAhyBHTgUAQEBAQEBAWUnhEEBAQEBAgESERE3AwIJDAQCAQgNBAQBAQMCBh0DAgICHxEUAQgIAgQBDQUIGodzAwsIAaN1ilCMSw2EKQEBAQEBAQEBAQEBAQEBAQEBAQEBARV8hSWES4JDgX4Vgmkrgi4Fl3ExAYV8hiUBhDCHH4VBh1iHYx4BAUKDa24BiAoBfgEBAQ X-IronPort-AV: E=Sophos;i="5.24,602,1454994000"; d="scan'208";a="154227679" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 May 2016 05:20:08 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 10 May 2016 05:20:07 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Tue, 10 May 2016 11:20:04 +0200 From: "Romascanu, Dan (Dan)" To: Harald Alvestrand , "Ruediger.Geib@telekom.de" , "paulej@packetizer.com" Thread-Topic: [rtcweb] [tsvwg] Diffserv QoS for Video Thread-Index: AQHRqiX79R6h3mPvRUCRYLUrADxkFZ+xnHOAgAAK1gCAAD1UAA== Date: Tue, 10 May 2016 09:20:04 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA751DEFE3@AZ-FFEXMB04.global.avaya.com> References: <828773FE19B05B4581311493A046E85E6ECC3084D0@HE111642.emea1.cds.t-internal.com> <828773FE19B05B4581311493A046E85E6ECC4090FD@HE111642.emea1.cds.t-internal.com> <57318F4E.4080102@alvestrand.no> In-Reply-To: <57318F4E.4080102@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] Diffserv QoS for Video 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, 10 May 2016 09:20:41 -0000 SSB3b3VsZCBhZ3JlZSB3aXRoIEhhcmFsZCBoZXJlLiBBbHNvLCBmcm9tIGEgVUkgcGVyc3BlY3Rp dmUgLSBpbiBtYW55IGNvbmZlcmVuY2luZyBzaXR1YXRpb25zIG9uZSB3b3VsZCBhY2NlcHQgbW9t ZW50YXJ5IGxvc3NlcyBvbiB0aGUgdmlkZW8gZmxvdyAodHJhbnNsYXRlZCBpbiBmcm96ZW4gZnJh bWVzKSB3aXRoIHRoZSBjb25kaXRpb24gdGhhdCBhdWRpbyBpcyBub3QgaW50ZXJydXB0ZWQuIA0K DQpSZWdhcmRzLA0KDQpEYW4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog cnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYXJh bGQgQWx2ZXN0cmFuZA0KU2VudDogVHVlc2RheSwgTWF5IDEwLCAyMDE2IDEwOjM2IEFNDQpUbzog UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlOyBwYXVsZWpAcGFja2V0aXplci5jb20NCkNjOiBydGN3 ZWJAaWV0Zi5vcmc7IHRzdndnQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gW3Rzdndn XSBEaWZmc2VydiBRb1MgZm9yIFZpZGVvDQoNCkZUUjogSSBkb24ndCBzZWUgc3VjaCBhbiBhZ3Jl ZW1lbnQgYXQgYWxsLg0KDQpPbiB0aGUgY29udHJhcnksIG15IHBlcmNlcHRpb24gaXMgdGhhdCBw ZW9wbGUgd2FudCB0aGUgYWJpbGl0eSB0byBkZWxpdmVyIGF1ZGlvIHdpdGggYSBsb3dlciBsb3Nz IHByb2JhYmlsaXR5IGFuZCBsb3dlciBkZWxheSBwcm9iYWJpbGl0eSB0aGFuIHZpZGVvIC0gaXQn cyBtb3JlIGltcG9ydGFudCB0byB0aGUgY29udmVyc2F0aW9uLCBhbmQgdGhlcmUgYXJlIGZld2Vy IHRoaW5ncyB0aGUgcmVjaXBpZW50IGNhbiBkbyB0byBoaWRlIHRoZSBsb3NzZXMuIElmIHRoZSBz ZW5kZXIgY2hvc2UgdG8gc2VuZCB0aGVtIG9uIHNlcGFyYXRlIGZsb3dzLCB0aGV5IHNob2xkIGhh dmUgZGlmZmVyZW50IERTQ1AgbWFya2luZ3MuDQoNCkkgYmVsaWV2ZSB0aGlzIGlzIHdoYXQgZHJh ZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zLTE1IHNlY3Rpb24gNSBzdGF0ZXMsIGFuZCBJIGJlbGll dmUgdGhhdCB0aGlzIGlzIHdoYXQgVFNWV0cgaGFzIGRlY2xhcmVkIGNvbnNlbnN1cyBvbiBhbmQg d3JvdGUgaW4gdGhlIGRvY3VtZW50IHRoYXQgcGFzc2VkIFdHIGxhc3QgY2FsbCBhbmQgaXMgY3Vy cmVudGx5IGluICJ3YWl0aW5nIGZvciB3cml0ZXVwIiBzdGF0ZS4NCg0KQ2hhbmdpbmcgdGhpcyBk ZXRlcm1pbmF0aW9uIHdvdWxkLCBhdCBtaW5pbXVtLCByZXF1aXJlIHJlb3BlbmluZyB0aGUgV0cg TGFzdCBDYWxsLg0KQW5kIEknZCBvYmplY3QuDQoNCkhhcmFsZA0KDQoNCkRlbiAxMC4gbWFpIDIw MTYgMDg6NTYsIHNrcmV2IFJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZToNCj4gSGkgUGF1bCwNCj4g DQo+IEkgdGhpbmsgd2UgYWdyZWUsIHRoYXQgYXVkaW8gYW5kIHZpZGVvIGZyYW1lcywgaWYgYm90 aCBhcmUgcGFydCBvZiB0aGUgDQo+IHNhbWUgKGludGVyYWN0aXZlKSBtZWRpYSBmbG93IHNob3Vs ZCBiZSB0cmFuc3BvcnRlZCBieSB0aGUgc2FtZSBQSEIgDQo+IFtQSl0gb3IgdGhlIHNhbWUgcXVl dWUgW1JHXS4gVGhlIGxhdHRlciBpcyBlbnN1cmVkLCBpZiB0aGUgc2FtZSBQSEIgaXMgDQo+IHBp Y2tlZCBmb3IgYXVkaW8gYW5kIHZpZGVvLiBUbyBtZSB0aGUgdGV4dCBvZiB0aGUgZHJhZnQgc28g ZmFyIGRvZXNuJ3QgDQo+IGV4cHJlc3MgdGhhdCBib3RoIGF1ZGlvIGFuZCB2aWRlbyBhcmUgc3Vw cG9zZWQgdG8gdXNlIGFuICJJbnRlcmFjdGl2ZSANCj4gVmlkZW8uLi4iIFBIQiwgaWYgYm90aCBh cmUgcHJlc2VudC4gSSdkIHByZWZlciB0byBoYXZlIHRleHQgd2l0aCBhIG5vbiANCj4gYmluZGlu ZyBzdGFuZGFyZCByZXF1aXJlbWVudCBzYXlpbmcNCj4gDQo+ICAgICAgSG93ZXZlciwgaWYgdGhl IGFwcGxpY2F0aW9uIHdpc2hlcyB0byBzZW5kIGJvdGggaW50ZXJhY3RpdmUgDQo+ICAgICAgdmlk ZW8gYW5kIGF1ZGlvLCBpdCBpcyBSRUNPTU1FTkRFRCB0byB0cmFuc3BvcnQgYXVkaW8gDQo+ICAg ICAgYW5kIHZpZGVvIHBhY2tldHMgYnkgdGhlIHNhbWUgcGVyIGhvcCBiZWhhdmlvci4gRm9yIGV4 YW1wbGUsIA0KPiAgICAgIGF1ZGlvIGFuZCB2aWRlbyBwYWNrZXRzIHdvdWxkIGJvdGggYmUgbWFy a2VkIGFzIEFGNDIgb3INCj4gICAgICBBRjQzLiANCj4gDQo+IEkgZG9uJ3QgaW5zaXN0IG9uIGRl c2NyaXB0aXZlIHRleHQgcHJvcG9zaW5nIHRvIHRyYW5zcG9ydCBhdWRpbyBieSBhbiBBRjQgUEhC IG9mZmVyaW5nIGEgbG93ZXIgZHJvcCByYXRpbyB0aGFuIHRoYXQgdXNlZCB0byB0cmFuc3BvcnQg dmlkZW8uIE15IGF1ZGlvL3ZpZGVvIGV4cGVydHMgc3VwcG9ydCB0aGlzIGFuZCBJJ20gcHJldHR5 IHN1cmUsIHRoYXQgYWxzbyBDaXNjbyByZXByZXNlbnRhdGl2ZXMgbWVudGlvbmVkIHRoYXQgYXVk aW8gcXVhbGl0eSByYW5rcyBhYm92ZSB2aWRlbyBxdWFsaXR5IGluIHRlbGVwcmVzZW5jZSBzZXNz aW9ucy4NCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBSdWVkaWdlcg0KPiANCj4gDQo+IC0tLS0tVXJz cHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCj4gVm9uOiBQYXVsIEUuIEpvbmVzIFttYWlsdG86 cGF1bGVqQHBhY2tldGl6ZXIuY29tXQ0KPiBHZXNlbmRldDogTW9udGFnLCA5LiBNYWkgMjAxNiAy MTowMw0KPiBBbjogR2VpYiwgUsO8ZGlnZXINCj4gQ2M6IGJyaWFuLmUuY2FycGVudGVyQGdtYWls LmNvbTsgZGF2aWQuYmxhY2tAZW1jLmNvbTsgdHN2d2dAaWV0Zi5vcmc7IA0KPiBydGN3ZWJAaWV0 Zi5vcmcNCj4gQmV0cmVmZjogUmU6IEFXOiBbdHN2d2ddIERpZmZzZXJ2IFFvUyBmb3IgVmlkZW8N Cj4gDQo+IFJ1ZWRpZ2VyLA0KPiANCj4gUGVyaGFwcyBhbiBleGFtcGxlIG1pZ2h0IGJlIGhlbHBm dWwuICBIb3cgYWJvdXQgSSBhZGQgdGhpcyB0ZXh0IGZvciBpbGx1c3RyYXRpdmUgcHVycG9zZXM/ DQo+IA0KPiAgICAgIFRvIGlsbHVzdHJhdGUgdGhlIHVzZSBvZiB0aGUgYWJvdmUgdGFibGUsIGxl dCB1cyBhc3N1bWUgdGhlDQo+ICAgICAgYXBwbGljYXRpb24gYXNzaWducyBhIHByaW9yaXR5IG9m ICJtZWRpdW0iIHRvIGF1ZGlvIGFuZCB2aWRlbw0KPiAgICAgIGZsb3dzLiAgR2l2ZW4gdGhhdCBh c3N1bXB0aW9uLCBpZiB0aGUgYXBwbGljYXRpb24gd2lzaGVzIHRvIHNlbmQNCj4gICAgICBvbmx5 IGF1ZGlvIHRoZW4gcGFja2V0cyB3b3VsZCBiZSBtYXJrZWQgRUYuICBIb3dldmVyLCBpZiB0aGUN Cj4gICAgICBhcHBsaWNhdGlvbiB3aXNoZXMgdG8gc2VuZCBib3RoIGludGVyYWN0aXZlIHZpZGVv IGFuZCBhdWRpbywNCj4gICAgICB0aGVuIGF1ZGlvIGFuZCB2aWRlbyBwYWNrZXRzIHdvdWxkIGJv dGggYmUgbWFya2VkIGFzIEFGNDIgb3INCj4gICAgICBBRjQzLiAgVGhlIGludGVudCBpcyB0byBl bnN1cmUgdGhhdCB3aGVuIGJvdGggYXVkaW8gYW5kIHZpZGVvDQo+ICAgICAgYXJlIGJlaW5nIHNl bnQgdG9nZXRoZXIgdGhhdCB0aGV5IHJlY2VpdmUgc2ltaWxhciBwZXItaG9wDQo+ICAgICAgYmVo YXZpb3IuDQo+IA0KPiBUaGlzIGRvZXNuJ3QgZ2V0IGludG8gdGhlIHByZWZlcmVuY2UgZm9yIEFG NDIgdnMuIEFGNDMuIElmIGl0IHdlcmUgbWUsIEknZCBtYXJrIGFsbCBhdWRpbyBhcyBBRjQyIGFu ZCBvbmx5IGtleSB2aWRlbyBmcmFtZXMgYXMgQUY0Mi4gIEFsbCBwcmVkaWN0aXZlIGZyYW1lcyB3 b3VsZCBiZSBzZW50IHdpdGggYW4gQUY0MyBtYXJraW5nLiAgSSBtaWdodCBldmVuIHRha2UgaXQg YSBzdGVwIGZ1cnRoZXIgYW5kIGNsYXNzaWZ5IGFsbCBhdWRpbyBhcyAiaGlnaCIuICBIb3dldmVy LCBJJ3ZlIHNlZW4gYSB0cmVtZW5kb3VzIGFtb3VudCBvZiBkZWJhdGUgb24gdGhpcyBiZWZvcmUs IHNvIEknZCBwcmVmZXIgdG8gbm90IGdvIHRvbyBmYXIgaW4gZGljdGF0aW5nIGF1ZGlvIG1hcmtp bmdzIHZzLiB2aWRlby4gIEkgZG8gdGhpbmsgbW9zdCBwZW9wbGUgZ2VuZXJhbGx5IGFncmVlIGFi b3V0IGF0IGxlYXN0IGVuc3VyaW5nIHRoZSBjbGFzcyBpcyB0aGUgc2FtZSwgb3RoZXJ3aXNlIHRo ZSB3aWxkbHkgZGlmZmVyZW50IFBIQiBpbnRyb2R1Y2VzIHNrZXcgYmV0d2VlbiBBL1YgcGFja2V0 IGFycml2YWwsIHRodXMgaW5mbGF0aW5nIHRoZSBzaXplIG9mIGJ1ZmZlcnMgbWFuYWdpbmcgdGhl IEEvViBzdHJlYW1zLiAgSG93ZXZlciwgd2UgZG8gbm90IHdhbnQgdG8gZGljdGF0ZSB0aGF0IGF1 ZGlvIHNob3VsZCBiZSB0cmVhdGVkIHNpZ25pZmljYW50bHkgYmV0dGVyIHRoYW4gYXVkaW8uICBG b3IgZGVhZiB1c2VycywgZm9yIGV4YW1wbGUsIHRoZSBhdWRpbyByZWFsbHkgaXNuJ3QgaW1wb3J0 YW50IGF0IGFsbC4gIFRoYXQgaXMgcGVyaGFwcyBhbiBleHRyZW1lIGV4YW1wbGUsIGJ1dCBpdCBu b25ldGhlbGVzcyBoaWdobGlnaHRzIHdoeSB3ZSBzaG91bGQgYmUgY2F1dGlvdXMgYWJvdXQgZXhh Y3RseSB3aGF0IHdlIG5vcm1hdGl2ZWx5IG1hbmRhdGUuDQo+IA0KPiBQYXVsDQo+IA0KPiAtLS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0NCj4gRnJvbTogUnVlZGlnZXIuR2VpYkB0ZWxla29t LmRlDQo+IFRvOiBwYXVsZWpAcGFja2V0aXplci5jb20NCj4gQ2M6IGJyaWFuLmUuY2FycGVudGVy QGdtYWlsLmNvbTsgZGF2aWQuYmxhY2tAZW1jLmNvbTsgdHN2d2dAaWV0Zi5vcmc7IA0KPiBydGN3 ZWJAaWV0Zi5vcmcNCj4gU2VudDogNS85LzIwMTYgMzozNDoyNSBBTQ0KPiBTdWJqZWN0OiBBVzog W3RzdndnXSBEaWZmc2VydiBRb1MgZm9yIFZpZGVvDQo+IA0KPj4gSGkgUGF1bCwNCj4+DQo+PiBJ J3ZlIHRhbGtlZCB3aXRoIGF1ZGlvL3ZpZGVvIGV4cGVydHMgb2YgRGV1dHNjaGUgVGVsZWtvbSBh bmQgdGhleSB0b28gDQo+PiBmYXZvcmVkIHdoYXQgeW91IHJlY29tbWVuZCBiZWxvdzogdHJhbnNw b3J0IGF1ZGlvIGFuZCB2aWRlbyBieSB0aGUgDQo+PiBzYW1lIHF1ZXVlLiBZb3VyIHN0YXRlbWVu dCBiZWxvdyBob3dldmVyIHN0b3BzIHRoZXJlIGFuZCB0aGUgZHJhZnQgDQo+PiB0ZXh0IGRvZXNu J3QgY2xhcmlmeSB0aGUgaXNzdWU6DQo+Pg0KPj4gSWYgdGhlcmUncyBpbnRlcmFjdGl2ZSB2aWRl byB3aXRoIGF1ZGlvLCB0aGVuIHRoZXkgYm90aCBzaG91bGQgYmUgDQo+PiBtYXJrZWQgZm9yIHRo ZSBzYW1lIFBIQiB3aGljaCBpczoNCj4+IC0gRUYgPw0KPj4gLSBBRjQ/IExpa2UgQUY0MSBBdWRp bywgQUY0MiBWaWRlbyAoQUY0MyBpbiBhZGRpdGlvbiwgaWYgUCBvciBCIA0KPj4gZnJhbWVzIGFy ZSB0byByZWNlaXZlIGEgbG93ZXIgcHJpb3JpdHkgLw0KPj4gICBoaWdoZXIgZHJvcCBwcmVjZWRl bmNlIFBIQik/DQo+Pg0KPj4gSSBwZXJzb25hbGx5IHByZWZlciBBRjQgaWYgYXVkaW8gYW5kIHZp ZGVvIGFyZSB0byBiZSB0cmFuc3BvcnRlZCBpbiANCj4+IHRoZSBzYW1lIHF1ZXVlLg0KPj4NCj4+ IEknZCBhbHNvIGFzayBmb3IgdGhlIGRyYWZ0IHRleHQgdG8gYmUgY2xlYXIgYWJvdXQgdGhlIGlz c3VlIHdoZW4gdG8gDQo+PiBtYXJrIGF1ZGlvIGJ5IHRoZSBFRiBQSEIuIE15IHVuZGVyc3RhbmRp bmcgYWZ0ZXIgcmVhZGluZyB5b3VyIA0KPj4gc3RhdGVtZW50IGJlbG93IGlzOiBBdWRpbyBtYXJr ZWQgRUYgaWYgdGhlcmUncyBubyB2aWRlbyBmbG93IG9ubHkuDQo+Pg0KPj4gLi4uDQo+PiBCQz5G aW5hbGx5LCB3aHkgaXMgYXVkaW8gbm90IGFsc28gc3ViZGl2aWRlZCBpbnRvIGludGVyYWN0aXZl IGFuZCANCj4+IEJDPm5vbi1pbnRlcmFjdGl2ZT8gQXMgZmFyIGFzIEkgY2FuIHNlZSwgYm90aCBh cmUgbG9naWNhbGx5IHBvc3NpYmxlLg0KPj4NCj4+IFtQSl0gRm9yIFdlYlJUQywgYXVkaW8gYWxv bmUgaXMgImludGVyYWN0aXZlIiBpbiBuYXR1cmUgKHdoaWNoIGlzDQo+PiAgIHdoeSBpdCdzIG1h cmtlZCBFRikuICBIb3dldmVyLCBpZiBvbmUgaXMgc2VuZGluZyBhdWRpbyBhbmQgdmlkZW8NCj4+ ICAgaXQgbWFrZXMgc2Vuc2UgdG8gbWFyayB0aGVtIGJvdGggc2FtZSB3YXkgdG8gZ2V0IHRoZSBz YW1lIFBIQiBhbmQNCj4+ICAgaG9wZWZ1bGx5IGhhdmUgdGhlbSBxdWV1ZWQgaW4gdGhlIHNhbWUg YnVmZmVycyBhbG9uZyB0aGUgcGF0aC4NCj4+ICAgU2VuZGluZyBhdWRpbyBhcyBFRiBhbmQgcG9z c2libHkgaGF2aW5nIGEgUEhCIHRoYXQgcmVzdWx0cyBpbg0KPj4gICBwYWNrZXRzIGFycml2aW5n IG11Y2ggZmFzdGVyIHRoYW4gY29ycmVzcG9uZGluZyB2aWRlbyBwYWNrZXRzDQo+PiAgIG1hcmtl ZCBhcyBBRjQyIGlzIG5vdCBhdCBhbGwgaGVscGZ1bCBmb3IgYXBwbGljYXRpb25zIHRoYXQgaGF2 ZQ0KPj4gICB0byBzeW5jaHJvbml6ZSB0aGUgYXVkaW8gYW5kIHZpZGVvIGZsb3dzLg0KPj4gLi4u DQo+Pg0KPj4gICBQYXVsDQo+Pg0KPj4NCj4+IFJlZ2FyZHMsDQo+Pg0KPj4gUnVlZGlnZXINCj4+ DQo+IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K cnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnDQpodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xp c3RpbmZvX3J0Y3dlYiZkPUN3SUdhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1JNGR6R3hS MzFPY05YQ0pmUXp2bHNpTFFmdWNCWFJ1Y1B2ZHJwaHBCc0ZBJm09TFJDamhRMHlFZWR6UkxnYVVt QjFQZnBHV2NKcy1yY3dMR2xGMUp3bUNVVSZzPVMxYzl6ZGdQdWFNNGNkTllnYmNDNE4xcjFWMkU0 TWlGU3N3aTFFRW1tVEUmZT0gDQo= From nobody Tue May 10 20:31: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 AD7E612D547; Tue, 10 May 2016 20:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, 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=packetizer.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 v302kFzzqgCM; Tue, 10 May 2016 20:31:34 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 DA20412B052; Tue, 10 May 2016 20:31:33 -0700 (PDT) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u4B3VPPV016696 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 May 2016 23:31:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1462937490; bh=pqawT0ItWap7Vn1fYJhwfU3DaZA9VYQd12jCokl2Hvg=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=mZv1hjdgXwN5dEw4ktug+9H5sFTXR5Obl04L+KcGPXkN6mG6aooLqRLOoz/T6OOtx I+JQ/zkzYbKg6zPV1ZscMBSZ2chkS9CxWC7ZlL4qsG25fSA3GrsTFecOSKaRqspEaF YpXNOyjxd2P8zj6rbiiUzfs5b0OuFc1WW2XpI0Ys= From: "Paul E. Jones" To: "Harald Alvestrand" , Ruediger.Geib@telekom.de Date: Wed, 11 May 2016 03:31:34 +0000 Message-Id: In-Reply-To: <57318F4E.4080102@alvestrand.no> User-Agent: eM_Client/6.0.24928.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.16 (dublin.packetizer.com [10.137.60.122]); Tue, 10 May 2016 23:31:30 -0400 (EDT) Archived-At: Cc: rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [rtcweb] [tsvwg] Diffserv QoS for Video X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Paul E. Jones" List-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, 11 May 2016 03:31:37 -0000 Yeah, that's a good point. Let's not go down the path of re-opening a=20 new round of changes that would require yet another LC and more time. Paul ------ Original Message ------ From: "Harald Alvestrand" To: Ruediger.Geib@telekom.de; paulej@packetizer.com Cc: rtcweb@ietf.org; tsvwg@ietf.org Sent: 5/10/2016 3:35:42 AM Subject: Re: [tsvwg] Diffserv QoS for Video >FTR: I don't see such an agreement at all. > >On the contrary, my perception is that people want the ability to >deliver audio with a lower loss probability and lower delay probability >than video - it's more important to the conversation, and there are >fewer things the recipient can do to hide the losses. If the sender >chose to send them on separate flows, they shold have different DSCP >markings. > >I believe this is what draft-ietf-tsvwg-rtcweb-qos-15 section 5 states, >and I believe that this is what TSVWG has declared consensus on and >wrote in the document that passed WG last call and is currently in >"waiting for writeup" state. > >Changing this determination would, at minimum, require reopening the WG >Last Call. >And I'd object. > >Harald > > >Den 10. mai 2016 08:56, skrev Ruediger.Geib@telekom.de: >> Hi Paul, >> >> I think we agree, that audio and video frames, if both are part of=20 >>the same (interactive) media flow should be transported by the same=20 >>PHB [PJ] or the same queue [RG]. The latter is ensured, if the same=20 >>PHB is picked for audio and video. To me the text of the draft so far=20 >>doesn't express that both audio and video are supposed to use an=20 >>"Interactive Video..." PHB, if both are present. I'd prefer to have=20 >>text with a non binding standard requirement saying >> >> However, if the application wishes to send both interactive >> video and audio, it is RECOMMENDED to transport audio >> and video packets by the same per hop behavior. For example, >> audio and video packets would both be marked as AF42 or >> AF43. >> >> I don't insist on descriptive text proposing to transport audio by an= =20 >>AF4 PHB offering a lower drop ratio than that used to transport video.= =20 >>My audio/video experts support this and I'm pretty sure, that also=20 >>Cisco representatives mentioned that audio quality ranks above video=20 >>quality in telepresence sessions. >> >> Regards, >> >> Ruediger >> >> >> -----Urspr=C3=BCngliche Nachricht----- >> Von: Paul E. Jones [mailto:paulej@packetizer.com] >> Gesendet: Montag, 9. Mai 2016 21:03 >> An: Geib, R=C3=BCdiger >> Cc: brian.e.carpenter@gmail.com; david.black@emc.com; tsvwg@ietf.org;= =20 >>rtcweb@ietf.org >> Betreff: Re: AW: [tsvwg] Diffserv QoS for Video >> >> Ruediger, >> >> Perhaps an example might be helpful. How about I add this text for=20 >>illustrative purposes? >> >> To illustrate the use of the above table, let us assume the >> application assigns a priority of "medium" to audio and video >> flows. Given that assumption, if the application wishes to send >> only audio then packets would be marked EF. However, if the >> application wishes to send both interactive video and audio, >> then audio and video packets would both be marked as AF42 or >> AF43. The intent is to ensure that when both audio and video >> are being sent together that they receive similar per-hop >> behavior. >> >> This doesn't get into the preference for AF42 vs. AF43. If it were=20 >>me, I'd mark all audio as AF42 and only key video frames as AF42. All= =20 >>predictive frames would be sent with an AF43 marking. I might even=20 >>take it a step further and classify all audio as "high". However,=20 >>I've seen a tremendous amount of debate on this before, so I'd prefer=20 >>to not go too far in dictating audio markings vs. video. I do think=20 >>most people generally agree about at least ensuring the class is the=20 >>same, otherwise the wildly different PHB introduces skew between A/V=20 >>packet arrival, thus inflating the size of buffers managing the A/V=20 >>streams. However, we do not want to dictate that audio should be=20 >>treated significantly better than audio. For deaf users, for example,= =20 >>the audio really isn't important at all. That is perhaps an extreme=20 >>example, but it nonetheless highlights why we should be cautious about= =20 >>exactly what we normatively mandate. >> >> Paul >> >> ------ Original Message ------ >> From: Ruediger.Geib@telekom.de >> To: paulej@packetizer.com >> Cc: brian.e.carpenter@gmail.com; david.black@emc.com; tsvwg@ietf.org;= =20 >>rtcweb@ietf.org >> Sent: 5/9/2016 3:34:25 AM >> Subject: AW: [tsvwg] Diffserv QoS for Video >> >>> Hi Paul, >>> >>> I've talked with audio/video experts of Deutsche Telekom and they=20 >>>too >>> favored what you recommend below: transport audio and video by the=20 >>>same >>> queue. Your statement below however stops there and the draft text >>> doesn't clarify the issue: >>> >>> If there's interactive video with audio, then they both should be >>> marked for the same PHB which is: >>> - EF ? >>> - AF4? Like AF41 Audio, AF42 Video (AF43 in addition, if P or B=20 >>>frames >>> are to receive a lower priority / >>> higher drop precedence PHB)? >>> >>> I personally prefer AF4 if audio and video are to be transported in= =20 >>>the >>> same queue. >>> >>> I'd also ask for the draft text to be clear about the issue when to >>> mark audio by the EF PHB. My understanding after reading your=20 >>>statement >>> below is: Audio marked EF if there's no video flow only. >>> >>> ... >>> BC>Finally, why is audio not also subdivided into interactive and >>> BC>non-interactive? As far as I can see, both are logically=20 >>>possible. >>> >>> [PJ] For WebRTC, audio alone is "interactive" in nature (which is >>> why it's marked EF). However, if one is sending audio and video >>> it makes sense to mark them both same way to get the same PHB and >>> hopefully have them queued in the same buffers along the path. >>> Sending audio as EF and possibly having a PHB that results in >>> packets arriving much faster than corresponding video packets >>> marked as AF42 is not at all helpful for applications that have >>> to synchronize the audio and video flows. >>> ... >>> >>> Paul >>> >>> >>> Regards, >>> >>> Ruediger >>> >> From nobody Wed May 11 08:55: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 B815C12D1EB for ; Wed, 11 May 2016 08:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 pFWZqcQqNTJZ for ; Wed, 11 May 2016 08:55:35 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8D3912D512 for ; Wed, 11 May 2016 08:55:34 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 30F381EB8496; Wed, 11 May 2016 17:55:33 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0279.002; Wed, 11 May 2016 17:55:32 +0200 From: "Hutton, Andrew" To: Philipp Hancke , "rtcweb@ietf.org" Thread-Topic: [rtcweb] which bandwidth modifiers need to be supported? Thread-Index: AQHRntQ2kVygUM+ne0GaC9s4SM+26Z+z8baA Date: Wed, 11 May 2016 15:55:31 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF260FFABF@MCHP04MSX.global-ad.net> References: <571DE213.8080306@goodadvice.pages.de> In-Reply-To: <571DE213.8080306@goodadvice.pages.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [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: Wed, 11 May 2016 15:55:37 -0000 I was also looking at this again my assumption is that TIAS is what a WebRT= C endpoint should generate TIAS as Philipp stated this is hinted at in the = W3C spec but probably also should be specified in JSEP and an example in ht= tps://tools.ietf.org/html/draft-ietf-rtcweb-sdp-01#section-5.2.2 would also= be useful. For parsing then both TIAS and AS needs to be supported this is specified i= n https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-14#section-5.8.=20 Regards Andy > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Philipp > Hancke > Sent: 25 April 2016 10:24 > To: rtcweb@ietf.org > Subject: [rtcweb] which bandwidth modifiers need to be supported? >=20 > which bandwidth modifiers for b=3D lines does a client need to support? >=20 > Chrome currently supports b=3DAS, however the implementation is closer to > TIAS semantically. Firefox does not implement either currently. >=20 > http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters- > maxBitrate > uses TIAS as a definition. >=20 > 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. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed May 11 09:40:30 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7565A12D09A for ; Wed, 11 May 2016 09:40:29 -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 9YXY_uWIkgoF for ; Wed, 11 May 2016 09:40:27 -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 8183B12B043 for ; Wed, 11 May 2016 09:40:27 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 0C5DD3B4753 for ; Wed, 11 May 2016 18:40:26 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.61]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id E735E35C05A for ; Wed, 11 May 2016 18:40:25 +0200 (CEST) Received: from OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0294.000; Wed, 11 May 2016 18:40:25 +0200 From: To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] On ICE improvement / Switching Between Pairs Based on RTT Thread-Index: AdGrnkrp7cI9TydpTh23sxm4WUHMFw== Date: Wed, 11 May 2016 16:40:25 +0000 Message-ID: <13750_1462984825_57336079_13750_4446_1_F9B5455F58DAFA47BC202D5C02C2BB2E09680705@OPEXCLILM22.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.3] Content-Type: text/plain; charset="us-ascii" 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.5.11.161517 Archived-At: Subject: [rtcweb] On ICE improvement / Switching Between Pairs Based on RTT 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, 11 May 2016 16:40:29 -0000 Dear all,=20 I am studying delay reduction between WebRTC pairs and TURN servers.=20 This draft https://tools.ietf.org/html/draft-uberti-mmusic-nombis-00#page-9= on ICE improvement mentions :=20 Switching Between Pairs Based on RTT and Switching To A New TURN Server as = examples.=20 Does anyone have more information about any concrete measurements about the= se aspects?=20 Thank you=20 Regards Amina Boubendir _______________________________________________ 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 May 11 13:54: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 1B2C112D50B for ; Wed, 11 May 2016 13:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 z-foj4pCYxbI for ; Wed, 11 May 2016 13:54:24 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 127C212B038 for ; Wed, 11 May 2016 13:54:23 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.16.0.17/8.16.0.17) with SMTP id u4BKrMc1007605; Wed, 11 May 2016 16:54:16 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 22vas412sh-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Wed, 11 May 2016 16:54:16 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc10.cis.neustar.com ([169.254.4.235]) with mapi id 14.03.0279.002; Wed, 11 May 2016 16:54:16 -0400 From: "Peterson, Jon" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] RTCWeb and STIR Thread-Index: AQHRqjHPcniNxw+EFUKqnnViZRV4Yp+yB8SAgAIAGYA= Date: Wed, 11 May 2016 20:54:15 +0000 Message-ID: References: <1D53717F-3679-4E9C-B612-FA75BFF13032@iii.ca> <57318BF1.4050006@alvestrand.no> In-Reply-To: <57318BF1.4050006@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.151] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-11_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1605110276 Archived-At: Cc: "Wendt, Chris" Subject: Re: [rtcweb] RTCWeb and STIR 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, 11 May 2016 20:54:26 -0000 STIR is planning on moving the fingerprint syntax to a JSON array anyway. I think we could easily get the PASSporT object aligned with the syntax in rtcweb-security-arch 5.6.4. So I think the fixes in 3.2 can probably be made - though I agree (per 3.7) we should try to make the encoding of the digest as compact as we can across the two mechanisms, which might warrant some more discussion. The really interesting interworking question, as Cullen's draft suggests, is how to prevent the "grossness" that results from the fact that STIR today carries its identity assertion in a SIP header, whereas WebRTC carries its assertion as an SDP attribute. The last thing we'd want is to do both redunantly. It does look like, provided we can get fingerprints into alignment, it would at least be possible to translate the SDP attribute into a SIP header and vice versa. A number of the smaller fixes that Cullen proposes for WebRTC seem like they could be helpful: as some are just adding extensions to the existing a=3Didentity attribute, which the rtcweb-security-arch spec allows, so much of that is painless. Support for multiple identity assertions in one SDP session seems like it would be valuable for non-STIR IdP use cases even. Questions like Cullen's 3.3.3, whether or not it would be better to break the domain and protocol out of the base64 encoded assertion, are things that would be nice to have, though I imagine people are reluctant to reopen rtcweb-security-arch at this point. Most of the questions about the identifiers carried in the assertion are cases where, at least on the PASSporT side, extensibility should be able to take care of them. The 3.6 question of whether identity should focus on RFC822-style names versus URIs is an interesting one: I'd venture it would be perfectly valid to define a PASSporT claim type for those, in addition to having URIs and telephone numbers as options (also, there's already a baseline JWS "email" claim that might serve). Per 3.9, I've been imagining a PASSporT extension specifically for conferencing architectures - possibly more than one will be required, to support centralized vs. mesh. This is a very handy document to have though, I think I understand the interworking story a lot better than I did before. Jon Peterson Neustar, Inc. On 5/10/16, 12:21 AM, "rtcweb on behalf of Harald Alvestrand" wrote: >Den 09. mai 2016 22:31, skrev Cullen Jennings: >>=20 >>=20 >> I've been looking at how WebRTC Identity and STIR work together and put >>together a worked out example at >>=20 >> http://www.ietf.org/id/draft-jennings-stir-rtcweb-identity-00.txt >>=20 >> It does not propose any significant changes to WebRTC but it does point >>at a few syntax changes that might make things easier. >>=20 >> Probably the key change for RTCWeb would be to unify the syntax we use >>for DTLS-SRTP fingerprints. > > >The fingerprint syntax comes from SDP/DTLS, not from RTCWeb, I believe. > >It might be best for STIR to either get with the party or propose an SDP >change for DTLS. > >> _______________________________________________ >> 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 Wed May 11 17:19: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 3C18512D83E; Wed, 11 May 2016 17:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.317 X-Spam-Level: X-Spam-Status: No, score=-5.317 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 jdrtTLrR_53v; Wed, 11 May 2016 17:19:36 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 DAF7512D82C; Wed, 11 May 2016 17:19:35 -0700 (PDT) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u4C0JUtG024323 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 11 May 2016 20:19:31 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u4C0JUtG024323 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1463012372; bh=BqDu5Atl8pJ2nYVlxs0lJzBudsg=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=wYUTyRmKvZkb/l/zq3p45+zGAUNGxSf/wKHrcJo5x/eiHYsjpq/T3YX9IJrbMKJrX 47Qd3ADZLwJPXXgtHNCNPlY/RNxYo0jEb8xeCs0vg97PsEB/6Qrd6CQAldVwB5PW18 DDzyDW0P8g69F5WUXMYJHZKHt2M7EwpupiQIX3Hg= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u4C0JUtG024323 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd53.lss.emc.com (RSA Interceptor); Wed, 11 May 2016 20:19:12 -0400 Received: from MXHUB107.corp.emc.com (MXHUB107.corp.emc.com [10.253.50.23]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u4C0JAZH008059 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 May 2016 20:19:11 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.9]) by MXHUB107.corp.emc.com ([10.253.50.23]) with mapi id 14.03.0266.001; Wed, 11 May 2016 20:19:10 -0400 From: "Black, David" To: "Ruediger.Geib@telekom.de" , "harald@alvestrand.no" Thread-Topic: [tsvwg] Diffserv QoS for Video Thread-Index: AQHRqo6WRFo/t41+4kaEDRul9pWaip+yFwIAgAJZMuA= Date: Thu, 12 May 2016 00:19:09 +0000 Message-ID: References: <828773FE19B05B4581311493A046E85E6ECC3084D0@HE111642.emea1.cds.t-internal.com> <828773FE19B05B4581311493A046E85E6ECC4090FD@HE111642.emea1.cds.t-internal.com> <57318F4E.4080102@alvestrand.no> <828773FE19B05B4581311493A046E85E6ECC409176@HE111642.emea1.cds.t-internal.com> In-Reply-To: <828773FE19B05B4581311493A046E85E6ECC409176@HE111642.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.38.107] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Black, David" , "rtcweb@ietf.org" , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] Diffserv QoS for Video 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, 12 May 2016 00:19:39 -0000 PiBJJ20gd29ya2luZyBvbiB0cmFuc3BvcnQgb25seSBhbmQgbXkgcnRjd2ViIGlucHV0IGlzIGRy YWZ0LWlldGYtdHN2d2ctcnRjd2ViLQ0KPiBxb3MtMTUuIEl0IHN0YXRlcyBsaXR0bGUgZm9yIGF1 ZGllbmNlIGxpa2UgbWUsIGlmIHRoZSBzdWJqZWN0IGlzIGF1ZGlvIGFuZCB2aWRlbw0KPiByZWxh dGVkIHRvIGEgdGFsa2luZyBwZXJzb24uIEkgdGhpbmsgdGhlIHJlbGV2YW50IHN0YXRlbWVudCBh cmUgbGluZXMgaW4gYSB0YWJsZS4gSSdkDQo+IGFwcHJlY2lhdGUgdGV4dCBoZWxwaW5nIHdpdGgg dGhlIGludGVycHJldGF0aW9uIG9mIHRhYmxlLiBJZiB3ZSBjYW4ndCBhZ3JlZSBvbg0KPiB1c2Vm dWwgdGV4dCAtIGxlYXZlIGl0IGFzIGlzLg0KDQpBcyBkcmFmdCBzaGVwaGVyZCwgSSB0aGluayB0 aGUgdGFibGUgdGV4dCBpcyBvayBhcy1pczsgb3RoZXIgV2ViUlRDIHNwZWNzIG93bg0KdGhlIGRl ZmluaXRpb24gb2Ygd2hhdCBhIG1lZGlhIGZsb3cgaXMsIGFuZCBvbmUgb2YgdGhlbSB3b3VsZCBi ZSB0aGUgYXBwcm9wcmlhdGUNCmxvY2F0aW9uIGZvciB0ZXh0IChpZiBhcHByb3ByaWF0ZSkgdG8g cG9pbnQgb3V0IHRoYXQgYXVkaW8gZm9yIHZpZGVvIGNvdWxkIGJlIHNlbnQNCm9uIHRoZSBzYW1l IG9yIGRpZmZlcmVudCBvciBkaWZmZXJlbnQgbWVkaWEgZmxvdyBhcyB0aGUgdmlkZW8uICAgQW1v bmcgdGhlIHJlYXNvbnMNCmZvciB0aGlzIGlzIHRoYXQgZGVjaWRpbmcgd2hldGhlciB0byB1c2Ug b25lIG9yIHR3byBtZWRpYSBmbG93cyBoYXMgUlRQIGltcGFjdHMNCnRoYXQgb2NjdXIgd2VsbCBi ZWZvcmUgRFNDUCBhc3NpZ25tZW50IHRvIG91dGJvdW5kIHRyYWZmaWMuDQoNCkFsc28sIGluIGFk ZGl0aW9uIHRvIHRoZSAtMTYgdmVyc2lvbiBvZiB0aGUgV2ViUlRDIFFvUyBkcmFmdCB0aGF0IHdh cyBqdXN0IHVwbG9hZGVkLA0KSSd2ZSBlZGl0ZWQgdGhhdCBkcmFmdCdzIHNoZXBoZXJkIHdyaXRl dXAgdG8gcmVmbGVjdCB0aGUgcmVzb2x1dGlvbiBvZiB0aGUgaXNzdWUgYXJvdW5kDQppbnRlcmFj dGl2ZSB2cy4gbm9uLWludGVyYWN0aXZlIHZpZGVvLCBpbmNsdWRpbmcgcmVjb3JkaW5nIHRoZSBl eHBlY3RhdGlvbiB0aGF0DQp0aGVyZSB3aWxsIGJlIHNvbWUgYWRkaXRpb25hbCB0ZXh0IG9uIHRo aXMgdG9waWMgaW4gdGhlIG5leHQgdmVyc2lvbiBvZiB0aGUgV2ViUlRDDQpUcmFuc3BvcnRzICBk cmFmdC4NCg0KVGhhbmtzLCAtLURhdmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogdHN2d2cgW21haWx0bzp0c3Z3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YNCj4gUnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlDQo+IFNlbnQ6IFR1ZXNkYXksIE1heSAxMCwg MjAxNiA0OjE5IEFNDQo+IFRvOiBoYXJhbGRAYWx2ZXN0cmFuZC5ubw0KPiBDYzogcnRjd2ViQGll dGYub3JnOyB0c3Z3Z0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3RzdndnXSBEaWZmc2VydiBR b1MgZm9yIFZpZGVvDQo+IA0KPiBIaSBIYXJhbGQsDQo+IA0KPiBXZSBzaG91bGQgYXZvaWQgdG8g cmUtb3BlbiBsYXN0IGNhbGwuIFRoYXQncyBub3QgbXkgaW50ZW50Lg0KPiANCj4gSSdtIHdvcmtp bmcgb24gdHJhbnNwb3J0IG9ubHkgYW5kIG15IHJ0Y3dlYiBpbnB1dCBpcyBkcmFmdC1pZXRmLXRz dndnLXJ0Y3dlYi0NCj4gcW9zLTE1LiBJdCBzdGF0ZXMgbGl0dGxlIGZvciBhdWRpZW5jZSBsaWtl IG1lLCBpZiB0aGUgc3ViamVjdCBpcyBhdWRpbyBhbmQgdmlkZW8NCj4gcmVsYXRlZCB0byBhIHRh bGtpbmcgcGVyc29uLiBJIHRoaW5rIHRoZSByZWxldmFudCBzdGF0ZW1lbnQgYXJlIGxpbmVzIGlu IGEgdGFibGUuIEknZA0KPiBhcHByZWNpYXRlIHRleHQgaGVscGluZyB3aXRoIHRoZSBpbnRlcnBy ZXRhdGlvbiBvZiB0YWJsZS4gSWYgd2UgY2FuJ3QgYWdyZWUgb24NCj4gdXNlZnVsIHRleHQgLSBs ZWF2ZSBpdCBhcyBpcy4NCj4gDQo+IEEgYmFja2JvbmUgc3VwcG9ydGluZyBSVFAgYmFzZWQgVFYg ZGlzdHJpYnV0aW9uIHRlbmRzIHRvIGJlIGVuZ2luZWVyZWQgZm9yDQo+IHN1cHBvcnQgb2YgYW4g QUY0IGxpa2UgUW9TIGNsYXNzIGZvciBsb3cgbG9zcy4gSSB0aGluaywgdGVsZXBob255IGNvZGVj cywgd2hvc2UNCj4gUlRQIHN0cmVhbXMgd2lsbCBiZSB0cmFuc3BvcnRlZCBieSBFRiwgYXJlIGFi bGUgdG8gZGVhbCB3aXRoIGhpZ2hlciBwYWNrZXQgbG9zcywNCj4gdGhhbiBtdWx0aWNhc3QgYmFz ZWQgSVBUVi4NCj4gDQo+IFRvIG1lLCBhbiBhdWRpbyBvciB0ZWxlcHJlc2VuY2UvdmlkZW9jb25m ZXJlbmNlIGNhbGwgd2l0aCBRb1MgcmVxdWlyZQ0KPiBhZG1pc3Npb24gY29udHJvbC4gVGhpcyBl bnN1cmVzIHRoYXQgdGhleSBhcmUgdHJhbnNwb3J0ZWQgd2l0aG91dCBxdWV1aW5nIG9yDQo+IGRy b3BzLg0KPiANCj4gSWYgdGhlcmUncyBjb25nZXN0aW9uIGhvd2V2ZXI6DQo+IA0KPiBBbiBhdWRp byBmbG93IG1hcmtlZCBBRjQxIHNob3VsZCBmYWNlIGEgbG93ZXIgZHJvcCByYXRlIHRoYW4gYSB2 aWRlbyBmbG93DQo+IG1hcmtlZCBBRjQyIGluIHRoZSBjYXNlIG9mIGNvbmdlc3Rpb24gYXQgYW4g bmV0d29yayBlZGdlIG5vZGUuIFRoZSBwYWNrZXRzDQo+IGFycml2ZSBpbiB0aGUgc2FtZSBvcmRl ciBhcyB0aGV5IHdlcmUgc2VudCAoaW5kZXBlbmRlbnQgb2YgdGhlIGZsb3cgdGhleSBiZWxvbmcN Cj4gdG8pLg0KPiANCj4gQW4gRUYgbWFya2VkIGF1ZGlvIGZsb3cgbWF5IGV4cGVyaWVuY2UgbG9z cyBldmVudHMgaW5kZXBlbmRlbnQgZnJvbSBhIHZpZGVvDQo+IGZsb3cgbWFya2VkIEFGNHguIElu IHRoZSBjYXNlIG9mIHF1ZXVpbmcsIG9uZSBvZiB0aGUgZmxvd3Mgd2lsbCBiZSBlYXJsaWVyLiBJ ZiBib3RoDQo+IGFyZSB0cmFuc3BvcnRlZCBieSBRb1MgY2xhc3NlcyBvcHRpbWl6ZWQgZm9yIHJ0 cC91ZHAgdHJhbnNwb3J0LCB0aGUgZGlmZmVyZW5jZSBpcw0KPiBhIGZldyBbbXNdIHBlciBjb25n ZXN0aW9uIHBvaW50LiBJZiBvbmUgb2YgdGhlIHF1ZXVlcyBpcyBvcHRpbWl6ZWQgZm9yIGdlbmVy YWwNCj4gZGF0YSB0cmFuc3BvcnQsIHRoZSBkZWxheSBkaWZmZXJlbmNlIGlzIGxpa2VseSB0byBi ZSBhIGRvdWJsZSBkaWdpdCBbbXNdIG51bWJlci4NCj4gVGhlIHBhY2tldHMgb2YgZWFjaCBmbG93 IGFycml2ZSBpbiBvcmRlciBhcyBzZW50LCB0aGUgcGFja2V0cyBvZiBvbmUgZmxvdyBhcmUNCj4g ZGVsYXllZCBhZ2FpbnN0IHRob3NlIG9mIHRoZSBvdGhlci4NCj4gDQo+IFJlZ2FyZHMsDQo+IA0K PiBSdWVkaWdlcg0KPiANCj4gLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KPiBW b246IEhhcmFsZCBBbHZlc3RyYW5kIFttYWlsdG86aGFyYWxkQGFsdmVzdHJhbmQubm9dDQo+IEdl c2VuZGV0OiBEaWVuc3RhZywgMTAuIE1haSAyMDE2IDA5OjM2DQo+IEFuOiBHZWliLCBSw7xkaWdl cjsgcGF1bGVqQHBhY2tldGl6ZXIuY29tDQo+IENjOiBydGN3ZWJAaWV0Zi5vcmc7IHRzdndnQGll dGYub3JnDQo+IEJldHJlZmY6IFJlOiBbdHN2d2ddIERpZmZzZXJ2IFFvUyBmb3IgVmlkZW8NCj4g DQo+IEZUUjogSSBkb24ndCBzZWUgc3VjaCBhbiBhZ3JlZW1lbnQgYXQgYWxsLg0KPiANCj4gT24g dGhlIGNvbnRyYXJ5LCBteSBwZXJjZXB0aW9uIGlzIHRoYXQgcGVvcGxlIHdhbnQgdGhlIGFiaWxp dHkgdG8gZGVsaXZlciBhdWRpbw0KPiB3aXRoIGEgbG93ZXIgbG9zcyBwcm9iYWJpbGl0eSBhbmQg bG93ZXIgZGVsYXkgcHJvYmFiaWxpdHkgdGhhbiB2aWRlbyAtIGl0J3MgbW9yZQ0KPiBpbXBvcnRh bnQgdG8gdGhlIGNvbnZlcnNhdGlvbiwgYW5kIHRoZXJlIGFyZSBmZXdlciB0aGluZ3MgdGhlIHJl Y2lwaWVudCBjYW4gZG8gdG8NCj4gaGlkZSB0aGUgbG9zc2VzLiBJZiB0aGUgc2VuZGVyIGNob3Nl IHRvIHNlbmQgdGhlbSBvbiBzZXBhcmF0ZSBmbG93cywgdGhleSBzaG9sZA0KPiBoYXZlIGRpZmZl cmVudCBEU0NQIG1hcmtpbmdzLg0KPiANCj4gSSBiZWxpZXZlIHRoaXMgaXMgd2hhdCBkcmFmdC1p ZXRmLXRzdndnLXJ0Y3dlYi1xb3MtMTUgc2VjdGlvbiA1IHN0YXRlcywgYW5kIEkNCj4gYmVsaWV2 ZSB0aGF0IHRoaXMgaXMgd2hhdCBUU1ZXRyBoYXMgZGVjbGFyZWQgY29uc2Vuc3VzIG9uIGFuZCB3 cm90ZSBpbiB0aGUNCj4gZG9jdW1lbnQgdGhhdCBwYXNzZWQgV0cgbGFzdCBjYWxsIGFuZCBpcyBj dXJyZW50bHkgaW4gIndhaXRpbmcgZm9yIHdyaXRldXAiIHN0YXRlLg0KPiANCj4gQ2hhbmdpbmcg dGhpcyBkZXRlcm1pbmF0aW9uIHdvdWxkLCBhdCBtaW5pbXVtLCByZXF1aXJlIHJlb3BlbmluZyB0 aGUgV0cgTGFzdA0KPiBDYWxsLg0KPiBBbmQgSSdkIG9iamVjdC4NCj4gDQo+IEhhcmFsZA0KPiAN Cj4gDQo+IERlbiAxMC4gbWFpIDIwMTYgMDg6NTYsIHNrcmV2IFJ1ZWRpZ2VyLkdlaWJAdGVsZWtv bS5kZToNCj4gPiBIaSBQYXVsLA0KPiA+DQo+ID4gSSB0aGluayB3ZSBhZ3JlZSwgdGhhdCBhdWRp byBhbmQgdmlkZW8gZnJhbWVzLCBpZiBib3RoIGFyZSBwYXJ0IG9mIHRoZQ0KPiA+IHNhbWUgKGlu dGVyYWN0aXZlKSBtZWRpYSBmbG93IHNob3VsZCBiZSB0cmFuc3BvcnRlZCBieSB0aGUgc2FtZSBQ SEINCj4gPiBbUEpdIG9yIHRoZSBzYW1lIHF1ZXVlIFtSR10uIFRoZSBsYXR0ZXIgaXMgZW5zdXJl ZCwgaWYgdGhlIHNhbWUgUEhCIGlzDQo+ID4gcGlja2VkIGZvciBhdWRpbyBhbmQgdmlkZW8uIFRv IG1lIHRoZSB0ZXh0IG9mIHRoZSBkcmFmdCBzbyBmYXIgZG9lc24ndA0KPiA+IGV4cHJlc3MgdGhh dCBib3RoIGF1ZGlvIGFuZCB2aWRlbyBhcmUgc3VwcG9zZWQgdG8gdXNlIGFuICJJbnRlcmFjdGl2 ZQ0KPiA+IFZpZGVvLi4uIiBQSEIsIGlmIGJvdGggYXJlIHByZXNlbnQuIEknZCBwcmVmZXIgdG8g aGF2ZSB0ZXh0IHdpdGggYSBub24NCj4gPiBiaW5kaW5nIHN0YW5kYXJkIHJlcXVpcmVtZW50IHNh eWluZw0KPiA+DQo+ID4gICAgICBIb3dldmVyLCBpZiB0aGUgYXBwbGljYXRpb24gd2lzaGVzIHRv IHNlbmQgYm90aCBpbnRlcmFjdGl2ZQ0KPiA+ICAgICAgdmlkZW8gYW5kIGF1ZGlvLCBpdCBpcyBS RUNPTU1FTkRFRCB0byB0cmFuc3BvcnQgYXVkaW8NCj4gPiAgICAgIGFuZCB2aWRlbyBwYWNrZXRz IGJ5IHRoZSBzYW1lIHBlciBob3AgYmVoYXZpb3IuIEZvciBleGFtcGxlLA0KPiA+ICAgICAgYXVk aW8gYW5kIHZpZGVvIHBhY2tldHMgd291bGQgYm90aCBiZSBtYXJrZWQgYXMgQUY0MiBvcg0KPiA+ ICAgICAgQUY0My4NCj4gPg0KPiA+IEkgZG9uJ3QgaW5zaXN0IG9uIGRlc2NyaXB0aXZlIHRleHQg cHJvcG9zaW5nIHRvIHRyYW5zcG9ydCBhdWRpbyBieSBhbiBBRjQgUEhCDQo+IG9mZmVyaW5nIGEg bG93ZXIgZHJvcCByYXRpbyB0aGFuIHRoYXQgdXNlZCB0byB0cmFuc3BvcnQgdmlkZW8uIE15IGF1 ZGlvL3ZpZGVvDQo+IGV4cGVydHMgc3VwcG9ydCB0aGlzIGFuZCBJJ20gcHJldHR5IHN1cmUsIHRo YXQgYWxzbyBDaXNjbyByZXByZXNlbnRhdGl2ZXMNCj4gbWVudGlvbmVkIHRoYXQgYXVkaW8gcXVh bGl0eSByYW5rcyBhYm92ZSB2aWRlbyBxdWFsaXR5IGluIHRlbGVwcmVzZW5jZSBzZXNzaW9ucy4N Cj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4NCj4gPiBSdWVkaWdlcg0KPiA+DQo+ID4NCj4gPiAtLS0t LVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQo+ID4gVm9uOiBQYXVsIEUuIEpvbmVzIFtt YWlsdG86cGF1bGVqQHBhY2tldGl6ZXIuY29tXQ0KPiA+IEdlc2VuZGV0OiBNb250YWcsIDkuIE1h aSAyMDE2IDIxOjAzDQo+ID4gQW46IEdlaWIsIFLDvGRpZ2VyDQo+ID4gQ2M6IGJyaWFuLmUuY2Fy cGVudGVyQGdtYWlsLmNvbTsgZGF2aWQuYmxhY2tAZW1jLmNvbTsgdHN2d2dAaWV0Zi5vcmc7DQo+ ID4gcnRjd2ViQGlldGYub3JnDQo+ID4gQmV0cmVmZjogUmU6IEFXOiBbdHN2d2ddIERpZmZzZXJ2 IFFvUyBmb3IgVmlkZW8NCj4gPg0KPiA+IFJ1ZWRpZ2VyLA0KPiA+DQo+ID4gUGVyaGFwcyBhbiBl eGFtcGxlIG1pZ2h0IGJlIGhlbHBmdWwuICBIb3cgYWJvdXQgSSBhZGQgdGhpcyB0ZXh0IGZvciBp bGx1c3RyYXRpdmUNCj4gcHVycG9zZXM/DQo+ID4NCj4gPiAgICAgIFRvIGlsbHVzdHJhdGUgdGhl IHVzZSBvZiB0aGUgYWJvdmUgdGFibGUsIGxldCB1cyBhc3N1bWUgdGhlDQo+ID4gICAgICBhcHBs aWNhdGlvbiBhc3NpZ25zIGEgcHJpb3JpdHkgb2YgIm1lZGl1bSIgdG8gYXVkaW8gYW5kIHZpZGVv DQo+ID4gICAgICBmbG93cy4gIEdpdmVuIHRoYXQgYXNzdW1wdGlvbiwgaWYgdGhlIGFwcGxpY2F0 aW9uIHdpc2hlcyB0byBzZW5kDQo+ID4gICAgICBvbmx5IGF1ZGlvIHRoZW4gcGFja2V0cyB3b3Vs ZCBiZSBtYXJrZWQgRUYuICBIb3dldmVyLCBpZiB0aGUNCj4gPiAgICAgIGFwcGxpY2F0aW9uIHdp c2hlcyB0byBzZW5kIGJvdGggaW50ZXJhY3RpdmUgdmlkZW8gYW5kIGF1ZGlvLA0KPiA+ICAgICAg dGhlbiBhdWRpbyBhbmQgdmlkZW8gcGFja2V0cyB3b3VsZCBib3RoIGJlIG1hcmtlZCBhcyBBRjQy IG9yDQo+ID4gICAgICBBRjQzLiAgVGhlIGludGVudCBpcyB0byBlbnN1cmUgdGhhdCB3aGVuIGJv dGggYXVkaW8gYW5kIHZpZGVvDQo+ID4gICAgICBhcmUgYmVpbmcgc2VudCB0b2dldGhlciB0aGF0 IHRoZXkgcmVjZWl2ZSBzaW1pbGFyIHBlci1ob3ANCj4gPiAgICAgIGJlaGF2aW9yLg0KPiA+DQo+ ID4gVGhpcyBkb2Vzbid0IGdldCBpbnRvIHRoZSBwcmVmZXJlbmNlIGZvciBBRjQyIHZzLiBBRjQz LiBJZiBpdCB3ZXJlIG1lLCBJJ2QgbWFyayBhbGwNCj4gYXVkaW8gYXMgQUY0MiBhbmQgb25seSBr ZXkgdmlkZW8gZnJhbWVzIGFzIEFGNDIuICBBbGwgcHJlZGljdGl2ZSBmcmFtZXMgd291bGQgYmUN Cj4gc2VudCB3aXRoIGFuIEFGNDMgbWFya2luZy4gIEkgbWlnaHQgZXZlbiB0YWtlIGl0IGEgc3Rl cCBmdXJ0aGVyIGFuZCBjbGFzc2lmeSBhbGwNCj4gYXVkaW8gYXMgImhpZ2giLiAgSG93ZXZlciwg SSd2ZSBzZWVuIGEgdHJlbWVuZG91cyBhbW91bnQgb2YgZGViYXRlIG9uIHRoaXMNCj4gYmVmb3Jl LCBzbyBJJ2QgcHJlZmVyIHRvIG5vdCBnbyB0b28gZmFyIGluIGRpY3RhdGluZyBhdWRpbyBtYXJr aW5ncyB2cy4gdmlkZW8uICBJIGRvDQo+IHRoaW5rIG1vc3QgcGVvcGxlIGdlbmVyYWxseSBhZ3Jl ZSBhYm91dCBhdCBsZWFzdCBlbnN1cmluZyB0aGUgY2xhc3MgaXMgdGhlIHNhbWUsDQo+IG90aGVy d2lzZSB0aGUgd2lsZGx5IGRpZmZlcmVudCBQSEIgaW50cm9kdWNlcyBza2V3IGJldHdlZW4gQS9W IHBhY2tldCBhcnJpdmFsLA0KPiB0aHVzIGluZmxhdGluZyB0aGUgc2l6ZSBvZiBidWZmZXJzIG1h bmFnaW5nIHRoZSBBL1Ygc3RyZWFtcy4gIEhvd2V2ZXIsIHdlIGRvIG5vdA0KPiB3YW50IHRvIGRp Y3RhdGUgdGhhdCBhdWRpbyBzaG91bGQgYmUgdHJlYXRlZCBzaWduaWZpY2FudGx5IGJldHRlciB0 aGFuIGF1ZGlvLiAgRm9yDQo+IGRlYWYgdXNlcnMsIGZvciBleGFtcGxlLCB0aGUgYXVkaW8gcmVh bGx5IGlzbid0IGltcG9ydGFudCBhdCBhbGwuICBUaGF0IGlzIHBlcmhhcHMgYW4NCj4gZXh0cmVt ZSBleGFtcGxlLCBidXQgaXQgbm9uZXRoZWxlc3MgaGlnaGxpZ2h0cyB3aHkgd2Ugc2hvdWxkIGJl IGNhdXRpb3VzIGFib3V0DQo+IGV4YWN0bHkgd2hhdCB3ZSBub3JtYXRpdmVseSBtYW5kYXRlLg0K PiA+DQo+ID4gUGF1bA0KPiA+DQo+ID4gLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tDQo+ ID4gRnJvbTogUnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlDQo+ID4gVG86IHBhdWxlakBwYWNrZXRp emVyLmNvbQ0KPiA+IENjOiBicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb207IGRhdmlkLmJsYWNr QGVtYy5jb207IHRzdndnQGlldGYub3JnOw0KPiA+IHJ0Y3dlYkBpZXRmLm9yZw0KPiA+IFNlbnQ6 IDUvOS8yMDE2IDM6MzQ6MjUgQU0NCj4gPiBTdWJqZWN0OiBBVzogW3RzdndnXSBEaWZmc2VydiBR b1MgZm9yIFZpZGVvDQo+ID4NCj4gPj4gSGkgUGF1bCwNCj4gPj4NCj4gPj4gSSd2ZSB0YWxrZWQg d2l0aCBhdWRpby92aWRlbyBleHBlcnRzIG9mIERldXRzY2hlIFRlbGVrb20gYW5kIHRoZXkgdG9v DQo+ID4+IGZhdm9yZWQgd2hhdCB5b3UgcmVjb21tZW5kIGJlbG93OiB0cmFuc3BvcnQgYXVkaW8g YW5kIHZpZGVvIGJ5IHRoZQ0KPiA+PiBzYW1lIHF1ZXVlLiBZb3VyIHN0YXRlbWVudCBiZWxvdyBo b3dldmVyIHN0b3BzIHRoZXJlIGFuZCB0aGUgZHJhZnQNCj4gPj4gdGV4dCBkb2Vzbid0IGNsYXJp ZnkgdGhlIGlzc3VlOg0KPiA+Pg0KPiA+PiBJZiB0aGVyZSdzIGludGVyYWN0aXZlIHZpZGVvIHdp dGggYXVkaW8sIHRoZW4gdGhleSBib3RoIHNob3VsZCBiZQ0KPiA+PiBtYXJrZWQgZm9yIHRoZSBz YW1lIFBIQiB3aGljaCBpczoNCj4gPj4gLSBFRiA/DQo+ID4+IC0gQUY0PyBMaWtlIEFGNDEgQXVk aW8sIEFGNDIgVmlkZW8gKEFGNDMgaW4gYWRkaXRpb24sIGlmIFAgb3IgQg0KPiA+PiBmcmFtZXMg YXJlIHRvIHJlY2VpdmUgYSBsb3dlciBwcmlvcml0eSAvDQo+ID4+ICAgaGlnaGVyIGRyb3AgcHJl Y2VkZW5jZSBQSEIpPw0KPiA+Pg0KPiA+PiBJIHBlcnNvbmFsbHkgcHJlZmVyIEFGNCBpZiBhdWRp byBhbmQgdmlkZW8gYXJlIHRvIGJlIHRyYW5zcG9ydGVkIGluDQo+ID4+IHRoZSBzYW1lIHF1ZXVl Lg0KPiA+Pg0KPiA+PiBJJ2QgYWxzbyBhc2sgZm9yIHRoZSBkcmFmdCB0ZXh0IHRvIGJlIGNsZWFy IGFib3V0IHRoZSBpc3N1ZSB3aGVuIHRvDQo+ID4+IG1hcmsgYXVkaW8gYnkgdGhlIEVGIFBIQi4g TXkgdW5kZXJzdGFuZGluZyBhZnRlciByZWFkaW5nIHlvdXINCj4gPj4gc3RhdGVtZW50IGJlbG93 IGlzOiBBdWRpbyBtYXJrZWQgRUYgaWYgdGhlcmUncyBubyB2aWRlbyBmbG93IG9ubHkuDQo+ID4+ DQo+ID4+IC4uLg0KPiA+PiBCQz5GaW5hbGx5LCB3aHkgaXMgYXVkaW8gbm90IGFsc28gc3ViZGl2 aWRlZCBpbnRvIGludGVyYWN0aXZlIGFuZA0KPiA+PiBCQz5ub24taW50ZXJhY3RpdmU/IEFzIGZh ciBhcyBJIGNhbiBzZWUsIGJvdGggYXJlIGxvZ2ljYWxseSBwb3NzaWJsZS4NCj4gPj4NCj4gPj4g W1BKXSBGb3IgV2ViUlRDLCBhdWRpbyBhbG9uZSBpcyAiaW50ZXJhY3RpdmUiIGluIG5hdHVyZSAo d2hpY2ggaXMNCj4gPj4gICB3aHkgaXQncyBtYXJrZWQgRUYpLiAgSG93ZXZlciwgaWYgb25lIGlz IHNlbmRpbmcgYXVkaW8gYW5kIHZpZGVvDQo+ID4+ICAgaXQgbWFrZXMgc2Vuc2UgdG8gbWFyayB0 aGVtIGJvdGggc2FtZSB3YXkgdG8gZ2V0IHRoZSBzYW1lIFBIQiBhbmQNCj4gPj4gICBob3BlZnVs bHkgaGF2ZSB0aGVtIHF1ZXVlZCBpbiB0aGUgc2FtZSBidWZmZXJzIGFsb25nIHRoZSBwYXRoLg0K PiA+PiAgIFNlbmRpbmcgYXVkaW8gYXMgRUYgYW5kIHBvc3NpYmx5IGhhdmluZyBhIFBIQiB0aGF0 IHJlc3VsdHMgaW4NCj4gPj4gICBwYWNrZXRzIGFycml2aW5nIG11Y2ggZmFzdGVyIHRoYW4gY29y cmVzcG9uZGluZyB2aWRlbyBwYWNrZXRzDQo+ID4+ICAgbWFya2VkIGFzIEFGNDIgaXMgbm90IGF0 IGFsbCBoZWxwZnVsIGZvciBhcHBsaWNhdGlvbnMgdGhhdCBoYXZlDQo+ID4+ICAgdG8gc3luY2hy b25pemUgdGhlIGF1ZGlvIGFuZCB2aWRlbyBmbG93cy4NCj4gPj4gLi4uDQo+ID4+DQo+ID4+ICAg UGF1bA0KPiA+Pg0KPiA+Pg0KPiA+PiBSZWdhcmRzLA0KPiA+Pg0KPiA+PiBSdWVkaWdlcg0KPiA+ Pg0KPiA+DQo= From nobody Wed May 11 18:43: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 E203512D82C for ; Wed, 11 May 2016 18:43:47 -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 SzN-5ggUyENM for ; Wed, 11 May 2016 18:43:46 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E67712D1A5 for ; Wed, 11 May 2016 18:43:46 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id i75so72142256ioa.3 for ; Wed, 11 May 2016 18:43:46 -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=TmPvy12OQL8iXV6Kyqh1EsxnOfahyiGU4HdCQzUYFvE=; b=oZh3coaliaeCuDRbBq/1U1xbvMtZtzVRtly0gpq3BZXZuG6w9vQtHeCq5OAtrqx9nI 0l20kCMh+XJDHZD9zI5NSaACKAUykr6mFPbqrHSta5B/m468YRVCeHAZ7lSkoutRD8tQ /X2QWiDElm9LoYZ11a7cutBXFtqYijyYDYjeSza4Gcfil/up6H2qwAXhniKyE4u0Gy4V 3IOWm+gEaQPj6iffK+gJMX6DGHohXHxgURKksB+AlKwYM5t1kQHeLo+uELzlz8gQ3Nsm jvtPxMp/5YiyazIkyW2UgBHzQ05PepYBg2LARcgO8x4pTjE3xvCIQQWWUfq+6O6LJB63 4hcA== 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=TmPvy12OQL8iXV6Kyqh1EsxnOfahyiGU4HdCQzUYFvE=; b=MtyhGEchnYjBhcYv9GdI7cJlcEvXZreOs8vnOfXne6n0LaOzcPwvr/9+1FQyDVu/mf RYraHz3dgIqBcFVNJOxEz4cnBwcazKntQblJ9+kjKa2tIfGxeAer4dE52FdSxdSBuMvu sNpRU0RUPavfayEQhMv4bhDByK3tYG5/VxFT53eMRB9BBSOZ+IfT1chVNhnlNMt1Zt1B pG1FeK1mdhN+Ssnpfe67mOSWB8Bhd04zxJOGbihZjBBVXE7CuU3wuUzh3Q4IZAqrb46m 0Hx6Fi3UfbA+Kq7nePgTU0++1V/BMGeo95Wv4dBt3TgAak+h3OP8fu5mAdqraV+4NFHe PqQg== X-Gm-Message-State: AOPr4FVCfKJ0EeWbT4K7Zj2aQn2RraV0ng+EGNIr2jS2Jbl3C/LgS8HRVf0Ku/K+vhviKoDoWJb0GL3ZTovFNg== MIME-Version: 1.0 X-Received: by 10.36.196.11 with SMTP id v11mr7045849itf.49.1463017423706; Wed, 11 May 2016 18:43:43 -0700 (PDT) Received: by 10.36.43.82 with HTTP; Wed, 11 May 2016 18:43:43 -0700 (PDT) In-Reply-To: References: <1D53717F-3679-4E9C-B612-FA75BFF13032@iii.ca> <57318BF1.4050006@alvestrand.no> Date: Thu, 12 May 2016 11:43:43 +1000 Message-ID: From: Martin Thomson To: "Peterson, Jon" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" , "Wendt, Chris" Subject: Re: [rtcweb] RTCWeb and STIR 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, 12 May 2016 01:43:56 -0000 On 12 May 2016 at 06:54, Peterson, Jon wrote: > This is a very handy document to have though, I think I understand the > interworking story a lot better than I did before. wot jon sed These are likely to be breaking changes, but I think that there are changes in this direction that would improve the functioning of the WebRTC identity stuff. Some potentially a lot. Getting good STIR PASSporT integration might be a big deal. From nobody Thu May 12 09:48:26 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 5A74112D6CE; Thu, 12 May 2016 09:48:25 -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.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160512164825.14308.14260.idtracker@ietfa.amsl.com> Date: Thu, 12 May 2016 09:48:25 -0700 Archived-At: Cc: rtcweb-chairs@ietf.org, draft-ietf-rtcweb-alpn@ietf.org, rtcweb@ietf.org, The IESG , turners@ieca.com, rfc-editor@rfc-editor.org Subject: [rtcweb] Protocol Action: 'Application Layer Protocol Negotiation for Web Real-Time Communications (WebRTC)' to Proposed Standard (draft-ietf-rtcweb-alpn-04.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 16:48:25 -0000 The IESG has approved the following document: - 'Application Layer Protocol Negotiation for Web Real-Time Communications (WebRTC)' (draft-ietf-rtcweb-alpn-04.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-alpn/ This is pretty simple/short draft that defines/registers two Application Layer Protocol Negotiation (ALPN) [RFC7301] values to enable an endpoint to positively identify WebRTC uses and distinguish them from other DTLS uses (i.e., provide media isolation). The two values are webrtc and c- webrtc; the first identifies a session that uses a combination of WebRTC compatible media and data, and the second identifies a session requiring confidentiality protection. As far as where you should point your fingers: - Sean Turner is the document shepherd, and; - Alissa Cooper is the responsible Area Director. From nobody Thu May 12 13:20:30 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B07112B011; Thu, 12 May 2016 13:20:26 -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 ZsmoGI32H3Nj; Thu, 12 May 2016 13:20:24 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::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 0754812B005; Thu, 12 May 2016 13:20:24 -0700 (PDT) Received: by mail-pa0-x22d.google.com with SMTP id xk12so32979560pac.0; Thu, 12 May 2016 13:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=9tLtjA8CBgC/wDtDMtr0ttx6PRD9JfqwXgzl1kOoDVY=; b=jpWxZ987I3pzv+8TP5ZgphJPZlOq2suPL2nZZ3wHi6oJZ4cPRTufrJK8r8Q88vLaHN v5r4x9/0Zfc20oGa+vDjBbKfyWLB2/HlGPRshICvvXDhdLzDMibS9G9gtSXDLp0cTefp 66kqMV+OezZmQ3rLGYv5cs2vJ4Y3Z8U8bmNgE2qtUyYEpYyyKkF8UXTn4H7MYHnYXLGW m9UnbhP4NRupvrDiLk3wh1cvaT4YdgJbGQehyRS9JJiyh0AAEKyxR6Kh/SBT/GC7/1K6 olMuY6NAt4MT/zOfWzR90VRzJuF9q4GE5bjsx/vRo2c+X59nVuzbhr+8MIoYmi/Yazly bSOQ== 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:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=9tLtjA8CBgC/wDtDMtr0ttx6PRD9JfqwXgzl1kOoDVY=; b=cyy5NQT+Ln9/A/ilhyuowqZprABnnU19UmxSxOrr0y0dDKJmFyc3NWzjcx4aF8kKyS BQkA4SLUQWJ69Xe1iz2DPQh5QzXUrdl5Cg0UA4QDVbyNCR53joDKS9ILfP76EWWTUHFL pKp2d6o5d85SV9d98/7/Mr5EeKPhEKr+4W0ZUyHTedYqfWDGfiw84tja+jLA/ZIp/ZqC 9wBfwvtqp8xdqTQKyL1lRoj8zWdj3KTZ4RPVynoD1mMOxJqPZ8Nav913eYwXMM9tdSOu nIRFyZk1mMxMLw03ar8z+CQk/Ul+BFAYY4biYTXDi8MRnGxZbjIakHeq3rj3Igls6w2K RlCQ== X-Gm-Message-State: AOPr4FUl57dhBuW5LqOYgxvYNrPxlH4wqdCGzOCsLb8mMfAVY6EIUwIxJY7pJyYUIfYwLA== X-Received: by 10.66.222.202 with SMTP id qo10mr16402283pac.141.1463084423539; Thu, 12 May 2016 13:20:23 -0700 (PDT) Received: from ?IPv6:2406:e007:69e1:1:28cc:dc4c:9703:6781? ([2406:e007:69e1:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id d186sm21877691pfa.45.2016.05.12.13.20.19 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 May 2016 13:20:22 -0700 (PDT) To: "Black, David" , "Ruediger.Geib@telekom.de" , "harald@alvestrand.no" References: <828773FE19B05B4581311493A046E85E6ECC3084D0@HE111642.emea1.cds.t-internal.com> <828773FE19B05B4581311493A046E85E6ECC4090FD@HE111642.emea1.cds.t-internal.com> <57318F4E.4080102@alvestrand.no> <828773FE19B05B4581311493A046E85E6ECC409176@HE111642.emea1.cds.t-internal.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1fbae98a-7aca-586e-2fe2-8c833e8d3cc8@gmail.com> Date: Fri, 13 May 2016 08:20:47 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] Diffserv QoS for Video 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, 12 May 2016 20:20:26 -0000 > Also, in addition to the -16 version of the WebRTC QoS draft that was j= ust uploaded, fwiw, as one of the people who's been commenting, I am happy with the cha= nges that have been made in that version. Regards Brian On 12/05/2016 12:19, Black, David wrote: >> I'm working on transport only and my rtcweb input is draft-ietf-tsvwg-= rtcweb- >> qos-15. It states little for audience like me, if the subject is audio= and video >> related to a talking person. I think the relevant statement are lines = in a table. I'd >> appreciate text helping with the interpretation of table. If we can't = agree on >> useful text - leave it as is. >=20 > As draft shepherd, I think the table text is ok as-is; other WebRTC spe= cs own > the definition of what a media flow is, and one of them would be the ap= propriate > location for text (if appropriate) to point out that audio for video co= uld be sent > on the same or different or different media flow as the video. Among = the reasons > for this is that deciding whether to use one or two media flows has RTP= impacts > that occur well before DSCP assignment to outbound traffic. >=20 > Also, in addition to the -16 version of the WebRTC QoS draft that was j= ust uploaded, > I've edited that draft's shepherd writeup to reflect the resolution of = the issue around > interactive vs. non-interactive video, including recording the expectat= ion that > there will be some additional text on this topic in the next version of= the WebRTC > Transports draft. >=20 > Thanks, --David >=20 >> -----Original Message----- >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of >> Ruediger.Geib@telekom.de >> Sent: Tuesday, May 10, 2016 4:19 AM >> To: harald@alvestrand.no >> Cc: rtcweb@ietf.org; tsvwg@ietf.org >> Subject: Re: [tsvwg] Diffserv QoS for Video >> >> Hi Harald, >> >> We should avoid to re-open last call. That's not my intent. >> >> I'm working on transport only and my rtcweb input is draft-ietf-tsvwg-= rtcweb- >> qos-15. It states little for audience like me, if the subject is audio= and video >> related to a talking person. I think the relevant statement are lines = in a table. I'd >> appreciate text helping with the interpretation of table. If we can't = agree on >> useful text - leave it as is. >> >> A backbone supporting RTP based TV distribution tends to be engineered= for >> support of an AF4 like QoS class for low loss. I think, telephony code= cs, whose >> RTP streams will be transported by EF, are able to deal with higher pa= cket loss, >> than multicast based IPTV. >> >> To me, an audio or telepresence/videoconference call with QoS require >> admission control. This ensures that they are transported without queu= ing or >> drops. >> >> If there's congestion however: >> >> An audio flow marked AF41 should face a lower drop rate than a video f= low >> marked AF42 in the case of congestion at an network edge node. The pac= kets >> arrive in the same order as they were sent (independent of the flow th= ey belong >> to). >> >> An EF marked audio flow may experience loss events independent from a = video >> flow marked AF4x. In the case of queuing, one of the flows will be ear= lier. If both >> are transported by QoS classes optimized for rtp/udp transport, the di= fference is >> a few [ms] per congestion point. If one of the queues is optimized for= general >> data transport, the delay difference is likely to be a double digit [m= s] number. >> The packets of each flow arrive in order as sent, the packets of one f= low are >> delayed against those of the other. >> >> Regards, >> >> Ruediger >> >> -----Urspr=C3=BCngliche Nachricht----- >> Von: Harald Alvestrand [mailto:harald@alvestrand.no] >> Gesendet: Dienstag, 10. Mai 2016 09:36 >> An: Geib, R=C3=BCdiger; paulej@packetizer.com >> Cc: rtcweb@ietf.org; tsvwg@ietf.org >> Betreff: Re: [tsvwg] Diffserv QoS for Video >> >> FTR: I don't see such an agreement at all. >> >> On the contrary, my perception is that people want the ability to deli= ver audio >> with a lower loss probability and lower delay probability than video -= it's more >> important to the conversation, and there are fewer things the recipien= t can do to >> hide the losses. If the sender chose to send them on separate flows, t= hey shold >> have different DSCP markings. >> >> I believe this is what draft-ietf-tsvwg-rtcweb-qos-15 section 5 states= , and I >> believe that this is what TSVWG has declared consensus on and wrote in= the >> document that passed WG last call and is currently in "waiting for wri= teup" state. >> >> Changing this determination would, at minimum, require reopening the W= G Last >> Call. >> And I'd object. >> >> Harald >> >> >> Den 10. mai 2016 08:56, skrev Ruediger.Geib@telekom.de: >>> Hi Paul, >>> >>> I think we agree, that audio and video frames, if both are part of th= e >>> same (interactive) media flow should be transported by the same PHB >>> [PJ] or the same queue [RG]. The latter is ensured, if the same PHB i= s >>> picked for audio and video. To me the text of the draft so far doesn'= t >>> express that both audio and video are supposed to use an "Interactive= >>> Video..." PHB, if both are present. I'd prefer to have text with a no= n >>> binding standard requirement saying >>> >>> However, if the application wishes to send both interactive >>> video and audio, it is RECOMMENDED to transport audio >>> and video packets by the same per hop behavior. For example, >>> audio and video packets would both be marked as AF42 or >>> AF43. >>> >>> I don't insist on descriptive text proposing to transport audio by an= AF4 PHB >> offering a lower drop ratio than that used to transport video. My audi= o/video >> experts support this and I'm pretty sure, that also Cisco representati= ves >> mentioned that audio quality ranks above video quality in telepresence= sessions. >>> >>> Regards, >>> >>> Ruediger >>> >>> >>> -----Urspr=C3=BCngliche Nachricht----- >>> Von: Paul E. Jones [mailto:paulej@packetizer.com] >>> Gesendet: Montag, 9. Mai 2016 21:03 >>> An: Geib, R=C3=BCdiger >>> Cc: brian.e.carpenter@gmail.com; david.black@emc.com; tsvwg@ietf.org;= >>> rtcweb@ietf.org >>> Betreff: Re: AW: [tsvwg] Diffserv QoS for Video >>> >>> Ruediger, >>> >>> Perhaps an example might be helpful. How about I add this text for i= llustrative >> purposes? >>> >>> To illustrate the use of the above table, let us assume the >>> application assigns a priority of "medium" to audio and video >>> flows. Given that assumption, if the application wishes to send= >>> only audio then packets would be marked EF. However, if the >>> application wishes to send both interactive video and audio, >>> then audio and video packets would both be marked as AF42 or >>> AF43. The intent is to ensure that when both audio and video >>> are being sent together that they receive similar per-hop >>> behavior. >>> >>> This doesn't get into the preference for AF42 vs. AF43. If it were me= , I'd mark all >> audio as AF42 and only key video frames as AF42. All predictive frame= s would be >> sent with an AF43 marking. I might even take it a step further and cl= assify all >> audio as "high". However, I've seen a tremendous amount of debate on = this >> before, so I'd prefer to not go too far in dictating audio markings vs= =2E video. I do >> think most people generally agree about at least ensuring the class is= the same, >> otherwise the wildly different PHB introduces skew between A/V packet = arrival, >> thus inflating the size of buffers managing the A/V streams. However,= we do not >> want to dictate that audio should be treated significantly better than= audio. For >> deaf users, for example, the audio really isn't important at all. Tha= t is perhaps an >> extreme example, but it nonetheless highlights why we should be cautio= us about >> exactly what we normatively mandate. >>> >>> Paul >>> >>> ------ Original Message ------ >>> From: Ruediger.Geib@telekom.de >>> To: paulej@packetizer.com >>> Cc: brian.e.carpenter@gmail.com; david.black@emc.com; tsvwg@ietf.org;= >>> rtcweb@ietf.org >>> Sent: 5/9/2016 3:34:25 AM >>> Subject: AW: [tsvwg] Diffserv QoS for Video >>> >>>> Hi Paul, >>>> >>>> I've talked with audio/video experts of Deutsche Telekom and they to= o >>>> favored what you recommend below: transport audio and video by the >>>> same queue. Your statement below however stops there and the draft >>>> text doesn't clarify the issue: >>>> >>>> If there's interactive video with audio, then they both should be >>>> marked for the same PHB which is: >>>> - EF ? >>>> - AF4? Like AF41 Audio, AF42 Video (AF43 in addition, if P or B >>>> frames are to receive a lower priority / >>>> higher drop precedence PHB)? >>>> >>>> I personally prefer AF4 if audio and video are to be transported in >>>> the same queue. >>>> >>>> I'd also ask for the draft text to be clear about the issue when to >>>> mark audio by the EF PHB. My understanding after reading your >>>> statement below is: Audio marked EF if there's no video flow only. >>>> >>>> ... >>>> BC>Finally, why is audio not also subdivided into interactive and >>>> BC>non-interactive? As far as I can see, both are logically possible= =2E >>>> >>>> [PJ] For WebRTC, audio alone is "interactive" in nature (which is >>>> why it's marked EF). However, if one is sending audio and video >>>> it makes sense to mark them both same way to get the same PHB and >>>> hopefully have them queued in the same buffers along the path. >>>> Sending audio as EF and possibly having a PHB that results in >>>> packets arriving much faster than corresponding video packets >>>> marked as AF42 is not at all helpful for applications that have >>>> to synchronize the audio and video flows. >>>> ... >>>> >>>> Paul >>>> >>>> >>>> Regards, >>>> >>>> Ruediger >>>> >>> From nobody Thu May 12 23:50: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 B4DB912D0F3; Thu, 12 May 2016 23:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 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, 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 gQpkK67EAuav; Thu, 12 May 2016 23:49:55 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B702E12D104; Thu, 12 May 2016 23:49:53 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail41.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 13 May 2016 08:49:05 +0200 X-IronPort-AV: E=Sophos;i="5.24,612,1454972400"; d="scan'208";a="879829059" Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 13 May 2016 08:47:33 +0200 Received: from HE111642.emea1.cds.t-internal.com ([10.134.93.11]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 13 May 2016 08:47:32 +0200 From: To: Date: Fri, 13 May 2016 08:47:32 +0200 Thread-Topic: [tsvwg] Diffserv QoS for Video Thread-Index: AdGsi7m9bhQ9q4tqTIScB8YNVo6qpAAVyblw Message-ID: <828773FE19B05B4581311493A046E85E6ECC40990E@HE111642.emea1.cds.t-internal.com> References: <828773FE19B05B4581311493A046E85E6ECC3084D0@HE111642.emea1.cds.t-internal.com> <828773FE19B05B4581311493A046E85E6ECC4090FD@HE111642.emea1.cds.t-internal.com> <57318F4E.4080102@alvestrand.no> <828773FE19B05B4581311493A046E85E6ECC409176@HE111642.emea1.cds.t-internal.com> <1fbae98a-7aca-586e-2fe2-8c833e8d3cc8@gmail.com> In-Reply-To: <1fbae98a-7aca-586e-2fe2-8c833e8d3cc8@gmail.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: rtcweb@ietf.org, tsvwg@ietf.org, brian.e.carpenter@gmail.com Subject: Re: [rtcweb] [tsvwg] Diffserv QoS for Video 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, 13 May 2016 06:49:59 -0000 RGF2aWQsDQoNCmFzIEkgbWVudGlvbmVkIGluIGFuIGVhcmxpZXIgbWFpbCwgYWxsIGNoYW5nZXMg d2hlcmUgdGhlIFdHIHJlYWNoZWQgYWdyZWVtZW50IGFyZSBmaW5lIHdpdGggbWUgYW5kIG90aGVy cyBJIGRvbid0IHB1cnN1ZS4NCg0KUmVnYXJkcywgUnVlZGlnZXINCg0KLS0tLS1VcnNwcsO8bmds aWNoZSBOYWNocmljaHQtLS0tLQ0KVm9uOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFu LmUuY2FycGVudGVyQGdtYWlsLmNvbV0gDQpHZXNlbmRldDogRG9ubmVyc3RhZywgMTIuIE1haSAy MDE2IDIyOjIxDQpBbjogQmxhY2ssIERhdmlkOyBHZWliLCBSw7xkaWdlcjsgaGFyYWxkQGFsdmVz dHJhbmQubm8NCkNjOiBydGN3ZWJAaWV0Zi5vcmc7IHRzdndnQGlldGYub3JnDQpCZXRyZWZmOiBS ZTogW3RzdndnXSBEaWZmc2VydiBRb1MgZm9yIFZpZGVvDQoNCj4gQWxzbywgaW4gYWRkaXRpb24g dG8gdGhlIC0xNiB2ZXJzaW9uIG9mIHRoZSBXZWJSVEMgUW9TIGRyYWZ0IHRoYXQgd2FzIA0KPiBq dXN0IHVwbG9hZGVkLA0KDQpmd2l3LCBhcyBvbmUgb2YgdGhlIHBlb3BsZSB3aG8ncyBiZWVuIGNv bW1lbnRpbmcsIEkgYW0gaGFwcHkgd2l0aCB0aGUgY2hhbmdlcyB0aGF0IGhhdmUgYmVlbiBtYWRl IGluIHRoYXQgdmVyc2lvbi4NCg0KUmVnYXJkcw0KICAgQnJpYW4NCg0KT24gMTIvMDUvMjAxNiAx MjoxOSwgQmxhY2ssIERhdmlkIHdyb3RlOg0KPj4gSSdtIHdvcmtpbmcgb24gdHJhbnNwb3J0IG9u bHkgYW5kIG15IHJ0Y3dlYiBpbnB1dCBpcyANCj4+IGRyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLSBx b3MtMTUuIEl0IHN0YXRlcyBsaXR0bGUgZm9yIGF1ZGllbmNlIGxpa2UgDQo+PiBtZSwgaWYgdGhl IHN1YmplY3QgaXMgYXVkaW8gYW5kIHZpZGVvIHJlbGF0ZWQgdG8gYSB0YWxraW5nIHBlcnNvbi4g SSANCj4+IHRoaW5rIHRoZSByZWxldmFudCBzdGF0ZW1lbnQgYXJlIGxpbmVzIGluIGEgdGFibGUu IEknZCBhcHByZWNpYXRlIA0KPj4gdGV4dCBoZWxwaW5nIHdpdGggdGhlIGludGVycHJldGF0aW9u IG9mIHRhYmxlLiBJZiB3ZSBjYW4ndCBhZ3JlZSBvbiB1c2VmdWwgdGV4dCAtIGxlYXZlIGl0IGFz IGlzLg0KPiANCj4gQXMgZHJhZnQgc2hlcGhlcmQsIEkgdGhpbmsgdGhlIHRhYmxlIHRleHQgaXMg b2sgYXMtaXM7IG90aGVyIFdlYlJUQyANCj4gc3BlY3Mgb3duIHRoZSBkZWZpbml0aW9uIG9mIHdo YXQgYSBtZWRpYSBmbG93IGlzLCBhbmQgb25lIG9mIHRoZW0gDQo+IHdvdWxkIGJlIHRoZSBhcHBy b3ByaWF0ZSBsb2NhdGlvbiBmb3IgdGV4dCAoaWYgYXBwcm9wcmlhdGUpIHRvIHBvaW50IG91dCB0 aGF0IGF1ZGlvIGZvciB2aWRlbyBjb3VsZCBiZSBzZW50DQo+IG9uIHRoZSBzYW1lIG9yIGRpZmZl cmVudCBvciBkaWZmZXJlbnQgbWVkaWEgZmxvdyBhcyB0aGUgdmlkZW8uICAgQW1vbmcgdGhlIHJl YXNvbnMNCj4gZm9yIHRoaXMgaXMgdGhhdCBkZWNpZGluZyB3aGV0aGVyIHRvIHVzZSBvbmUgb3Ig dHdvIG1lZGlhIGZsb3dzIGhhcyANCj4gUlRQIGltcGFjdHMgdGhhdCBvY2N1ciB3ZWxsIGJlZm9y ZSBEU0NQIGFzc2lnbm1lbnQgdG8gb3V0Ym91bmQgdHJhZmZpYy4NCj4gDQo+IEFsc28sIGluIGFk ZGl0aW9uIHRvIHRoZSAtMTYgdmVyc2lvbiBvZiB0aGUgV2ViUlRDIFFvUyBkcmFmdCB0aGF0IHdh cyANCj4ganVzdCB1cGxvYWRlZCwgSSd2ZSBlZGl0ZWQgdGhhdCBkcmFmdCdzIHNoZXBoZXJkIHdy aXRldXAgdG8gcmVmbGVjdCANCj4gdGhlIHJlc29sdXRpb24gb2YgdGhlIGlzc3VlIGFyb3VuZCBp bnRlcmFjdGl2ZSB2cy4gbm9uLWludGVyYWN0aXZlIA0KPiB2aWRlbywgaW5jbHVkaW5nIHJlY29y ZGluZyB0aGUgZXhwZWN0YXRpb24gdGhhdCB0aGVyZSB3aWxsIGJlIHNvbWUgDQo+IGFkZGl0aW9u YWwgdGV4dCBvbiB0aGlzIHRvcGljIGluIHRoZSBuZXh0IHZlcnNpb24gb2YgdGhlIFdlYlJUQyBU cmFuc3BvcnRzICBkcmFmdC4NCj4gDQo+IFRoYW5rcywgLS1EYXZpZA0KPiANCj4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiANCj4+IFJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZQ0KPj4g U2VudDogVHVlc2RheSwgTWF5IDEwLCAyMDE2IDQ6MTkgQU0NCj4+IFRvOiBoYXJhbGRAYWx2ZXN0 cmFuZC5ubw0KPj4gQ2M6IHJ0Y3dlYkBpZXRmLm9yZzsgdHN2d2dAaWV0Zi5vcmcNCj4+IFN1Ympl Y3Q6IFJlOiBbdHN2d2ddIERpZmZzZXJ2IFFvUyBmb3IgVmlkZW8NCj4+DQo+PiBIaSBIYXJhbGQs DQo+Pg0KPj4gV2Ugc2hvdWxkIGF2b2lkIHRvIHJlLW9wZW4gbGFzdCBjYWxsLiBUaGF0J3Mgbm90 IG15IGludGVudC4NCj4+DQo+PiBJJ20gd29ya2luZyBvbiB0cmFuc3BvcnQgb25seSBhbmQgbXkg cnRjd2ViIGlucHV0IGlzIA0KPj4gZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItIHFvcy0xNS4gSXQg c3RhdGVzIGxpdHRsZSBmb3IgYXVkaWVuY2UgbGlrZSANCj4+IG1lLCBpZiB0aGUgc3ViamVjdCBp cyBhdWRpbyBhbmQgdmlkZW8gcmVsYXRlZCB0byBhIHRhbGtpbmcgcGVyc29uLiBJIA0KPj4gdGhp bmsgdGhlIHJlbGV2YW50IHN0YXRlbWVudCBhcmUgbGluZXMgaW4gYSB0YWJsZS4gSSdkIGFwcHJl Y2lhdGUgDQo+PiB0ZXh0IGhlbHBpbmcgd2l0aCB0aGUgaW50ZXJwcmV0YXRpb24gb2YgdGFibGUu IElmIHdlIGNhbid0IGFncmVlIG9uIHVzZWZ1bCB0ZXh0IC0gbGVhdmUgaXQgYXMgaXMuDQo+Pg0K Pj4gQSBiYWNrYm9uZSBzdXBwb3J0aW5nIFJUUCBiYXNlZCBUViBkaXN0cmlidXRpb24gdGVuZHMg dG8gYmUgDQo+PiBlbmdpbmVlcmVkIGZvciBzdXBwb3J0IG9mIGFuIEFGNCBsaWtlIFFvUyBjbGFz cyBmb3IgbG93IGxvc3MuIEkgDQo+PiB0aGluaywgdGVsZXBob255IGNvZGVjcywgd2hvc2UgUlRQ IHN0cmVhbXMgd2lsbCBiZSB0cmFuc3BvcnRlZCBieSBFRiwgDQo+PiBhcmUgYWJsZSB0byBkZWFs IHdpdGggaGlnaGVyIHBhY2tldCBsb3NzLCB0aGFuIG11bHRpY2FzdCBiYXNlZCBJUFRWLg0KPj4N Cj4+IFRvIG1lLCBhbiBhdWRpbyBvciB0ZWxlcHJlc2VuY2UvdmlkZW9jb25mZXJlbmNlIGNhbGwg d2l0aCBRb1MgcmVxdWlyZSANCj4+IGFkbWlzc2lvbiBjb250cm9sLiBUaGlzIGVuc3VyZXMgdGhh dCB0aGV5IGFyZSB0cmFuc3BvcnRlZCB3aXRob3V0IA0KPj4gcXVldWluZyBvciBkcm9wcy4NCj4+ DQo+PiBJZiB0aGVyZSdzIGNvbmdlc3Rpb24gaG93ZXZlcjoNCj4+DQo+PiBBbiBhdWRpbyBmbG93 IG1hcmtlZCBBRjQxIHNob3VsZCBmYWNlIGEgbG93ZXIgZHJvcCByYXRlIHRoYW4gYSB2aWRlbyAN Cj4+IGZsb3cgbWFya2VkIEFGNDIgaW4gdGhlIGNhc2Ugb2YgY29uZ2VzdGlvbiBhdCBhbiBuZXR3 b3JrIGVkZ2Ugbm9kZS4gDQo+PiBUaGUgcGFja2V0cyBhcnJpdmUgaW4gdGhlIHNhbWUgb3JkZXIg YXMgdGhleSB3ZXJlIHNlbnQgKGluZGVwZW5kZW50IA0KPj4gb2YgdGhlIGZsb3cgdGhleSBiZWxv bmcgdG8pLg0KPj4NCj4+IEFuIEVGIG1hcmtlZCBhdWRpbyBmbG93IG1heSBleHBlcmllbmNlIGxv c3MgZXZlbnRzIGluZGVwZW5kZW50IGZyb20gYSANCj4+IHZpZGVvIGZsb3cgbWFya2VkIEFGNHgu IEluIHRoZSBjYXNlIG9mIHF1ZXVpbmcsIG9uZSBvZiB0aGUgZmxvd3Mgd2lsbCANCj4+IGJlIGVh cmxpZXIuIElmIGJvdGggYXJlIHRyYW5zcG9ydGVkIGJ5IFFvUyBjbGFzc2VzIG9wdGltaXplZCBm b3IgDQo+PiBydHAvdWRwIHRyYW5zcG9ydCwgdGhlIGRpZmZlcmVuY2UgaXMgYSBmZXcgW21zXSBw ZXIgY29uZ2VzdGlvbiBwb2ludC4gDQo+PiBJZiBvbmUgb2YgdGhlIHF1ZXVlcyBpcyBvcHRpbWl6 ZWQgZm9yIGdlbmVyYWwgZGF0YSB0cmFuc3BvcnQsIHRoZSBkZWxheSBkaWZmZXJlbmNlIGlzIGxp a2VseSB0byBiZSBhIGRvdWJsZSBkaWdpdCBbbXNdIG51bWJlci4NCj4+IFRoZSBwYWNrZXRzIG9m IGVhY2ggZmxvdyBhcnJpdmUgaW4gb3JkZXIgYXMgc2VudCwgdGhlIHBhY2tldHMgb2Ygb25lIA0K Pj4gZmxvdyBhcmUgZGVsYXllZCBhZ2FpbnN0IHRob3NlIG9mIHRoZSBvdGhlci4NCj4+DQo+PiBS ZWdhcmRzLA0KPj4NCj4+IFJ1ZWRpZ2VyDQo+Pg0KPj4gLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNo cmljaHQtLS0tLQ0KPj4gVm9uOiBIYXJhbGQgQWx2ZXN0cmFuZCBbbWFpbHRvOmhhcmFsZEBhbHZl c3RyYW5kLm5vXQ0KPj4gR2VzZW5kZXQ6IERpZW5zdGFnLCAxMC4gTWFpIDIwMTYgMDk6MzYNCj4+ IEFuOiBHZWliLCBSw7xkaWdlcjsgcGF1bGVqQHBhY2tldGl6ZXIuY29tDQo+PiBDYzogcnRjd2Vi QGlldGYub3JnOyB0c3Z3Z0BpZXRmLm9yZw0KPj4gQmV0cmVmZjogUmU6IFt0c3Z3Z10gRGlmZnNl cnYgUW9TIGZvciBWaWRlbw0KPj4NCj4+IEZUUjogSSBkb24ndCBzZWUgc3VjaCBhbiBhZ3JlZW1l bnQgYXQgYWxsLg0KPj4NCj4+IE9uIHRoZSBjb250cmFyeSwgbXkgcGVyY2VwdGlvbiBpcyB0aGF0 IHBlb3BsZSB3YW50IHRoZSBhYmlsaXR5IHRvIA0KPj4gZGVsaXZlciBhdWRpbyB3aXRoIGEgbG93 ZXIgbG9zcyBwcm9iYWJpbGl0eSBhbmQgbG93ZXIgZGVsYXkgDQo+PiBwcm9iYWJpbGl0eSB0aGFu IHZpZGVvIC0gaXQncyBtb3JlIGltcG9ydGFudCB0byB0aGUgY29udmVyc2F0aW9uLCBhbmQgDQo+ PiB0aGVyZSBhcmUgZmV3ZXIgdGhpbmdzIHRoZSByZWNpcGllbnQgY2FuIGRvIHRvIGhpZGUgdGhl IGxvc3Nlcy4gSWYgDQo+PiB0aGUgc2VuZGVyIGNob3NlIHRvIHNlbmQgdGhlbSBvbiBzZXBhcmF0 ZSBmbG93cywgdGhleSBzaG9sZCBoYXZlIGRpZmZlcmVudCBEU0NQIG1hcmtpbmdzLg0KPj4NCj4+ IEkgYmVsaWV2ZSB0aGlzIGlzIHdoYXQgZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zLTE1IHNl Y3Rpb24gNSANCj4+IHN0YXRlcywgYW5kIEkgYmVsaWV2ZSB0aGF0IHRoaXMgaXMgd2hhdCBUU1ZX RyBoYXMgZGVjbGFyZWQgY29uc2Vuc3VzIA0KPj4gb24gYW5kIHdyb3RlIGluIHRoZSBkb2N1bWVu dCB0aGF0IHBhc3NlZCBXRyBsYXN0IGNhbGwgYW5kIGlzIGN1cnJlbnRseSBpbiAid2FpdGluZyBm b3Igd3JpdGV1cCIgc3RhdGUuDQo+Pg0KPj4gQ2hhbmdpbmcgdGhpcyBkZXRlcm1pbmF0aW9uIHdv dWxkLCBhdCBtaW5pbXVtLCByZXF1aXJlIHJlb3BlbmluZyB0aGUgDQo+PiBXRyBMYXN0IENhbGwu DQo+PiBBbmQgSSdkIG9iamVjdC4NCj4+DQo+PiBIYXJhbGQNCj4+DQo+Pg0KPj4gRGVuIDEwLiBt YWkgMjAxNiAwODo1Niwgc2tyZXYgUnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlOg0KPj4+IEhpIFBh dWwsDQo+Pj4NCj4+PiBJIHRoaW5rIHdlIGFncmVlLCB0aGF0IGF1ZGlvIGFuZCB2aWRlbyBmcmFt ZXMsIGlmIGJvdGggYXJlIHBhcnQgb2YgDQo+Pj4gdGhlIHNhbWUgKGludGVyYWN0aXZlKSBtZWRp YSBmbG93IHNob3VsZCBiZSB0cmFuc3BvcnRlZCBieSB0aGUgc2FtZSANCj4+PiBQSEIgW1BKXSBv ciB0aGUgc2FtZSBxdWV1ZSBbUkddLiBUaGUgbGF0dGVyIGlzIGVuc3VyZWQsIGlmIHRoZSBzYW1l IA0KPj4+IFBIQiBpcyBwaWNrZWQgZm9yIGF1ZGlvIGFuZCB2aWRlby4gVG8gbWUgdGhlIHRleHQg b2YgdGhlIGRyYWZ0IHNvIA0KPj4+IGZhciBkb2Vzbid0IGV4cHJlc3MgdGhhdCBib3RoIGF1ZGlv IGFuZCB2aWRlbyBhcmUgc3VwcG9zZWQgdG8gdXNlIGFuIA0KPj4+ICJJbnRlcmFjdGl2ZSBWaWRl by4uLiIgUEhCLCBpZiBib3RoIGFyZSBwcmVzZW50LiBJJ2QgcHJlZmVyIHRvIGhhdmUgDQo+Pj4g dGV4dCB3aXRoIGEgbm9uIGJpbmRpbmcgc3RhbmRhcmQgcmVxdWlyZW1lbnQgc2F5aW5nDQo+Pj4N Cj4+PiAgICAgIEhvd2V2ZXIsIGlmIHRoZSBhcHBsaWNhdGlvbiB3aXNoZXMgdG8gc2VuZCBib3Ro IGludGVyYWN0aXZlDQo+Pj4gICAgICB2aWRlbyBhbmQgYXVkaW8sIGl0IGlzIFJFQ09NTUVOREVE IHRvIHRyYW5zcG9ydCBhdWRpbw0KPj4+ICAgICAgYW5kIHZpZGVvIHBhY2tldHMgYnkgdGhlIHNh bWUgcGVyIGhvcCBiZWhhdmlvci4gRm9yIGV4YW1wbGUsDQo+Pj4gICAgICBhdWRpbyBhbmQgdmlk ZW8gcGFja2V0cyB3b3VsZCBib3RoIGJlIG1hcmtlZCBhcyBBRjQyIG9yDQo+Pj4gICAgICBBRjQz Lg0KPj4+DQo+Pj4gSSBkb24ndCBpbnNpc3Qgb24gZGVzY3JpcHRpdmUgdGV4dCBwcm9wb3Npbmcg dG8gdHJhbnNwb3J0IGF1ZGlvIGJ5IA0KPj4+IGFuIEFGNCBQSEINCj4+IG9mZmVyaW5nIGEgbG93 ZXIgZHJvcCByYXRpbyB0aGFuIHRoYXQgdXNlZCB0byB0cmFuc3BvcnQgdmlkZW8uIE15IA0KPj4g YXVkaW8vdmlkZW8gZXhwZXJ0cyBzdXBwb3J0IHRoaXMgYW5kIEknbSBwcmV0dHkgc3VyZSwgdGhh dCBhbHNvIENpc2NvIA0KPj4gcmVwcmVzZW50YXRpdmVzIG1lbnRpb25lZCB0aGF0IGF1ZGlvIHF1 YWxpdHkgcmFua3MgYWJvdmUgdmlkZW8gcXVhbGl0eSBpbiB0ZWxlcHJlc2VuY2Ugc2Vzc2lvbnMu DQo+Pj4NCj4+PiBSZWdhcmRzLA0KPj4+DQo+Pj4gUnVlZGlnZXINCj4+Pg0KPj4+DQo+Pj4gLS0t LS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KPj4+IFZvbjogUGF1bCBFLiBKb25lcyBb bWFpbHRvOnBhdWxlakBwYWNrZXRpemVyLmNvbV0NCj4+PiBHZXNlbmRldDogTW9udGFnLCA5LiBN YWkgMjAxNiAyMTowMw0KPj4+IEFuOiBHZWliLCBSw7xkaWdlcg0KPj4+IENjOiBicmlhbi5lLmNh cnBlbnRlckBnbWFpbC5jb207IGRhdmlkLmJsYWNrQGVtYy5jb207IA0KPj4+IHRzdndnQGlldGYu b3JnOyBydGN3ZWJAaWV0Zi5vcmcNCj4+PiBCZXRyZWZmOiBSZTogQVc6IFt0c3Z3Z10gRGlmZnNl cnYgUW9TIGZvciBWaWRlbw0KPj4+DQo+Pj4gUnVlZGlnZXIsDQo+Pj4NCj4+PiBQZXJoYXBzIGFu IGV4YW1wbGUgbWlnaHQgYmUgaGVscGZ1bC4gIEhvdyBhYm91dCBJIGFkZCB0aGlzIHRleHQgZm9y IA0KPj4+IGlsbHVzdHJhdGl2ZQ0KPj4gcHVycG9zZXM/DQo+Pj4NCj4+PiAgICAgIFRvIGlsbHVz dHJhdGUgdGhlIHVzZSBvZiB0aGUgYWJvdmUgdGFibGUsIGxldCB1cyBhc3N1bWUgdGhlDQo+Pj4g ICAgICBhcHBsaWNhdGlvbiBhc3NpZ25zIGEgcHJpb3JpdHkgb2YgIm1lZGl1bSIgdG8gYXVkaW8g YW5kIHZpZGVvDQo+Pj4gICAgICBmbG93cy4gIEdpdmVuIHRoYXQgYXNzdW1wdGlvbiwgaWYgdGhl IGFwcGxpY2F0aW9uIHdpc2hlcyB0byBzZW5kDQo+Pj4gICAgICBvbmx5IGF1ZGlvIHRoZW4gcGFj a2V0cyB3b3VsZCBiZSBtYXJrZWQgRUYuICBIb3dldmVyLCBpZiB0aGUNCj4+PiAgICAgIGFwcGxp Y2F0aW9uIHdpc2hlcyB0byBzZW5kIGJvdGggaW50ZXJhY3RpdmUgdmlkZW8gYW5kIGF1ZGlvLA0K Pj4+ICAgICAgdGhlbiBhdWRpbyBhbmQgdmlkZW8gcGFja2V0cyB3b3VsZCBib3RoIGJlIG1hcmtl ZCBhcyBBRjQyIG9yDQo+Pj4gICAgICBBRjQzLiAgVGhlIGludGVudCBpcyB0byBlbnN1cmUgdGhh dCB3aGVuIGJvdGggYXVkaW8gYW5kIHZpZGVvDQo+Pj4gICAgICBhcmUgYmVpbmcgc2VudCB0b2dl dGhlciB0aGF0IHRoZXkgcmVjZWl2ZSBzaW1pbGFyIHBlci1ob3ANCj4+PiAgICAgIGJlaGF2aW9y Lg0KPj4+DQo+Pj4gVGhpcyBkb2Vzbid0IGdldCBpbnRvIHRoZSBwcmVmZXJlbmNlIGZvciBBRjQy IHZzLiBBRjQzLiBJZiBpdCB3ZXJlIA0KPj4+IG1lLCBJJ2QgbWFyayBhbGwNCj4+IGF1ZGlvIGFz IEFGNDIgYW5kIG9ubHkga2V5IHZpZGVvIGZyYW1lcyBhcyBBRjQyLiAgQWxsIHByZWRpY3RpdmUg DQo+PiBmcmFtZXMgd291bGQgYmUgc2VudCB3aXRoIGFuIEFGNDMgbWFya2luZy4gIEkgbWlnaHQg ZXZlbiB0YWtlIGl0IGEgDQo+PiBzdGVwIGZ1cnRoZXIgYW5kIGNsYXNzaWZ5IGFsbCBhdWRpbyBh cyAiaGlnaCIuICBIb3dldmVyLCBJJ3ZlIHNlZW4gYSANCj4+IHRyZW1lbmRvdXMgYW1vdW50IG9m IGRlYmF0ZSBvbiB0aGlzIGJlZm9yZSwgc28gSSdkIHByZWZlciB0byBub3QgZ28gDQo+PiB0b28g ZmFyIGluIGRpY3RhdGluZyBhdWRpbyBtYXJraW5ncyB2cy4gdmlkZW8uICBJIGRvIHRoaW5rIG1v c3QgDQo+PiBwZW9wbGUgZ2VuZXJhbGx5IGFncmVlIGFib3V0IGF0IGxlYXN0IGVuc3VyaW5nIHRo ZSBjbGFzcyBpcyB0aGUgc2FtZSwgDQo+PiBvdGhlcndpc2UgdGhlIHdpbGRseSBkaWZmZXJlbnQg UEhCIGludHJvZHVjZXMgc2tldyBiZXR3ZWVuIEEvViBwYWNrZXQgDQo+PiBhcnJpdmFsLCB0aHVz IGluZmxhdGluZyB0aGUgc2l6ZSBvZiBidWZmZXJzIG1hbmFnaW5nIHRoZSBBL1Ygc3RyZWFtcy4g IA0KPj4gSG93ZXZlciwgd2UgZG8gbm90IHdhbnQgdG8gZGljdGF0ZSB0aGF0IGF1ZGlvIHNob3Vs ZCBiZSB0cmVhdGVkIA0KPj4gc2lnbmlmaWNhbnRseSBiZXR0ZXIgdGhhbiBhdWRpby4gIEZvciBk ZWFmIHVzZXJzLCBmb3IgZXhhbXBsZSwgdGhlIA0KPj4gYXVkaW8gcmVhbGx5IGlzbid0IGltcG9y dGFudCBhdCBhbGwuICBUaGF0IGlzIHBlcmhhcHMgYW4gZXh0cmVtZSBleGFtcGxlLCBidXQgaXQg bm9uZXRoZWxlc3MgaGlnaGxpZ2h0cyB3aHkgd2Ugc2hvdWxkIGJlIGNhdXRpb3VzIGFib3V0IGV4 YWN0bHkgd2hhdCB3ZSBub3JtYXRpdmVseSBtYW5kYXRlLg0KPj4+DQo+Pj4gUGF1bA0KPj4+DQo+ Pj4gLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tDQo+Pj4gRnJvbTogUnVlZGlnZXIuR2Vp YkB0ZWxla29tLmRlDQo+Pj4gVG86IHBhdWxlakBwYWNrZXRpemVyLmNvbQ0KPj4+IENjOiBicmlh bi5lLmNhcnBlbnRlckBnbWFpbC5jb207IGRhdmlkLmJsYWNrQGVtYy5jb207IA0KPj4+IHRzdndn QGlldGYub3JnOyBydGN3ZWJAaWV0Zi5vcmcNCj4+PiBTZW50OiA1LzkvMjAxNiAzOjM0OjI1IEFN DQo+Pj4gU3ViamVjdDogQVc6IFt0c3Z3Z10gRGlmZnNlcnYgUW9TIGZvciBWaWRlbw0KPj4+DQo+ Pj4+IEhpIFBhdWwsDQo+Pj4+DQo+Pj4+IEkndmUgdGFsa2VkIHdpdGggYXVkaW8vdmlkZW8gZXhw ZXJ0cyBvZiBEZXV0c2NoZSBUZWxla29tIGFuZCB0aGV5IA0KPj4+PiB0b28gZmF2b3JlZCB3aGF0 IHlvdSByZWNvbW1lbmQgYmVsb3c6IHRyYW5zcG9ydCBhdWRpbyBhbmQgdmlkZW8gYnkgDQo+Pj4+ IHRoZSBzYW1lIHF1ZXVlLiBZb3VyIHN0YXRlbWVudCBiZWxvdyBob3dldmVyIHN0b3BzIHRoZXJl IGFuZCB0aGUgDQo+Pj4+IGRyYWZ0IHRleHQgZG9lc24ndCBjbGFyaWZ5IHRoZSBpc3N1ZToNCj4+ Pj4NCj4+Pj4gSWYgdGhlcmUncyBpbnRlcmFjdGl2ZSB2aWRlbyB3aXRoIGF1ZGlvLCB0aGVuIHRo ZXkgYm90aCBzaG91bGQgYmUgDQo+Pj4+IG1hcmtlZCBmb3IgdGhlIHNhbWUgUEhCIHdoaWNoIGlz Og0KPj4+PiAtIEVGID8NCj4+Pj4gLSBBRjQ/IExpa2UgQUY0MSBBdWRpbywgQUY0MiBWaWRlbyAo QUY0MyBpbiBhZGRpdGlvbiwgaWYgUCBvciBCIA0KPj4+PiBmcmFtZXMgYXJlIHRvIHJlY2VpdmUg YSBsb3dlciBwcmlvcml0eSAvDQo+Pj4+ICAgaGlnaGVyIGRyb3AgcHJlY2VkZW5jZSBQSEIpPw0K Pj4+Pg0KPj4+PiBJIHBlcnNvbmFsbHkgcHJlZmVyIEFGNCBpZiBhdWRpbyBhbmQgdmlkZW8gYXJl IHRvIGJlIHRyYW5zcG9ydGVkIGluIA0KPj4+PiB0aGUgc2FtZSBxdWV1ZS4NCj4+Pj4NCj4+Pj4g SSdkIGFsc28gYXNrIGZvciB0aGUgZHJhZnQgdGV4dCB0byBiZSBjbGVhciBhYm91dCB0aGUgaXNz dWUgd2hlbiB0byANCj4+Pj4gbWFyayBhdWRpbyBieSB0aGUgRUYgUEhCLiBNeSB1bmRlcnN0YW5k aW5nIGFmdGVyIHJlYWRpbmcgeW91ciANCj4+Pj4gc3RhdGVtZW50IGJlbG93IGlzOiBBdWRpbyBt YXJrZWQgRUYgaWYgdGhlcmUncyBubyB2aWRlbyBmbG93IG9ubHkuDQo+Pj4+DQo+Pj4+IC4uLg0K Pj4+PiBCQz5GaW5hbGx5LCB3aHkgaXMgYXVkaW8gbm90IGFsc28gc3ViZGl2aWRlZCBpbnRvIGlu dGVyYWN0aXZlIGFuZCANCj4+Pj4gQkM+bm9uLWludGVyYWN0aXZlPyBBcyBmYXIgYXMgSSBjYW4g c2VlLCBib3RoIGFyZSBsb2dpY2FsbHkgcG9zc2libGUuDQo+Pj4+DQo+Pj4+IFtQSl0gRm9yIFdl YlJUQywgYXVkaW8gYWxvbmUgaXMgImludGVyYWN0aXZlIiBpbiBuYXR1cmUgKHdoaWNoIGlzDQo+ Pj4+ICAgd2h5IGl0J3MgbWFya2VkIEVGKS4gIEhvd2V2ZXIsIGlmIG9uZSBpcyBzZW5kaW5nIGF1 ZGlvIGFuZCB2aWRlbw0KPj4+PiAgIGl0IG1ha2VzIHNlbnNlIHRvIG1hcmsgdGhlbSBib3RoIHNh bWUgd2F5IHRvIGdldCB0aGUgc2FtZSBQSEIgYW5kDQo+Pj4+ICAgaG9wZWZ1bGx5IGhhdmUgdGhl bSBxdWV1ZWQgaW4gdGhlIHNhbWUgYnVmZmVycyBhbG9uZyB0aGUgcGF0aC4NCj4+Pj4gICBTZW5k aW5nIGF1ZGlvIGFzIEVGIGFuZCBwb3NzaWJseSBoYXZpbmcgYSBQSEIgdGhhdCByZXN1bHRzIGlu DQo+Pj4+ICAgcGFja2V0cyBhcnJpdmluZyBtdWNoIGZhc3RlciB0aGFuIGNvcnJlc3BvbmRpbmcg dmlkZW8gcGFja2V0cw0KPj4+PiAgIG1hcmtlZCBhcyBBRjQyIGlzIG5vdCBhdCBhbGwgaGVscGZ1 bCBmb3IgYXBwbGljYXRpb25zIHRoYXQgaGF2ZQ0KPj4+PiAgIHRvIHN5bmNocm9uaXplIHRoZSBh dWRpbyBhbmQgdmlkZW8gZmxvd3MuDQo+Pj4+IC4uLg0KPj4+Pg0KPj4+PiAgIFBhdWwNCj4+Pj4N Cj4+Pj4NCj4+Pj4gUmVnYXJkcywNCj4+Pj4NCj4+Pj4gUnVlZGlnZXINCj4+Pj4NCj4+Pg0KDQo= From nobody Fri May 13 08:39:23 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 7C7E712D594; Fri, 13 May 2016 08:39:22 -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 yjDZJiSQamuj; Fri, 13 May 2016 08:39:21 -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 205A312D59B; Fri, 13 May 2016 08:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=510; q=dns/txt; s=iport; t=1463153961; x=1464363561; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/xAPsaa3+hNi9W/GNRaM0SBRGdgJ2FAcLwJovVZmUUg=; b=V0CAtLyykOGR6aqYw6Boc+j025UEtomWIUEi36iEUkOzMbbZGEOjvWTt de1fS+0LGHO1n4PTLtefnELiUEMSHQpyfAu5/APiRarmgNfPO8J8p8qRb 0ZhcBoUjVl2mpb28SJ+JsHRIwQZ4IUJBoW9zRq2ydkoFcx84wc1WQs75Z M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BoAgBu9DVX/4kNJK1egzeBUwa5UAENg?= =?us-ascii?q?XaGEQKBLDgUAQEBAQEBAWUcC4RCAQEBAwE6PwULAgEIGB4QMiUCBA4FiCcIwRs?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEciBsIgk+EP4Mrgi4BBJgnAY4dgVONRo9AA?= =?us-ascii?q?R4BAUKDbG6HW38BAQE?= X-IronPort-AV: E=Sophos;i="5.24,614,1454976000"; d="scan'208";a="271387147" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 May 2016 15:39:20 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4DFdKXa027006 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 May 2016 15:39:20 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, 13 May 2016 11:39:19 -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, 13 May 2016 11:39:19 -0400 From: "Cullen Jennings (fluffy)" To: "Ruediger.Geib@telekom.de" Thread-Topic: [tsvwg] Diffserv QoS for Video Thread-Index: AQHRrS2dZ/47y6ykhEqiDL26Kx1AUA== Date: Fri, 13 May 2016 15:39:19 +0000 Message-ID: <986DFBC3-AE46-4D9C-8884-128047EF9777@cisco.com> References: <828773FE19B05B4581311493A046E85E6ECC3084D0@HE111642.emea1.cds.t-internal.com> <828773FE19B05B4581311493A046E85E6ECC4090FD@HE111642.emea1.cds.t-internal.com> In-Reply-To: <828773FE19B05B4581311493A046E85E6ECC4090FD@HE111642.emea1.cds.t-internal.com> 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] Diffserv QoS for Video 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, 13 May 2016 15:39:22 -0000 > On May 10, 2016, at 12:56 AM, Ruediger.Geib@telekom.de wrote: >=20 > I think we agree, that audio and video frames, if both are part of the sa= me (interactive) media flow should be transported by the same PHB [PJ] or t= he same queue [RG].=20 I don't think we have consensus on that in the ART area but my understandin= g of this spec was that it allowed people that wanted to do that to give th= em the same and it allowed people that wanted to implement the different qu= eues to do that.=20 From nobody Wed May 18 12:47: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 A8CED128B44; Wed, 18 May 2016 12:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.747 X-Spam-Level: X-Spam-Status: No, score=-5.747 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 Xaxq47abnVKs; Wed, 18 May 2016 12:47:30 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (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 2662E12D692; Wed, 18 May 2016 12:47:21 -0700 (PDT) Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u4IJlFII009502 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 May 2016 15:47:17 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com u4IJlFII009502 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1463600837; bh=2k0oIEgwX8sLityQfwJU+UTwibc=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=rxqN64dh3bECMtL2ztt1Y+bzGslvzkdsgh2tW52CyK8HxIV5Nv9UYSN6SBfQNfCUT JukXdIBlvzY7Zty0K8/wPL5Ukm+S2xan2Hy2ayJkASdwPBcr1oR1SBDc6W+SV84sQC rVEi7+f+I4r843Ek6iglV0B5xCDZQu+8ARfowgOM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com u4IJlFII009502 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd01.lss.emc.com (RSA Interceptor); Wed, 18 May 2016 15:44:23 -0400 Received: from MXHUB215.corp.emc.com (MXHUB215.corp.emc.com [10.253.68.85]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u4IJl84L031113 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 18 May 2016 15:47:09 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.85]) by MXHUB215.corp.emc.com ([10.253.68.85]) with mapi id 14.03.0266.001; Wed, 18 May 2016 15:47:08 -0400 From: "Black, David" To: Suresh Krishnan , The IESG Thread-Topic: Suresh Krishnan's No Objection on draft-ietf-tsvwg-rtcweb-qos-16: (with COMMENT) Thread-Index: AQHRsL3pgmZGYRZOg0C3APxN5SCGMp+/FCoQ Date: Wed, 18 May 2016 19:47:08 +0000 Message-ID: References: <20160518042945.24804.1258.idtracker@ietfa.amsl.com> In-Reply-To: <20160518042945.24804.1258.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.115] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "rtcweb@ietf.org" , "Black, David" , "draft-ietf-tsvwg-rtcweb-qos@ietf.org" , "tsvwg-chairs@ietf.org" , "tsvwg@ietf.org" Subject: Re: [rtcweb] Suresh Krishnan's No Objection on draft-ietf-tsvwg-rtcweb-qos-16: (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: Wed, 18 May 2016 19:47:31 -0000 SGkgU3VyZXNoLA0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50cy4NCg0KPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IFNlY3Rpb24gNToNCj4gDQo+IFRo ZSBkcmFmdCBjbGFpbXMgdGhhdCAiQ3VycmVudGx5LCBhbGwgV2ViUlRDIHZpZGVvIGlzIGFzc3Vt ZWQgdG8gYmUNCj4gaW50ZXJhY3RpdmUiIGFuZCBtYWtlcyBhIHJlZmVyZW5jZSB0byBbSS1ELmll dGYtcnRjd2ViLXRyYW5zcG9ydHNdLCBidXQNCj4gdGhlIHJlZmVycmVkIGRyYWZ0IGRvZXMgbm90 IGNvbnRhaW4gYW55IGV4cGxhbmF0aW9uIHJlZ2FyZGluZyB0aGlzLiBJcw0KPiB0aGlzIHNvbWUg a2luZCBvZiB3ZWxsIGtub3duIGZhY3QgaW4gV2ViUlRDIGNpcmNsZXM/IElmIHNvLCBpcyBpdA0K PiBkb2N1bWVudGVkIHNvbWV3aGVyZT8NCg0KVGhlIHNoZXBoZXJkIHdyaXRlLXVwIGNvdmVyZWQg dGhpcyB0b3BpYyBpbiBwYXJ0Og0KDQogICBJRVRGIExDIGRpc2N1c3Npb24gcmVzdWx0ZWQgaW4g bWlub3IgZWRpdHMgYW5kIHJlc29sdXRpb24gb2Ygb25lIGlzc3VlLg0KICAgVGhlIGlzc3VlIGFy b3NlIHdoZW4gTWFnbnVzIFdlc3Rlcmx1bmQgYXNrZWQgdGhlIChzZWVtaW5nbHkgc2ltcGxlKQ0K ICAgcXVlc3Rpb24gb2YgaG93IGEgYnJvd3NlciBkZXRlcm1pbmVzIHdoZXRoZXIgV2ViUlRDIHZp ZGVvIGlzIGludGVyYWN0aXZlLg0KDQogICBUaGUgYW5zd2VyIHR1cm5zIG91dCB0byBiZSB0aGF0 IHRoZSBicm93c2VyIGRvZXNuJ3QgZG8gdGhhdCAtIGFsbCBXZWJSVEMNCiAgIHZpZGVvIChhbmQg YWN0dWFsbHkgYWxsIG1lZGlhKSBpcyBpbnRlcmFjdGl2ZSBmb3IgYSBXZWJSVEMgYXBwbGljYXRp b24NCiAgIHJ1bm5pbmcgaW4gYSBicm93c2VyIGJlY2F1c2UgdGhlIFdlYlJUQyBicm93c2VyIEFQ SSBjYW4ndCBzcGVjaWZ5IHRoYXQNCiAgIHZpZGVvIChvciBtZWRpYSkgaXMgbm9uLWludGVyYWN0 aXZlLiAgIEluIGFkZGl0aW9uIHRvIGV4cGxhaW5pbmcgdGhhdCBpbg0KICAgdGhpcyBkcmFmdCwg dGhlIG5leHQgdmVyc2lvbiAoLTEzKSBvZiB0aGUgV2ViUlRDIHRyYW5zcG9ydHMgZHJhZnQNCiAg IChkcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzKSB3aWxsIHN0YXRlIHRoYXQgYWxsIFdlYlJU QyBtZWRpYSBpcw0KICAgaW50ZXJhY3RpdmUuDQoNClRoZXJlIGlzIGFncmVlZC10byB0ZXh0IGZv ciB0aGUgV2ViUlRDIHRyYW5zcG9ydHMgZHJhZnQsIHNvIEknbSBhIGJpdCBzdXJwcmlzZWQNCnRo YXQgdGhlIHJldmlzZWQgKC0xMykgdmVyc2lvbiBvZiB0aGF0IGRyYWZ0IGhhc24ndCBhcHBlYXJl ZCB5ZXQuICAgSSdtIGNjOidpbmcNCnRoZSBSVENXRUIgV0cgbWFpbGluZyBsaXN0IHRvIChnZW50 bHkpIHJlbWluZCBIYXJhbGQgdG8gcmV2aXNlIGFuZCBwb3N0IHRoYXQNCmRyYWZ0LCBzb29uIHBs ZWFzZSA7LSkuDQoNCkkgd291bGQgc3VnZ2VzdCB0aGF0IFNwZW5jZXIgcHJvbWlzZSBub3QgdG8g YW5ub3VuY2UgSUVTRyBhcHByb3ZhbA0Kb2YgdGhpcyB0c3Z3Zy1ydGN3ZWItcW9zIGRyYWZ0IHVu dGlsIHRoYXQgbmVjZXNzYXJ5IHZlcnNpb24gb2YgdGhlIFdlYlJUQw0KdHJhbnNwb3J0cyBkcmFm dCBpcyBwb3N0ZWQuDQoNCj4gU2VjdGlvbiA4Og0KPiANCj4gSXMgdGhpcyByZWFsbHkgcmVxdWly ZWQgdG8gYmUgaW4gdGhlIGRvY3VtZW50PyBUaGUgc2hlcGhlcmQgd3JpdGV1cCBkb2VzDQo+IGV4 cGxhaW4gdGhlIHJhdGlvbmFsZSBmb3IgdGhlIGRvd25yZWZzLg0KDQpUaGlzIGRvd25yZWYgZXhw bGFuYXRpb24gd2FzIGFkZGVkIGJhc2VkIG9uIGEgInNob3cgeW91ciB3b3JrIiByYXRpb25hbGUg LQ0KcGFydCBvZiB0aGUgY29udGV4dCBvbiBpcyB0aGF0IHRoZXJlIGhhcyBiZWVuIHNvbWUgcmVj ZW50IGRpc2N1c3Npb24gaW4gVFNWV0cNCmFib3V0IGEgcG9zc2libGUgcmV2aXNpb24gdG8gUkZD IDQ1OTQsIG9uZSBvZiB0aGUgZG93bnJlZi1lZCBSRkNzLiANCg0KSWYgdGhlIElFU0cgd291bGQg bGlrZSB0byBzZWUgU2VjdGlvbiA4IHJlbW92ZWQsIHRoYXQgd29uJ3QgYmUgYSBwcm9ibGVtLCAN CmJ1dCBJJ2QgcHJlZmVyIHRvIHNlZSBndWlkYW5jZSBvbiB0aGlzIGZyb20gdGhlIElFU0cgYXMg YSB3aG9sZS4NCg0KVGhhbmtzLA0KLS1EYXZpZCAoYXMgZHJhZnQgc2hlcGhlcmQpLg0KDQo= From nobody Mon May 23 09:58: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 B662C12DA40 for ; Mon, 23 May 2016 09:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtrabjC-d1zZ for ; Mon, 23 May 2016 09:58:05 -0700 (PDT) Received: from smtp105.iad3a.emailsrvr.com (smtp105.iad3a.emailsrvr.com [173.203.187.105]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B64312D935 for ; Mon, 23 May 2016 09:58:02 -0700 (PDT) Received: from smtp6.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp6.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id EC05B180362; Mon, 23 May 2016 12:57:56 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp6.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 8F0291804CD; Mon, 23 May 2016 12:57:56 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.92.108.159] (184-23-135-130.dedicated.static.sonic.net [184.23.135.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Mon, 23 May 2016 12:57:56 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF260FFABF@MCHP04MSX.global-ad.net> Date: Mon, 23 May 2016 08:42:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4CD65A98-7FFE-4E24-A258-E022509E0A32@iii.ca> References: <571DE213.8080306@goodadvice.pages.de> <9F33F40F6F2CD847824537F3C4E37DDF260FFABF@MCHP04MSX.global-ad.net> To: "Hutton, Andrew" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [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, 23 May 2016 16:58:07 -0000 I=E2=80=99m not sure there is a requirement for a WebRTC endpoint to = generate them but if there is, agree that we should say TIAS is = preferred.=20 > On May 11, 2016, at 8:55 AM, Hutton, Andrew = wrote: >=20 > I was also looking at this again my assumption is that TIAS is what a = WebRTC endpoint should generate TIAS as Philipp stated this is hinted at = in the W3C spec but probably also should be specified in JSEP and an = example in = https://tools.ietf.org/html/draft-ietf-rtcweb-sdp-01#section-5.2.2 would = also be useful. >=20 > For parsing then both TIAS and AS needs to be supported this is = specified in = https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-14#section-5.8.=20 >=20 > Regards > Andy >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Philipp >> Hancke >> Sent: 25 April 2016 10:24 >> To: rtcweb@ietf.org >> Subject: [rtcweb] which bandwidth modifiers need to be supported? >>=20 >> which bandwidth modifiers for b=3D lines does a client need to = support? >>=20 >> Chrome currently supports b=3DAS, however the implementation is = closer to >> TIAS semantically. Firefox does not implement either currently. >>=20 >> http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters- >> maxBitrate >> uses TIAS as a definition. >>=20 >> 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. >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed May 25 03:04:49 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E190F12D9E3 for ; Wed, 25 May 2016 03:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] 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 NGufgvhDCXi5 for ; Wed, 25 May 2016 03:04:45 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA3612DA80 for ; Wed, 25 May 2016 03:03:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id F3B5D7C7E6A for ; Wed, 25 May 2016 12:03:35 +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 O6monsHiXBN1 for ; Wed, 25 May 2016 12:03:34 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:12:c86f:6f80:194b:9465]) by mork.alvestrand.no (Postfix) with ESMTPSA id 4B9857C7E64 for ; Wed, 25 May 2016 12:03:34 +0200 (CEST) To: rtcweb@ietf.org References: From: Harald Alvestrand Message-ID: <57457874.1010708@alvestrand.no> Date: Wed, 25 May 2016 12:03:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040204050708010808010908" Archived-At: Subject: Re: [rtcweb] Security architecture: Making ECDSA mandatory 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, 25 May 2016 10:04:48 -0000 This is a multi-part message in MIME format. --------------040204050708010808010908 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit In my search for status on ECDSA (we're in the process of switching the Chrome default), I came across this in the current draft: All implementations MUST implement DTLS 1.0, with the cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and the DTLS-SRTP protection profile SRTP_AES128_CM_HMAC_SHA1_80. Implementations SHOULD implement DTLS 1.2 with the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite. Implementations SHOULD favor cipher suites which support PFS over non-PFS cipher suites and GCM over CBC cipher suites. [[OPEN ISSUE: Should we require ECDSA? Waiting for WG Consensus.]] I also found Martin's PR. It's 11 months old, still open. Can we merge this now? On 06/13/2015 12:06 AM, Martin Thomson wrote: > I've opened https://github.com/rtcweb-wg/security-arch/pull/33 > > This changes the MTI cipher suites to ECDSA and does a little cleanup > on the corresponding API requirements to more closely match what has > just landed in the W3C specification. > > We discussed ECDSA and the only concerns raised were with > compatibility. I've done some testing with other implementations with > no issues, and ECDSA seems to be well supported on all those > hard-to-upgrade PSTN gateways (thanks to Cullen and Ethan for helping > out with checks there and to NIST for creating certification pressure > with FIPS-2). > > I have an implementation that switches Firefox to ECDSA with P-256 by > default. It's much, much faster. http://bench.cr.yp.to/ claims that > it's 150 times faster on mobile devices for keygen. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------040204050708010808010908 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
In my search for status on ECDSA (we're in the process of switching the Chrome default), I came across this in the current draft:

   All implementations MUST implement DTLS 1.0, with the cipher suite
   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and the DTLS-SRTP protection
   profile SRTP_AES128_CM_HMAC_SHA1_80.  Implementations SHOULD
   implement DTLS 1.2 with the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
   cipher suite.  Implementations SHOULD favor cipher suites which
   support PFS over non-PFS cipher suites and GCM over CBC cipher
   suites.  [[OPEN ISSUE: Should we require ECDSA?  Waiting for WG
   Consensus.]]
I also found Martin's PR. It's 11 months old, still open.

Can we merge this now?


On 06/13/2015 12:06 AM, Martin Thomson wrote:
I've opened https://github.com/rtcweb-wg/security-arch/pull/33

This changes the MTI cipher suites to ECDSA and does a little cleanup
on the corresponding API requirements to more closely match what has
just landed in the W3C specification.

We discussed ECDSA and the only concerns raised were with
compatibility.  I've done some testing with other implementations with
no issues, and ECDSA seems to be well supported on all those
hard-to-upgrade PSTN gateways (thanks to Cullen and Ethan for helping
out with checks there and to NIST for creating certification pressure
with FIPS-2).

I have an implementation that switches Firefox to ECDSA with P-256 by
default.  It's much, much faster.  http://bench.cr.yp.to/ claims that
it's 150 times faster on mobile devices for keygen.

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

--------------040204050708010808010908-- From nobody Wed May 25 03:17: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 7666E12D66A for ; Wed, 25 May 2016 03:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 c5NFhk_7S5bt for ; Wed, 25 May 2016 03:17:07 -0700 (PDT) Received: from out.tornado.email (out.tornado.email [195.159.144.141]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3E312DA16 for ; Wed, 25 May 2016 03:17:06 -0700 (PDT) Received: from [62.96.148.44] (helo=Alfreds-MacBook-Pro-2.local) by out.tornado.email with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1b5VsP-0002VY-7B; Wed, 25 May 2016 12:17:21 +0200 To: Martin Thomson , "rtcweb@ietf.org" References: From: "Alfred E. Heggestad" Message-ID: <57457B9F.7060709@db.org> Date: Wed, 25 May 2016 12:17:03 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 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] Security architecture: Making ECDSA mandatory 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, 25 May 2016 10:17:09 -0000 On 13/06/15 00:06, Martin Thomson wrote: > I've opened https://github.com/rtcweb-wg/security-arch/pull/33 > > This changes the MTI cipher suites to ECDSA and does a little cleanup > on the corresponding API requirements to more closely match what has > just landed in the W3C specification. > > We discussed ECDSA and the only concerns raised were with > compatibility. I've done some testing with other implementations with > no issues, and ECDSA seems to be well supported on all those > hard-to-upgrade PSTN gateways (thanks to Cullen and Ethan for helping > out with checks there and to NIST for creating certification pressure > with FIPS-2). > > I have an implementation that switches Firefox to ECDSA with P-256 by > default. It's much, much faster. http://bench.cr.yp.to/ claims that > it's 150 times faster on mobile devices for keygen. > I can confirm this. Here at Wire.com we are using ECDSA certs for the DTLS connections. Generating self-signed certs takes around 1 millisecond. /alfred From nobody Wed May 25 08:12:59 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F3B12D7BF for ; Wed, 25 May 2016 08:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, 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 HYVn_4Qi4Ss0 for ; Wed, 25 May 2016 08:12:55 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5682412D837 for ; Wed, 25 May 2016 08:11:13 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id c127so50308609ywb.1 for ; Wed, 25 May 2016 08:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=EtwTzOO0+8dB718DECa8jEept0CZIxgmfOhOXGG3tx8=; b=NvcN0CcSk8yjFzPxwZ2YmrivgpCUwNm+x5Y73xfE4XEIAT19yNKmJo6+PMOs4x9Ff+ Rnvl0VM1tG66XOxPKAAGL6/WAj3xlF/v+7/M2lLAdgpbW4tre7jx+lJJC6oZPmwMeaTK x4dpS3k1ifPdrA+RG+WWB0JgUTI7et83IBxLDcimclJY8XlFS49+A197FOrC/AWO7vr1 GZdNKixKdPiraq97y2aFwwL1sU4+I4v6auXKNtBlOwSn+93XlLthDs4Li/NgFg6f6t4C I4xHkm09qcpKUrsAZLiMJ4jJ9p8X/FglTK9/by9JpFWdPgjW0Lv+z/MDmgfOqKcm8yM0 FNbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=EtwTzOO0+8dB718DECa8jEept0CZIxgmfOhOXGG3tx8=; b=B4VWnw8ViswP7/bEIB6iVpNE4l1+I+YNm4NAJTyKyKNZFJ8RI1CJIX6KnedmIarP9E i51eXjgIdPcYnb/0r9YN9oXCNVIZfcAsWy2uCoc9paIAelJ/KKQjRTp2JnCGhFGRU8O0 jirNwDLLttX/SNPx1UwE8E29IVQllIfsQOx42VvqZUX8ObIX9QU9q9hGpgIscIefEV8v 4bmZStiHfzUWJLOMnrFXHGV6RKnvsGuRiXJ9+2krK5GxwAyazSm+ODKExwaVMAEmGYfE tHzaSFJ7WpU7FFGbjhoO4BVNJtdzZ/rc8NRh+5mfzrG5XC5LESGebQliL+mTc5rTDhuz D/SQ== X-Gm-Message-State: ALyK8tJy9pVk5uyjDQCwTAs1YqV6pSZ0R2EihZGFHFEB/wp5dqj8CzMZlQpLz+xq0MAzhQgthoyQoTHAZwXaww== X-Received: by 10.13.212.142 with SMTP id w136mr2680342ywd.226.1464189072549; Wed, 25 May 2016 08:11:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.240.194 with HTTP; Wed, 25 May 2016 08:10:53 -0700 (PDT) In-Reply-To: <57457B9F.7060709@db.org> References: <57457B9F.7060709@db.org> From: Michael Davey Date: Wed, 25 May 2016 16:10:53 +0100 Message-ID: To: "Alfred E. Heggestad" Content-Type: multipart/alternative; boundary=001a114fb5a28dafb10533ac158c Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Security architecture: Making ECDSA mandatory X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: md84419@gmail.com List-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, 25 May 2016 15:12:58 -0000 --001a114fb5a28dafb10533ac158c Content-Type: text/plain; charset=UTF-8 I would recommend referencing IETF BCP 195. The comments about ECDHE in that document (and of course the wider issues with weak DH key exchange) may also be noteworthy. -- Michael On 25 May 2016 at 11:17, Alfred E. Heggestad wrote: > > > On 13/06/15 00:06, Martin Thomson wrote: > >> I've opened https://github.com/rtcweb-wg/security-arch/pull/33 >> >> This changes the MTI cipher suites to ECDSA and does a little cleanup >> on the corresponding API requirements to more closely match what has >> just landed in the W3C specification. >> >> We discussed ECDSA and the only concerns raised were with >> compatibility. I've done some testing with other implementations with >> no issues, and ECDSA seems to be well supported on all those >> hard-to-upgrade PSTN gateways (thanks to Cullen and Ethan for helping >> out with checks there and to NIST for creating certification pressure >> with FIPS-2). >> >> I have an implementation that switches Firefox to ECDSA with P-256 by >> default. It's much, much faster. http://bench.cr.yp.to/ claims that >> it's 150 times faster on mobile devices for keygen. >> >> > I can confirm this. Here at Wire.com we are using ECDSA certs for the > DTLS connections. Generating self-signed certs takes around 1 millisecond. > > > > /alfred > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a114fb5a28dafb10533ac158c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would recommend referencing IETF BCP 195.=C2=A0 The= comments about ECDHE in that document (and of course the wider issues with= weak DH key exchange) may also be noteworthy.

--
Michael<= br>

On 25 May = 2016 at 11:17, Alfred E. Heggestad <aeh@db.org> wrote:


On 13/06/15 00:06, Martin Thomson wrote:
I've opened https://github.com/rtcweb-wg/secur= ity-arch/pull/33

This changes the MTI cipher suites to ECDSA and does a little cleanup
on the corresponding API requirements to more closely match what has
just landed in the W3C specification.

We discussed ECDSA and the only concerns raised were with
compatibility.=C2=A0 I've done some testing with other implementations = with
no issues, and ECDSA seems to be well supported on all those
hard-to-upgrade PSTN gateways (thanks to Cullen and Ethan for helping
out with checks there and to NIST for creating certification pressure
with FIPS-2).

I have an implementation that switches Firefox to ECDSA with P-256 by
default.=C2=A0 It's much, much faster.=C2=A0 http://bench.cr.yp.to/ cl= aims that
it's 150 times faster on mobile devices for keygen.


 I can confirm this. Here at Wire.com we are using ECDSA certs for the
DTLS connections. Generating self-signed certs takes around 1 millisecond.<= span class=3D"HOEnZb">



/alfred


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

--001a114fb5a28dafb10533ac158c-- From nobody Wed May 25 16:48:44 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDDF12DE3F; Wed, 25 May 2016 16:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.328 X-Spam-Level: X-Spam-Status: No, score=-108.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 3CInYKlMzYYC; Wed, 25 May 2016 16:48:40 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6912E12DE2F; Wed, 25 May 2016 16:48:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9C0FD180006; Wed, 25 May 2016 16:48:04 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160525234804.9C0FD180006@rfc-editor.org> Date: Wed, 25 May 2016 16:48:04 -0700 (PDT) Archived-At: Cc: rtcweb@ietf.org, rfc-editor@rfc-editor.org Subject: [rtcweb] RFC 7874 on WebRTC Audio Codec and Processing Requirements 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, 25 May 2016 23:48:43 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7874 Title: WebRTC Audio Codec and Processing Requirements Author: JM. Valin, C. Bran Status: Standards Track Stream: IETF Date: May 2016 Mailbox: jmvalin@jmvalin.ca, cary.bran@plantronics.com Pages: 7 Characters: 16160 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-rtcweb-audio-11.txt URL: https://www.rfc-editor.org/info/rfc7874 DOI: http://dx.doi.org/10.17487/RFC7874 This document outlines the audio codec and processing requirements for WebRTC endpoints. This document is a product of the Real-Time Communication in WEB-browsers Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed May 25 16:49: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 2128812DE4B; Wed, 25 May 2016 16:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.328 X-Spam-Level: X-Spam-Status: No, score=-108.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 NUvwUXZ6OFzy; Wed, 25 May 2016 16:48:54 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7475E12DE48; Wed, 25 May 2016 16:48:54 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 94EB3180006; Wed, 25 May 2016 16:48:18 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160525234818.94EB3180006@rfc-editor.org> Date: Wed, 25 May 2016 16:48:18 -0700 (PDT) Archived-At: Cc: rtcweb@ietf.org, rfc-editor@rfc-editor.org Subject: [rtcweb] RFC 7875 on Additional WebRTC Audio Codecs for Interoperability 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, 25 May 2016 23:49:00 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7875 Title: Additional WebRTC Audio Codecs for Interoperability Author: S. Proust, Ed. Status: Informational Stream: IETF Date: May 2016 Mailbox: stephane.proust@orange.com Pages: 12 Characters: 26626 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-rtcweb-audio-codecs-for-interop-06.txt URL: https://www.rfc-editor.org/info/rfc7875 DOI: http://dx.doi.org/10.17487/RFC7875 To ensure a baseline of interoperability between WebRTC endpoints, a minimum set of required codecs is specified. However, to maximize the possibility of establishing 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 use cases most relevant to interoperability. This document is a product of the Real-Time Communication in WEB-browsers Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon May 30 15:14:50 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE5212D695 for ; Mon, 30 May 2016 15:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, 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 nQ5QxQNo0U7y for ; Mon, 30 May 2016 15:14:47 -0700 (PDT) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id 463E012D147 for ; Mon, 30 May 2016 15:14:45 -0700 (PDT) X-AuditID: 12074413-473ff700000008c7-e1-574cbb557bc6 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by (Symantec Messaging Gateway) with SMTP id F3.7F.02247.55BBC475; Mon, 30 May 2016 18:14:45 -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 u4UMEiVf007621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 30 May 2016 18:14:44 -0400 To: "rtcweb@ietf.org" From: Paul Kyzivat Message-ID: Date: Mon, 30 May 2016 18:14:53 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHIsWRmVeSWpSXmKPExsUixO6iqBu62yfcoPktp8Xaf+3sDoweS5b8 ZApgjOK2SUosKQvOTM/Tt0vgzujsnsVcMFezYvWkFtYGxp0KXYycHBICJhLnd/1j6mLk4hAS 2MooceTqRUYI5zeTxK9jN5lAqkQE1CUuP7zADmKzCWhJzDn0nwXEFhYwlpi65h9QAwcHr4C9 xO2v5iBhFgFVifUNn9lAbFGBNImz104wg9i8AoISJ2c+AWtlFjCTmLf5ITOELS+x/e0c5gmM PLOQlM1CUjYLSdkCRuZVjHKJOaW5urmJmTnFqcm6xcmJeXmpRbrmermZJXqpKaWbGCFhI7yD cddJuUOMAhyMSjy8DJ0+4UKsiWXFlbmHGCU5mJREeVtLgUJ8SfkplRmJxRnxRaU5qcWHGCU4 mJVEeC/vAsrxpiRWVqUW5cOkpDlYlMR51Zao+wkJpCeWpGanphakFsFkZTg4lCR4G0AaBYtS 01Mr0jJzShDSTBycIMO5pESKU/NSUosSS0sy4kGRFF8MjCWQFA/Q3jNge4sLEnOBohCtpxgV pcR5r+8ESgiAJDJK8+DGwpLBK0ZxoC+Feb+AVPEAEwlc9yugwUxAg+MzwAaXJCKkpBoY17Qf uLvlytbdZecffLVcbPmkegnn0jbn8iPWO45aKDakXjx9dV5Q1P0dIknv720UbtlzQnWdwQSz rljx3b4rLwe//n5ssc3Pf+Z31sUaN03vN786r3z7PJslqu5ny+onM3xx4PPLYfnxsyyA5d3B VecDXDaHznxzZZPtB3+OchbtK56Pa62KMpRYijMSDbWYi4oTAVaJD13hAgAA Archived-At: Subject: [rtcweb] partial review of draft-ietf-rtcweb-sdp-01 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, 30 May 2016 22:14:50 -0000 Ted asked if I would do a review of draft-ietf-rtcweb-sdp-01. I started, but it is taking a long time. I'm sending what I have so far to give you something to consider/work on. In order to simplify this review for both me and readers, I will in general only mention an issue once, the first time I find it, and be silent on future occurrences of the same issue. * In general in the examples it would be very helpful if you would include a blank line prior to each m-line. When reading these it is currently hard to find the m-lines, which is something needed when trying understand and compare things. * Section 3: I realize this is for a webrtc oriented reader, so I am trying to understand it from that perspective. Even so, I have trouble with classifying a=ice* as "Security Descriptions". Given the existing categories I would think they better belong in "Stream Description". * Section 5.1: o The term "Session" is used rather loosely in this document to refer to either a "Communication Session" or a "RTP Session" or a "RTP Stream" depending on the context. This seems like a bad idea. It may be forgivable to mix communication session and RTP session in examples where a single bundle is used for all media, or there is only one m-line. But not if multiple m-lines aren't bundled, and not with RTP Stream. OTOH, so far I haven't noticed any place where this is an issue. * Section 5.2.1: The SDP line-wrapping convention described in 5.1 isn't being used in the example. Is there a reason for including the IP address in the a=rtcp line, when it is the same as the address in the c= line, which is the default? Is there any expectation that a=ptime:60 only applies to opus? IIUC this should be interpreted ad applying to all codecs mentioned in the m-line. (There is no order-dependence among attributes within a single media section. AFAIK there is no way of specifying a separate ptime for individual codecs in an m-line.) Use of sha-1 in a=fingerprint is about to become incorrect according to draft-ietf-mmusic-4572-update-03. That work is being driven by rtcweb, so I would think you would want to reflect it here. The way tables are formatted in RFC format can make the examples confusing to readers: the label for table 1 falls exactly between the bottom of the table it describes and the following table. When viewed on a screen it is difficult to tell what each table is. I suggest tweaking the contents of the tables to make this clearer. E.g., +----------------------------------+--------------------------------+ | SDP Contents - Offer | RFC#/Notes | +----------------------------------+--------------------------------+ In Table 2, the o-line has two spaces after the "-". It should only be one. * Section 5.2.3: Table 5 has ice and fingerprint attributes prior to the first m-line. The m-line and associated attributes for the data channel is inconsistent with draft-ietf-mmusic-sctp-sdp-16. I think it ought to be (more or less): m=application 56966 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 24.23.204.141 a=mid:data a=sctp-port:5000 a=setup:actpass ... If you really want to negotiate the usage of channel 1, then it also needs to include: a=dcmap:1 subprotocol="chat";label="channel 1" (Note: this presumes that "chat" is a registered subprotocol. It isn't!) * Section 5.2.4: This seems fine if Bob intends to send audio (e.g. MoH). If not then it would be better to answer a=inactive. * Section 5.2.5: Has there been any discussion of pros/cons of having DTMF on a separate m-line and a separate ssrc? If one or both ends actually think of DTMF as being part of another audio stream then this might present problems. This could especially be true for interoperation with telephony devices. Is there anything in rtcweb that prevents having these on the same m-line and ssrc? * Section 5.2.7: Note that the BAS concept has been removed from Bundle, so you at least shouldn't refer to it. (You can still do the O/A if you want.) In Table 14 (answer), why are ice attributes and fingerprints given separately (and differently) for the two m-lines? (Even though the ports and addresses are the same.) This is contrary to current bundle (-29) procedures. In the 2nd (BAS) offer there is a gratuitous change in ordering of several of the attributes. (Makes it difficult to see what has changed.) I also don't understand the other differences between the ice and fingerprints in audio and video, and between this and the first offer. * Section 5.2.8: This example *assumes* bundle support, and so uses the same addr/port for bundled m-lines. But this will fail badly if the assumption turns out to be wrong. When making this assumption you ought to use bundle-only in the initial offer to ensure nothing bad happens if the assumption of bundle support by answerer turns out to be wrong. AFAIK there is no downside to doing this. Again this doesn't follow current bundle rules. ======= That's as far as I have gotten. (Slow going.) I'll try to get you more later. Thanks, Paul From nobody Tue May 31 12:09:53 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 D415212D892 for ; Tue, 31 May 2016 12:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 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_SOFTFAIL=0.665] 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 iid7YF5lp-mZ for ; Tue, 31 May 2016 12:09:39 -0700 (PDT) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (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 E141212D0B3 for ; Tue, 31 May 2016 12:09:38 -0700 (PDT) Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by comcast with SMTP id 7p1dbzdL7IY3M7p2nbiOXZ; Tue, 31 May 2016 19:09:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1464721777; bh=4fSnhWB1S/amtKpYXY1ewMz6faR3zALp5sIpCwcpJt4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=ZbgOkc2uwwdWAg90JH5g0TfqBh6RpNKdvzDLwakB8Rdu/rI2p1vSuNyeZuuavbGTv CCmjBn6z/tj/jm/J2t8XkY7tySn/YohRI7GnPUjDpSVTaX1nZCNQrdvOl51T07SBEs xQIi1bgrbqdxCfZDFHUCVuRncDXJuQK33ZrlpoZAzVJ7H8Lc+8gS6RM4pDg/0fkP+M 32Q0eIRI8OA+qhoGLw3IrJ7VNx3Po+q2kYju3yo0lPATBO28TppyZnEShcq3zl14S2 R7qmA01QOj4uKU99MJAgTrFYZ273r88BMzT7ejMf3e1SdFXANMFy0jcp/KbRXZVOID zs4riNLEGeqUg== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-18v.sys.comcast.net with comcast id 179c1t00R3KdFy10179cAQ; Tue, 31 May 2016 19:09:37 +0000 To: rtcweb@ietf.org References: From: Paul Kyzivat Message-ID: <20582c8f-be8e-abc7-32b9-4b21166102e2@alum.mit.edu> Date: Tue, 31 May 2016 15:09:35 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 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] partial review of draft-ietf-rtcweb-sdp-01 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, 31 May 2016 19:09:41 -0000 Another general issue: I have been *trying* to verify the consistency in use of ports, IP addresses, fingerprints, ice ufrag info, ice passwords, ssrcs, cnames, etc. Of course this is excruciating to do. (For a reviewer like me, and also for a potential implementer trying to understand the examples.) My preliminary take is that there are a number of errors. A lot of them are probably cut/paste errors. With sufficient analysis it is sometimes possible to figure out what was intended vs. what is written. But it is hard with this much stuff. It would be easier if, instead of using random sample values, the values were replaced with semantically relevant and easily recognized values. (E.g., "ALICE-SSRC-1", "TED-CNAME-2") Unfortunately I don't think this can be done while also having those values by syntactically valid. I think I will end up making such a replacement myself, in a local copy, simply to assist in analyzing what is there. Thanks, Paul On 5/30/16 6:14 PM, Paul Kyzivat wrote: > Ted asked if I would do a review of draft-ietf-rtcweb-sdp-01. I started, > but it is taking a long time. I'm sending what I have so far to give you > something to consider/work on. > > In order to simplify this review for both me and readers, I will in > general only mention an issue once, the first time I find it, and be > silent on future occurrences of the same issue. > > * In general in the examples it would be very helpful if you would > include a blank line prior to each m-line. When reading these it is > currently hard to find the m-lines, which is something needed when > trying understand and compare things. > > * Section 3: > > I realize this is for a webrtc oriented reader, so I am trying to > understand it from that perspective. Even so, I have trouble with > classifying a=ice* as "Security Descriptions". Given the existing > categories I would think they better belong in "Stream Description". > > * Section 5.1: > > o The term "Session" is used rather loosely in this document to > refer to either a "Communication Session" or a "RTP Session" or a > "RTP Stream" depending on the context. > > This seems like a bad idea. It may be forgivable to mix communication > session and RTP session in examples where a single bundle is used for > all media, or there is only one m-line. But not if multiple m-lines > aren't bundled, and not with RTP Stream. > > OTOH, so far I haven't noticed any place where this is an issue. > > * Section 5.2.1: > > The SDP line-wrapping convention described in 5.1 isn't being used in > the example. > > Is there a reason for including the IP address in the a=rtcp line, when > it is the same as the address in the c= line, which is the default? > > Is there any expectation that a=ptime:60 only applies to opus? IIUC this > should be interpreted ad applying to all codecs mentioned in the m-line. > (There is no order-dependence among attributes within a single media > section. AFAIK there is no way of specifying a separate ptime for > individual codecs in an m-line.) > > Use of sha-1 in a=fingerprint is about to become incorrect according to > draft-ietf-mmusic-4572-update-03. That work is being driven by rtcweb, > so I would think you would want to reflect it here. > > The way tables are formatted in RFC format can make the examples > confusing to readers: the label for table 1 falls exactly between the > bottom of the table it describes and the following table. When viewed on > a screen it is difficult to tell what each table is. I suggest tweaking > the contents of the tables to make this clearer. E.g., > > +----------------------------------+--------------------------------+ > | SDP Contents - Offer | RFC#/Notes | > +----------------------------------+--------------------------------+ > > In Table 2, the o-line has two spaces after the "-". It should only be one. > > * Section 5.2.3: > > Table 5 has ice and fingerprint attributes prior to the first m-line. > > The m-line and associated attributes for the data channel is > inconsistent with draft-ietf-mmusic-sctp-sdp-16. I think it ought to be > (more or less): > > m=application 56966 UDP/DTLS/SCTP webrtc-datachannel > c=IN IP4 24.23.204.141 > a=mid:data > a=sctp-port:5000 > a=setup:actpass > ... > > If you really want to negotiate the usage of channel 1, then it also > needs to include: > > a=dcmap:1 subprotocol="chat";label="channel 1" > > (Note: this presumes that "chat" is a registered subprotocol. It isn't!) > > * Section 5.2.4: > > This seems fine if Bob intends to send audio (e.g. MoH). If not then it > would be better to answer a=inactive. > > * Section 5.2.5: > > Has there been any discussion of pros/cons of having DTMF on a separate > m-line and a separate ssrc? If one or both ends actually think of DTMF > as being part of another audio stream then this might present problems. > This could especially be true for interoperation with telephony devices. > > Is there anything in rtcweb that prevents having these on the same > m-line and ssrc? > > * Section 5.2.7: > > Note that the BAS concept has been removed from Bundle, so you at least > shouldn't refer to it. (You can still do the O/A if you want.) > > In Table 14 (answer), why are ice attributes and fingerprints given > separately (and differently) for the two m-lines? (Even though the ports > and addresses are the same.) This is contrary to current bundle (-29) > procedures. > > In the 2nd (BAS) offer there is a gratuitous change in ordering of > several of the attributes. (Makes it difficult to see what has changed.) > I also don't understand the other differences between the ice and > fingerprints in audio and video, and between this and the first offer. > > * Section 5.2.8: > > This example *assumes* bundle support, and so uses the same addr/port > for bundled m-lines. But this will fail badly if the assumption turns > out to be wrong. When making this assumption you ought to use > bundle-only in the initial offer to ensure nothing bad happens if the > assumption of bundle support by answerer turns out to be wrong. AFAIK > there is no downside to doing this. > > Again this doesn't follow current bundle rules. > > ======= > > That's as far as I have gotten. (Slow going.) I'll try to get you more > later. > > Thanks, > Paul > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Tue May 31 13:25:41 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 140F912D652 for ; Tue, 31 May 2016 13:25:40 -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 IF93B28280tU for ; Tue, 31 May 2016 13:25:37 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA7612D7F4 for ; Tue, 31 May 2016 13:25:36 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id c127so200830217ywb.1 for ; Tue, 31 May 2016 13:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=hUGp8XX8cUCNha1TfS2VYLnGqJ/lfHuAunItmus9OLM=; b=ZaPQ3IEGLHAfKJxWyTuMWHihMFMKE0X/VhBoOXS9aO2E6DDjckE9gwN5nxIRhM3gKb TRnrb1BvJfhhOjXRFcWRqqG0T8ZqWVykxpIPTuY5ya6bzBjfZ3rIgv9OVZfr0oM0W7g6 ZwJgIcp5dnaszgaCCB84z3oaOUwapa5zmMglJOs1URF4STWnohzmsW79VLt8CoRS698M FQDy3z5GiEVj/pCYv/EnQkGBBwSImSZUmL3fnlkHLheEMFRfEdkfvbMDWc5V9Y8uOMS8 S3q2FRqOZTkREpo77Lbw1Js5Qd9NZedrRt0riAL5EvswjK7zr8rybaLjyHhzYkR3WAbT QQQA== 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=hUGp8XX8cUCNha1TfS2VYLnGqJ/lfHuAunItmus9OLM=; b=OK/XqHdhkEaoTnPUW947vD576zp4kJ43w7VHMeWEk4e1SP1mlDCvQPVqgNrSDyVRUw 2uvMUkBOM5xZPO/RYLhgtkGlAi/Vo+anfWEQ8HZbQPH0L+G8/DbZgl1vIpgsqvwb1VHy +WHCDJVDFfhPNXpCN+MS84qcgQ8e++mXYLym51rZ7HMBhEEqLGpdTntxYGBiC0fVdNm3 p/1nedYcfa/fv96oyGwcLKxKav4ztoDw8DCbq5TO2Ii+HRNMWog8dkp+mscQTEooBg7a uCkwxr9HWyaDDDHM9fpmXMLKDK/vKyYe8OReujVKBpxiHeRT6mlL4EHDFQer3GmiR3tb ChmA== X-Gm-Message-State: ALyK8tIf03jI0Mc3ViS2/35wGSLLoEcE7fHuzAqdzfqco6WItNLeGgGykBuK8rrwx+e6XHYd4w7yRxTSqNTRgQ== MIME-Version: 1.0 X-Received: by 10.129.90.135 with SMTP id o129mr23311201ywb.20.1464726335127; Tue, 31 May 2016 13:25:35 -0700 (PDT) Received: by 10.129.54.15 with HTTP; Tue, 31 May 2016 13:25:35 -0700 (PDT) In-Reply-To: <20582c8f-be8e-abc7-32b9-4b21166102e2@alum.mit.edu> References: <20582c8f-be8e-abc7-32b9-4b21166102e2@alum.mit.edu> Date: Tue, 31 May 2016 13:25:35 -0700 Message-ID: From: Suhas Nandakumar To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a114914f0e611c50534292cf0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] partial review of draft-ietf-rtcweb-sdp-01 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, 31 May 2016 20:25:40 -0000 --001a114914f0e611c50534292cf0 Content-Type: text/plain; charset=UTF-8 Thanks Paul for reviewing the draft. We will go through your comments and get back to you. In the meanwhile, I suggest people to HTML rendering of the draft for ease of readability. Here is the link: https://tools.ietf.org/id/draft-ietf-rtcweb-sdp-01.html Thanks Suhas On Tue, May 31, 2016 at 12:09 PM, Paul Kyzivat wrote: > Another general issue: > > I have been *trying* to verify the consistency in use of ports, IP > addresses, fingerprints, ice ufrag info, ice passwords, ssrcs, cnames, etc. > > Of course this is excruciating to do. (For a reviewer like me, and also > for a potential implementer trying to understand the examples.) > > My preliminary take is that there are a number of errors. A lot of them > are probably cut/paste errors. With sufficient analysis it is sometimes > possible to figure out what was intended vs. what is written. But it is > hard with this much stuff. > > It would be easier if, instead of using random sample values, the values > were replaced with semantically relevant and easily recognized values. > (E.g., "ALICE-SSRC-1", "TED-CNAME-2") Unfortunately I don't think this can > be done while also having those values by syntactically valid. > > I think I will end up making such a replacement myself, in a local copy, > simply to assist in analyzing what is there. > > Thanks, > Paul > > > On 5/30/16 6:14 PM, Paul Kyzivat wrote: > >> Ted asked if I would do a review of draft-ietf-rtcweb-sdp-01. I started, >> but it is taking a long time. I'm sending what I have so far to give you >> something to consider/work on. >> >> In order to simplify this review for both me and readers, I will in >> general only mention an issue once, the first time I find it, and be >> silent on future occurrences of the same issue. >> >> * In general in the examples it would be very helpful if you would >> include a blank line prior to each m-line. When reading these it is >> currently hard to find the m-lines, which is something needed when >> trying understand and compare things. >> >> * Section 3: >> >> I realize this is for a webrtc oriented reader, so I am trying to >> understand it from that perspective. Even so, I have trouble with >> classifying a=ice* as "Security Descriptions". Given the existing >> categories I would think they better belong in "Stream Description". >> >> * Section 5.1: >> >> o The term "Session" is used rather loosely in this document to >> refer to either a "Communication Session" or a "RTP Session" or a >> "RTP Stream" depending on the context. >> >> This seems like a bad idea. It may be forgivable to mix communication >> session and RTP session in examples where a single bundle is used for >> all media, or there is only one m-line. But not if multiple m-lines >> aren't bundled, and not with RTP Stream. >> >> OTOH, so far I haven't noticed any place where this is an issue. >> >> * Section 5.2.1: >> >> The SDP line-wrapping convention described in 5.1 isn't being used in >> the example. >> >> Is there a reason for including the IP address in the a=rtcp line, when >> it is the same as the address in the c= line, which is the default? >> >> Is there any expectation that a=ptime:60 only applies to opus? IIUC this >> should be interpreted ad applying to all codecs mentioned in the m-line. >> (There is no order-dependence among attributes within a single media >> section. AFAIK there is no way of specifying a separate ptime for >> individual codecs in an m-line.) >> >> Use of sha-1 in a=fingerprint is about to become incorrect according to >> draft-ietf-mmusic-4572-update-03. That work is being driven by rtcweb, >> so I would think you would want to reflect it here. >> >> The way tables are formatted in RFC format can make the examples >> confusing to readers: the label for table 1 falls exactly between the >> bottom of the table it describes and the following table. When viewed on >> a screen it is difficult to tell what each table is. I suggest tweaking >> the contents of the tables to make this clearer. E.g., >> >> +----------------------------------+--------------------------------+ >> | SDP Contents - Offer | RFC#/Notes | >> +----------------------------------+--------------------------------+ >> >> In Table 2, the o-line has two spaces after the "-". It should only be >> one. >> >> * Section 5.2.3: >> >> Table 5 has ice and fingerprint attributes prior to the first m-line. >> >> The m-line and associated attributes for the data channel is >> inconsistent with draft-ietf-mmusic-sctp-sdp-16. I think it ought to be >> (more or less): >> >> m=application 56966 UDP/DTLS/SCTP webrtc-datachannel >> c=IN IP4 24.23.204.141 >> a=mid:data >> a=sctp-port:5000 >> a=setup:actpass >> ... >> >> If you really want to negotiate the usage of channel 1, then it also >> needs to include: >> >> a=dcmap:1 subprotocol="chat";label="channel 1" >> >> (Note: this presumes that "chat" is a registered subprotocol. It isn't!) >> >> * Section 5.2.4: >> >> This seems fine if Bob intends to send audio (e.g. MoH). If not then it >> would be better to answer a=inactive. >> >> * Section 5.2.5: >> >> Has there been any discussion of pros/cons of having DTMF on a separate >> m-line and a separate ssrc? If one or both ends actually think of DTMF >> as being part of another audio stream then this might present problems. >> This could especially be true for interoperation with telephony devices. >> >> Is there anything in rtcweb that prevents having these on the same >> m-line and ssrc? >> >> * Section 5.2.7: >> >> Note that the BAS concept has been removed from Bundle, so you at least >> shouldn't refer to it. (You can still do the O/A if you want.) >> >> In Table 14 (answer), why are ice attributes and fingerprints given >> separately (and differently) for the two m-lines? (Even though the ports >> and addresses are the same.) This is contrary to current bundle (-29) >> procedures. >> >> In the 2nd (BAS) offer there is a gratuitous change in ordering of >> several of the attributes. (Makes it difficult to see what has changed.) >> I also don't understand the other differences between the ice and >> fingerprints in audio and video, and between this and the first offer. >> >> * Section 5.2.8: >> >> This example *assumes* bundle support, and so uses the same addr/port >> for bundled m-lines. But this will fail badly if the assumption turns >> out to be wrong. When making this assumption you ought to use >> bundle-only in the initial offer to ensure nothing bad happens if the >> assumption of bundle support by answerer turns out to be wrong. AFAIK >> there is no downside to doing this. >> >> Again this doesn't follow current bundle rules. >> >> ======= >> >> That's as far as I have gotten. (Slow going.) I'll try to get you more >> later. >> >> Thanks, >> Paul >> >> _______________________________________________ >> 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 > --001a114914f0e611c50534292cf0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Paul for reviewing the draft.=C2=A0 We will go thro= ugh your comments and get back to you. In the meanwhile, I suggest people t= o HTML rendering of the draft for ease of readability.

H= ere is the link:=C2=A0https://tools.ietf.org/id/draft-ietf-rtcweb-sdp-01.html<= /div>

Thanks
Suhas

On Tue, May 31, 2016 at 12:09 PM,= Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
Another general issue:

I have been *trying* to verify the consistency in use of ports, IP addresse= s, fingerprints, ice ufrag info, ice passwords, ssrcs, cnames, etc.

Of course this is excruciating to do. (For a reviewer like me, and also for= a potential implementer trying to understand the examples.)

My preliminary take is that there are a number of errors. A lot of them are= probably cut/paste errors. With sufficient analysis it is sometimes possib= le to figure out what was intended vs. what is written. But it is hard with= this much stuff.

It would be easier if, instead of using random sample values, the values we= re replaced with semantically relevant and easily recognized values. (E.g.,= "ALICE-SSRC-1", "TED-CNAME-2") Unfortunately I don'= ;t think this can be done while also having those values by syntactically v= alid.

I think I will end up making such a replacement myself, in a local copy, si= mply to assist in analyzing what is there.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

On 5/30/16 6:14 PM, Paul Kyzivat wrote:
Ted asked if I would do a review of draft-ietf-rtcweb-sdp-01. I started, but it is taking a long time. I'm sending what I have so far to give yo= u
something to consider/work on.

In order to simplify this review for both me and readers, I will in
general only mention an issue once, the first time I find it, and be
silent on future occurrences of the same issue.

* In general in the examples it would be very helpful if you would
include a blank line prior to each m-line. When reading these it is
currently hard to find the m-lines, which is something needed when
trying understand and compare things.

* Section 3:

I realize this is for a webrtc oriented reader, so I am trying to
understand it from that perspective. Even so, I have trouble with
classifying a=3Dice* as "Security Descriptions". Given the existi= ng
categories I would think they better belong in "Stream Description&quo= t;.

* Section 5.1:

=C2=A0 =C2=A0o=C2=A0 The term "Session" is used rather loosely in= this document to
=C2=A0 =C2=A0 =C2=A0 refer to either a "Communication Session" or= a "RTP Session" or a
=C2=A0 =C2=A0 =C2=A0 "RTP Stream" depending on the context.

This seems like a bad idea. It may be forgivable to mix communication
session and RTP session in examples where a single bundle is used for
all media, or there is only one m-line. But not if multiple m-lines
aren't bundled, and not with RTP Stream.

OTOH, so far I haven't noticed any place where this is an issue.

* Section 5.2.1:

The SDP line-wrapping convention described in 5.1 isn't being used in the example.

Is there a reason for including the IP address in the a=3Drtcp line, when it is the same as the address in the c=3D line, which is the default?

Is there any expectation that a=3Dptime:60 only applies to opus? IIUC this<= br> should be interpreted ad applying to all codecs mentioned in the m-line. (There is no order-dependence among attributes within a single media
section. AFAIK there is no way of specifying a separate ptime for
individual codecs in an m-line.)

Use of sha-1 in a=3Dfingerprint is about to become incorrect according to draft-ietf-mmusic-4572-update-03. That work is being driven by rtcweb,
so I would think you would want to reflect it here.

The way tables are formatted in RFC format can make the examples
confusing to readers: the label for table 1 falls exactly between the
bottom of the table it describes and the following table. When viewed on a screen it is difficult to tell what each table is. I suggest tweaking
the contents of the tables to make this clearer. E.g.,

=C2=A0 =C2=A0+----------------------------------+--------------------------= ------+
=C2=A0 =C2=A0| SDP Contents - Offer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| RFC#/Notes=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+----------------------------------+--------------------------= ------+

In Table 2, the o-line has two spaces after the "-". It should on= ly be one.

* Section 5.2.3:

Table 5 has ice and fingerprint attributes prior to the first m-line.

The m-line and associated attributes for the data channel is
inconsistent with draft-ietf-mmusic-sctp-sdp-16. I think it ought to be
(more or less):

m=3Dapplication 56966 UDP/DTLS/SCTP webrtc-datachannel
c=3DIN IP4 24.23.204.141
a=3Dmid:data
a=3Dsctp-port:5000
a=3Dsetup:actpass
...

If you really want to negotiate the usage of channel 1, then it also
needs to include:

a=3Ddcmap:1 subprotocol=3D"chat";label=3D"channel 1"
(Note: this presumes that "chat" is a registered subprotocol. It = isn't!)

* Section 5.2.4:

This seems fine if Bob intends to send audio (e.g. MoH). If not then it
would be better to answer a=3Dinactive.

* Section 5.2.5:

Has there been any discussion of pros/cons of having DTMF on a separate
m-line and a separate ssrc? If one or both ends actually think of DTMF
as being part of another audio stream then this might present problems.
This could especially be true for interoperation with telephony devices.
Is there anything in rtcweb that prevents having these on the same
m-line and ssrc?

* Section 5.2.7:

Note that the BAS concept has been removed from Bundle, so you at least
shouldn't refer to it. (You can still do the O/A if you want.)

In Table 14 (answer), why are ice attributes and fingerprints given
separately (and differently) for the two m-lines? (Even though the ports and addresses are the same.) This is contrary to current bundle (-29)
procedures.

In the 2nd (BAS) offer there is a gratuitous change in ordering of
several of the attributes. (Makes it difficult to see what has changed.) I also don't understand the other differences between the ice and
fingerprints in audio and video, and between this and the first offer.

* Section 5.2.8:

This example *assumes* bundle support, and so uses the same addr/port
for bundled m-lines. But this will fail badly if the assumption turns
out to be wrong. When making this assumption you ought to use
bundle-only in the initial offer to ensure nothing bad happens if the
assumption of bundle support by answerer turns out to be wrong. AFAIK
there is no downside to doing this.

Again this doesn't follow current bundle rules.

=3D=3D=3D=3D=3D=3D=3D

That's as far as I have gotten. (Slow going.) I'll try to get you m= ore
later.

=C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 Paul

_______________________________________________
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

--001a114914f0e611c50534292cf0--