From nobody Tue Jul 1 01:02:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBC61B27D7 for ; Tue, 1 Jul 2014 01:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D_qiTuCuMC5W for ; Tue, 1 Jul 2014 01:02:38 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D6F11A0199 for ; Tue, 1 Jul 2014 01:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=940; q=dns/txt; s=iport; t=1404201758; x=1405411358; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=35qXaFdX9jCZmiYsLubldUnCv3ryHjFVYHb80CFBLsg=; b=QnkJ0niET7hueyk+8wPkDwQSDw229HDYwkeOLqSK5laFONVYRvovv2qG Vc2gWX7/OhA2Cu4BH8QzwB+H+4jw1hR1dzvvBnaU2gs+Y5SZAkIhU2lCW UrB9P7TzHcFo9q/1FFVXnuIX3rXljSA7pxJTe3yg9yqce8CF6PcQT1WAe 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAMhqslOtJV2Y/2dsb2JhbABagw1SWr4nhnFTAYEJFnWEAwEBAQQBAQE3NBcEAgEIEQMBAgEeECcLHQgCBAESiEINx14TBI8OBoQ9BZphk3+DQoIw X-IronPort-AV: E=Sophos;i="5.01,580,1400025600"; d="scan'208";a="336992475" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 01 Jul 2014 08:02:20 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6182KNO006965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Jul 2014 08:02:20 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.10]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Tue, 1 Jul 2014 03:02:20 -0500 From: "Ram Mohan R (rmohanr)" To: Michael Procter , Harald Alvestrand , "" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-04.txt Thread-Index: AQHPlQLIVmwIrzxAmkuknV+S3pv8Ig== Date: Tue, 1 Jul 2014 08:02:19 +0000 Message-ID: References: <20140618031726.3502.90813.idtracker@ietfa.amsl.com> <53AFCDA3.5000508@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.53.77] Content-Type: text/plain; charset="us-ascii" Content-ID: <26E2A8BF403F284B891B7E93AD65E50E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DY6wY4SKHkBRkw2YApcaoQdxgN4 Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 01 Jul 2014 08:02:40 -0000 Sure. Will fix this in the next revision. Ram -----Original Message----- From: Michael Procter Date: Sunday, 29 June 2014 6:06 pm To: Harald Alvestrand Cc: "" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-04.txt >On 29 June 2014 09:26, Harald Alvestrand wrote: >> I think it will be fine if you just put in a definition for the term. >> BTW, I'd like it to be an "inverse" 5-tuple, not an "inverted" one. > >Adding a definition would be fine for me. And "inverse" is better, >too. I had spent some time peering at stun xor-mapped-addresses >before reading this draft, so I might have been overly sensitive to >the word 'inverted'! > >Michael > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Jul 1 02:13:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFC11A0167 for ; Tue, 1 Jul 2014 02:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 Nt6_Bt35sHYt for ; Tue, 1 Jul 2014 02:13:17 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840CB1A00E1 for ; Tue, 1 Jul 2014 02:13:17 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id j15so7524362qaq.12 for ; Tue, 01 Jul 2014 02:13:16 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=8a1nIHjy6M5tIBZWf5+mtzTNKfmebsMg6wWJF3TZhu4=; b=d6+myxzA+j8MGEKcK9Fk/NqUJEqXbet72NJVCmTVyPtrdpLbdosBvvxkZMIDGjtaTW 6EK7Jjigp/J+IZIk8WEVCIwGCn/VedeR3Xo6YD06EC3jQsQXqyUZL2h5pJ1MlQ0pjqhl k+5Xp8DSUwutGKpD+ilo0OJzu/h/egJVmwJgUuVItMoK8OpRuwHWCmLucjJ+qRkhjFjq PmYK20JccYRuzOlG1tAOVo71hU42OiPK5IZCwv4/uJWlpLYwIaUr6hS3MV3ClGoeiNx0 oGWtQOi3NcTLEBGbQ7NwbeJGD7j5yY2zpU5URl0ayqRSVzf+IsBWUYNSdhdBSlRqUFfJ /QVw== X-Gm-Message-State: ALoCoQm2cXigcT4sMnzPQXeQ4rQ3Z0VYJuF7NiIjHrAyjVkq/sDHUNyzVCIGTp6XSvGEBqnXc/+V X-Received: by 10.229.65.200 with SMTP id k8mr67729917qci.4.1404205996679; Tue, 01 Jul 2014 02:13:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.234.131 with HTTP; Tue, 1 Jul 2014 02:12:56 -0700 (PDT) In-Reply-To: <20140618031726.3502.90813.idtracker@ietfa.amsl.com> References: <20140618031726.3502.90813.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 1 Jul 2014 11:12:56 +0200 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ZCDh2RpIlgLZ23VeCyU7VNppnFA Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 01 Jul 2014 09:13:19 -0000 Hi, May the draft include some text clarifying that ICE-Lite endpoints do not need to send Consent Freshness STUN requests to the remote peer? Best regards. 2014-06-18 5:17 GMT+02:00 : > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Real-Time Communication in WEB-browsers= Working Group of the IETF. > > Title : STUN Usage for Consent Freshness > Authors : Muthu Arul Mozhi Perumal > Dan Wing > Ram Mohan Ravindranath > Tirumaleswar Reddy > Martin Thomson > Filename : draft-ietf-rtcweb-stun-consent-freshness-04.txt > Pages : 9 > Date : 2014-06-17 > > Abstract: > To prevent sending excessive traffic to an endpoint, periodic consent > needs to be obtained from that remote endpoint. > > This document describes a consent mechanism using a new STUN usage. > This same mechanism can also determine connection loss ("liveness") > with a remote peer. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness= / > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent-freshne= ss-04 > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 I=C3=B1aki Baz Castillo From nobody Tue Jul 1 02:18:54 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56D11B27CB for ; Tue, 1 Jul 2014 02:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIsbjO2ogWXF for ; Tue, 1 Jul 2014 02:18:51 -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 2E4F81A00E1 for ; Tue, 1 Jul 2014 02:18:51 -0700 (PDT) X-AuditID: c1b4fb30-f79da6d000006b80-50-53b27cf95b50 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 8F.75.27520.9FC72B35; Tue, 1 Jul 2014 11:18:49 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0174.001; Tue, 1 Jul 2014 11:18:48 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-04.txt Thread-Index: AQHPiqPamkRxoO5CEUaMFUWdXHPAmZuK4nsAgAAi40g= Date: Tue, 1 Jul 2014 09:18:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3ACBF8@ESESSMB209.ericsson.se> References: <20140618031726.3502.90813.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvje7Pmk3BBp2blSym77OxWPuvnd2B yeNcw3t2jyVLfjIFMEVx2aSk5mSWpRbp2yVwZaw9vImlYI1Ixd6rz1kaGI/ydzFyckgImEg8 mzuRFcIWk7hwbz1bFyMXh5DAUUaJI9OWsoAkhAQWMkosmBjWxcjBwSZgIdH9TxskLCKQILH5 wRSwEmGBYIkjF5axQsRDJL5OWMMOYVtJLD94iwnEZhFQkTh0+Q9YnFfAV2LRsu9MELtaGSXu /d/ABDKfUyBQ4srDSJAaRqB7vp9aA9bLLCAucevJfCaIOwUkluw5zwxhi0q8fPwP6n5FiavT l0PV60ncmDqFDcLWlli28DUzxF5BiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRWjaHFqcVJu upGRXmpRZnJxcX6eXl5qySZGYIwc3PLbYAfjy+eOhxgFOBiVeHgXLN0YLMSaWFZcmXuIUZqD RUmcd+G5ecFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGGesvPNko9CCY/82vj/JsHJzbsGx O9a58zOOfMmcYnVFfUX84bsXHAUKgrmPP7VZ/CdiX2Tj1XdPdq+aKfLdL1Do/r3F806FJn9e LMW3QPGpwXaz9Vu7e4VMXyVblCj3bnTpqWIy3Jh/dY95fOjXCZeV00PSTM9w/1Jg/lRm4hS+ 9ujPx/YhXs1KLMUZiYZazEXFiQCoV/sEcgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kltoqMxHDdhwx-pu-Uj_DTfHd9A Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 01 Jul 2014 09:18:53 -0000 +1 I get this question every now and then, so I think it would be good to clar= ify in the draft. Regards, Christer ________________________________________ From: rtcweb [rtcweb-bounces@ietf.org] on behalf of I=F1aki Baz Castillo [i= bc@aliax.net] Sent: Tuesday, 01 July 2014 12:12 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-= 04.txt Hi, May the draft include some text clarifying that ICE-Lite endpoints do not need to send Consent Freshness STUN requests to the remote peer? Best regards. 2014-06-18 5:17 GMT+02:00 : > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Real-Time Communication in WEB-browsers= Working Group of the IETF. > > Title : STUN Usage for Consent Freshness > Authors : Muthu Arul Mozhi Perumal > Dan Wing > Ram Mohan Ravindranath > Tirumaleswar Reddy > Martin Thomson > Filename : draft-ietf-rtcweb-stun-consent-freshness-04.txt > Pages : 9 > Date : 2014-06-17 > > Abstract: > To prevent sending excessive traffic to an endpoint, periodic consent > needs to be obtained from that remote endpoint. > > This document describes a consent mechanism using a new STUN usage. > This same mechanism can also determine connection loss ("liveness") > with a remote peer. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness= / > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent-freshne= ss-04 > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- I=F1aki Baz Castillo _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb= From nobody Tue Jul 1 09:34:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB681B285C; Tue, 1 Jul 2014 09:34:08 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCd-MgjieUx4; Tue, 1 Jul 2014 09:34:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 833F01B2845; Tue, 1 Jul 2014 09:34:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140701163405.3562.14545.idtracker@ietfa.amsl.com> Date: Tue, 01 Jul 2014 09:34:05 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1pilJpV-v5ZPFs8XTPydxMMi2G8 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-video-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-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, 01 Jul 2014 16:34:08 -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 Working Group of the IETF. Title : WebRTC Video Processing and Codec Requirements Author : Adam Roach Filename : draft-ietf-rtcweb-video-00.txt Pages : 7 Date : 2014-07-01 Abstract: This specification provides the requirements and consideration for WebRTC applications to send and receive video across a network. It specifies the video processing that is required, codecs and their parameters, and types of RTP packetization that need to be supported. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-video-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 1 12:47:54 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45D71B28C7 for ; Tue, 1 Jul 2014 12:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iViGconS41zU for ; Tue, 1 Jul 2014 12:47:50 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF7E31B28C6 for ; Tue, 1 Jul 2014 12:47:50 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id tr6so8655518ieb.15 for ; Tue, 01 Jul 2014 12:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Dzqr3kz3+NEX8ErgAdvsL/+RFlyYfKwZvVsuA3Z29zo=; b=TEn4UMkrzzKJQwWlFaAbgY7jUL3pS5UPhWvzGelJ//G4qV6yBnr0r/oAhRyDXyxygU GKbrXXp4KeBc7xSEgcevyCrv/162I7gj74YxLqMtUiQzMtegmyt5ZV/R2FFGBFr4Suk8 kMTTa7sVU6Oj2IKGraAtxtUEOCLTy3Qe2cqpC9OBncDgj0fnAGrgBt1Nzqc0dWZ48fFL pzPuDQeTYuscFfgSEMDfaf6qD90awIRtTq+zewOn7RnvtphP26uwyBRY0wHMIK7/oXEl eQFlBgP6V23JdMmJkOd4sPNxwFC7an3c5YZfyyw9MBuLpsL/AaS0skWGodjzcV4w9Ap9 5hHA== MIME-Version: 1.0 X-Received: by 10.43.160.68 with SMTP id mb4mr16664839icc.4.1404244070149; Tue, 01 Jul 2014 12:47:50 -0700 (PDT) Received: by 10.42.99.6 with HTTP; Tue, 1 Jul 2014 12:47:50 -0700 (PDT) Date: Tue, 1 Jul 2014 12:47:50 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" , Sean Turner , Cullen Jennings Content-Type: multipart/alternative; boundary=001a11c303e8fab3f304fd270c53 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/CK5Oem4bzeI2Gse0DJ_W75wUHpU Subject: [rtcweb] Finalized agenda X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 01 Jul 2014 19:47:52 -0000 --001a11c303e8fab3f304fd270c53 Content-Type: text/plain; charset=UTF-8 Although there may still be some late changes, the IETF 90 is now considered final: https://datatracker.ietf.org/meeting/90/agenda.html RTCWEB will meet in Ballroom C Wednesday Morning and Thursday afternoon. If you have agenda requests for the chairs (especially for documents outside the current workplan), please let us know. Ted, Cullen, Sean --001a11c303e8fab3f304fd270c53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Although there may still be some late changes, the = IETF 90 is now considered final:

https://datatracker.ietf.org= /meeting/90/agenda.html

RTCWEB will meet in Ballroom C Wednesday Morning and Thurs= day afternoon.

If you have agenda requests for the chairs (especially for documents outsid= e the current workplan), please let us know.

Ted, Culle= n, Sean
--001a11c303e8fab3f304fd270c53-- From nobody Wed Jul 2 09:20:59 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519B81B280E for ; Wed, 2 Jul 2014 09:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.601 X-Spam-Level: X-Spam-Status: No, score=-6.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZgBWhLPLmQO for ; Wed, 2 Jul 2014 09:20:47 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B4C41B2816 for ; Wed, 2 Jul 2014 09:20:43 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s62GK903023502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Jul 2014 16:20:09 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s62GK7wv024855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jul 2014 18:20:07 +0200 Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 2 Jul 2014 18:20:06 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.136]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0181.006; Wed, 2 Jul 2014 18:20:06 +0200 From: "Rauschenbach, Uwe (NSN - DE/Munich)" To: ext Christer Holmberg , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-04.txt Thread-Index: AQHPiqPbMQagHyXG/UaGFX7NOF+g25uK4nsAgAABooCAAiGRMA== Date: Wed, 2 Jul 2014 16:20:06 +0000 Message-ID: <56C2F665D49E0341B9DF5938005ACDF8338BC2@DEMUMBX005.nsn-intra.net> References: <20140618031726.3502.90813.idtracker@ietfa.amsl.com>, <7594FB04B1934943A5C02806D1A2204B1D3ACBF8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D3ACBF8@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.115] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3378 X-purgate-ID: 151667::1404318009-00007A71-2B7CA987/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/g3mP_A9EFQQO4yUCyGN79nlT4Hc Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 16:20:52 -0000 Same here.=20 It makes sense to clarify that they must respond to consent requests, but d= on't need to send them. Kind regards, Uwe=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Christer > Holmberg > Sent: Tuesday, July 01, 2014 11:19 AM > To: I=F1aki Baz Castillo; rtcweb@ietf.org > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent- > freshness-04.txt >=20 > +1 >=20 > I get this question every now and then, so I think it would be good to > clarify in the draft. >=20 > Regards, >=20 > Christer >=20 > ________________________________________ > From: rtcweb [rtcweb-bounces@ietf.org] on behalf of I=F1aki Baz Castillo > [ibc@aliax.net] > Sent: Tuesday, 01 July 2014 12:12 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent- > freshness-04.txt >=20 > Hi, >=20 > May the draft include some text clarifying that ICE-Lite endpoints do > not need to send Consent Freshness STUN requests to the remote peer? >=20 > Best regards. >=20 >=20 > 2014-06-18 5:17 GMT+02:00 : > > > > 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 Working Group of the IETF. > > > > Title : STUN Usage for Consent Freshness > > Authors : Muthu Arul Mozhi Perumal > > Dan Wing > > Ram Mohan Ravindranath > > Tirumaleswar Reddy > > Martin Thomson > > Filename : draft-ietf-rtcweb-stun-consent-freshness- > 04.txt > > Pages : 9 > > Date : 2014-06-17 > > > > Abstract: > > To prevent sending excessive traffic to an endpoint, periodic > consent > > needs to be obtained from that remote endpoint. > > > > This document describes a consent mechanism using a new STUN usage. > > This same mechanism can also determine connection loss ("liveness") > > with a remote peer. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent- > freshness/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-04 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent- > freshness-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/ > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 >=20 > -- > I=F1aki Baz Castillo > >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Jul 2 11:32:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960151B29ED for ; Wed, 2 Jul 2014 11:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SDacvA9kNCY for ; Wed, 2 Jul 2014 11:32:35 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1401D1A00EA for ; Wed, 2 Jul 2014 11:32:35 -0700 (PDT) Received: from [172.20.10.2] (unknown [209.121.225.227]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5160722E256; Wed, 2 Jul 2014 14:32:31 -0400 (EDT) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Jul 2014 11:33:28 -0700 Message-Id: <7F2087CA-E3B9-41B1-8022-62953BB7A6C9@iii.ca> To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/UhkGHTkaj5vq7q2SdrODxTsPYY0 Subject: [rtcweb] Draft agenda for IETF 90 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 18:32:36 -0000 Here is a very rough draft of agenda for IETF 90 meeting. It will change = a bunch.=20 ------------------------------------- Very draft agenda V1 Agenda Bashing ( 5 min ) WG Status Updates ( 5 min ) JSEP ( 90 min )=20 RTP Usage (30 min) Transport (20 min) Overview (20 min)=20 Stun Consent Freshness (20 min) Security (if no WGLC prior) (20 min) Audio (15 min) - people wanted a consensus call on other codecs (AMR, etc) Video (15 min) - review the issues other than the MTI codec part=20 From nobody Wed Jul 2 16:23:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2987F1A0ACC for ; Wed, 2 Jul 2014 16:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j_E020oQnky2 for ; Wed, 2 Jul 2014 16:23:18 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 629161A0AA2 for ; Wed, 2 Jul 2014 16:23:18 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hi2so9704853wib.0 for ; Wed, 02 Jul 2014 16:23:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=SOixgqPKEOcvQhZGWlj7jsdv7HuN3JrmTagTiDY6/rg=; b=jOooxFwUpjlSdv0WDbfvrePuXq9cFlHcwI1HaletoaIQC4JFH9Q6BQWJjJp6yZOT8X /0Hj5L1Gc76ilBZ47UnsjFjijsGFzgHr9O3i+25uqsRRXDejfT64benTwekMmFVCWMHg pAn+xrn/yhnraj3T+WejXcDuJgD39BlpRvbKpXWfRB7mJE7MUsy/n37Ed8ubcZnTPIqe jwdWNp4muoJK0mdTXSeazXGvkydML4gSaRhnb34ZbBpYOw+q/MxDjp/rh+tNn2MYyV6j j0N0+qeHNBMQOtefcJOf5itJ5uLWV+/R5f5p05BlK4m86+k/kmz6kRh18UM2wGbpLGmU 7APA== X-Gm-Message-State: ALoCoQnMeun5bRFthts54JPyDPPd1ymPjrmBlX0xeX4qahUgZ7Mnezr9C6HEUScEO9k210J3LXTh X-Received: by 10.180.76.20 with SMTP id g20mr6285948wiw.7.1404343397007; Wed, 02 Jul 2014 16:23:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.57.202 with HTTP; Wed, 2 Jul 2014 16:22:36 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:d67:f212:2165:1fd2] From: Eric Rescorla Date: Wed, 2 Jul 2014 16:22:36 -0700 Message-ID: To: mmusic WG , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=f46d04343946525dfe04fd3e2ddb Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ouS-gZ1aqYp2-EtmpLavuFRdFn4 Subject: [rtcweb] Dummy ports X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 23:23:21 -0000 --f46d04343946525dfe04fd3e2ddb Content-Type: text/plain; charset=UTF-8 Folks, https://github.com/rtcweb-wg/jsep/issues/41 We ran into a place where bundle and trickle conflict. Trickle requires that you use port 9 for the c-line if you are doing full trickle: http://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-01#section-5.1 However, JSEP explicitly requires that we use distinct ports for each m= line: http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-06#section-5.2.1 Obviously 9 is equal to itself, so this isn't going to work. The JSEP editors got together and came to the conclusion that we probably needed to use sequential numbers < 1024. Does anyone object to this? If not, perhaps Emil can edit this into Trickle. Also, JSEP uses the term "null" for these ports. We propose that instead we use the term "dummy". -Ekr --f46d04343946525dfe04fd3e2ddb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Folks,




Trickle requires that you use port 9 for the c-line if = you are doing full
trickle:


However, JSEP explicitly requires = that we use distinct ports for
each m=3D line:

Obviously 9 is equal to itself, so this isn't= going to work.


The JSEP editors go= t together and came to the conclusion that
we probably needed to = use sequential numbers < 1024. Does
anyone object to this? If not, perhaps Emil can edit this into Trickle= .


Also, JSEP uses the term "nu= ll" for these ports. We propose that
instead we use the term= "dummy".

-Ekr



=




--f46d04343946525dfe04fd3e2ddb-- From nobody Wed Jul 2 16:36:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E401A03FD; Wed, 2 Jul 2014 16:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rR1NaB1ko3xO; Wed, 2 Jul 2014 16:36:52 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F801A0387; Wed, 2 Jul 2014 16:36:52 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id n12so11641416wgh.19 for ; Wed, 02 Jul 2014 16:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b4+tOolvxcpd0ktMD30/K729vkqmjdPEA4F1+Fpsg6w=; b=JDlohnSSetoe3JOG7z1ompZcU6sDYzjEQbul+o0XDn6g+fiZHSCjwmqqwMPXachmMB /p961G+3BEqtWJR6CUssszYr/+4AkgNTAA7hEX6U+lX+iq2IXJOc9rT0/CCGMFtzEoT+ Ih0LWXLryh90ysGWugjNemMhcH5pGl2PKqc73RIOD7neRVsZRU59CDlSUcMLItofP+JS JqCniqhnbn6OszEqaO6RsN9g63/Tvl/aP78ZCP3xNv/rDXF/IX41BlCE7IcEmDm6llNe y1apwEYe/kGK6Ax2GOxEoo230LtSIKQ2lmWDC4h8RCMsS0hfkwWlpbsgNido5JdjKbpg rHbQ== MIME-Version: 1.0 X-Received: by 10.180.101.39 with SMTP id fd7mr7072565wib.65.1404344210753; Wed, 02 Jul 2014 16:36:50 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Wed, 2 Jul 2014 16:36:50 -0700 (PDT) In-Reply-To: References: Date: Wed, 2 Jul 2014 16:36:50 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IKu4mcxIZEtG-p3cuBGFEfOEfww Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [rtcweb] [MMUSIC] Dummy ports X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 23:36:53 -0000 On 2 July 2014 16:22, Eric Rescorla wrote: > > However, JSEP explicitly requires that we use distinct ports for > each m= line: > http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-06#section-5.2.1 > > Obviously 9 is equal to itself, so this isn't going to work. I'm not sure that this is actually a problem, unless I've missed something. The reason for having different ports is to make it clear that the m= section will have distinct transport endpoints and can be unbungled if the answerer wants that. But the presence (or absence) of a=bungle-only is sufficient to distinguish those m= sections. > Also, JSEP uses the term "null" for these ports. We propose that > instead we use the term "dummy". WFM. From nobody Thu Jul 3 00:39:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73FD1A037A for ; Thu, 3 Jul 2014 00:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZobZDAvFIT1s for ; Thu, 3 Jul 2014 00:39:51 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD9A21A01BE for ; Thu, 3 Jul 2014 00:39:50 -0700 (PDT) Received: from [47.73.102.68] (unknown [47.73.102.68]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id DA12F1C0E9788; Thu, 3 Jul 2014 09:39:47 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: Date: Thu, 3 Jul 2014 09:39:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kIusI_-PxaOYKXcvQdAcXmxpmuY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS version X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Jul 2014 07:39:52 -0000 On 01 Jul 2014, at 02:20, Martin Thomson = wrote: > On 30 June 2014 16:55, Michael Tuexen = wrote: >>> "Wouldn't that imply that it makes sense to use DTLS 1.2 in all = documents?" >>>=20 >>> [BA] Not necessarily. As I understand it, existing implementations = only support 1.0 - and if we were to mandate only 1.2 ciphersuites, then = this would create an interoperability problem. >> There are also several clarifications and corrections to handshake = issues. This >> really helps in interoperability.... >=20 > Bernard is right. But there are several advantages to an update to > referencing (D)TLS 1.2. For one, we get better ciphersuites (AES-GCM > and all the AEAD modes). >=20 > That said, there are enough implementations out there already that > *requiring* 1.2 might be too aggressive. I think that I'd prefer that > (so that we can make modern ciphersuite recommendations to fit), but > if someone has a strong need for 1.0, I don't have a problem > suggesting that 1.0 be accepted. >=20 > p.s., DTLS 1.2 is coming in Firefox. As it turns out, NSS supported > it, but it hadn't been turned on. So the consensus seems to be to require 1.0 for now. If there will be a change in the future, a separate RFC will change that = to 1.2. Right? Best regards Michael >=20 From nobody Thu Jul 3 00:48:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9499E1A01BE for ; Thu, 3 Jul 2014 00:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVb5dnR6CdWp for ; Thu, 3 Jul 2014 00:48:14 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F1CE1A016E for ; Thu, 3 Jul 2014 00:48:14 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id g10so13395701pdj.28 for ; Thu, 03 Jul 2014 00:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q8NLqEHm5iR3DJ3sAEhs96ni8zwRKeeI8juPRUHtjr0=; b=GqU6p19u7uq7tQzejwTZAu8mRGR2GE5OkySNpV51Tf+22zhfm44m3X4r22SleKEfAy Zjro81TOtCnkx/Citn+3Y4S5kQYYT7mOPdWFOnp7LQuMCL5LmRfeoh7svKQsZ8UZs1k/ vw89K7LKa59n/F67BbmCLj2jCFqjVZnBgH957GFCRi/C31FfGNAXv6ciAN1goLoMWTqY 9aJBQQQrdg1W7Q7prq+QFZnKqZpFyPyOYcuRStnaUtWQF014JpgNnW2S17sQuiaei3LR NXxUFi4lSfigOf4k9grnoF6JXzm5MFp+vt0u54kboSL9a5RN2NsyFeqgbYOHXEa4TqOJ YmbQ== X-Received: by 10.68.143.231 with SMTP id sh7mr2945111pbb.7.1404373693919; Thu, 03 Jul 2014 00:48:13 -0700 (PDT) Received: from [10.42.1.154] ([63.249.94.5]) by mx.google.com with ESMTPSA id nw13sm139672342pab.37.2014.07.03.00.48.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Jul 2014 00:48:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Jim Spring In-Reply-To: Date: Thu, 3 Jul 2014 00:48:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6355614E-44DA-4729-97C2-E903548EBA8B@gmail.com> References: To: Michael Tuexen X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mtaL93gWU-_CcR249sHDEmZcbwM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS version X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Jul 2014 07:48:15 -0000 Personally, given the lack of widespread adoption of DTLS 1.2 at this = point, I would prefer a requirement of 1.0 for this round of things. That said, I believe there will be a pull request in the next week = addressing this section of security-arch does expire in mig august, so = we should make progress soon. Hopefully any of the "TBDs" in the = document can be fleshed out before Toronto. -jim On Jul 3, 2014, at 12:39 AM, Michael Tuexen = wrote: > On 01 Jul 2014, at 02:20, Martin Thomson = wrote: >=20 >> On 30 June 2014 16:55, Michael Tuexen = wrote: >>>> "Wouldn't that imply that it makes sense to use DTLS 1.2 in all = documents?" >>>>=20 >>>> [BA] Not necessarily. As I understand it, existing implementations = only support 1.0 - and if we were to mandate only 1.2 ciphersuites, then = this would create an interoperability problem. >>> There are also several clarifications and corrections to handshake = issues. This >>> really helps in interoperability.... >>=20 >> Bernard is right. But there are several advantages to an update to >> referencing (D)TLS 1.2. For one, we get better ciphersuites (AES-GCM >> and all the AEAD modes). >>=20 >> That said, there are enough implementations out there already that >> *requiring* 1.2 might be too aggressive. I think that I'd prefer = that >> (so that we can make modern ciphersuite recommendations to fit), but >> if someone has a strong need for 1.0, I don't have a problem >> suggesting that 1.0 be accepted. >>=20 >> p.s., DTLS 1.2 is coming in Firefox. As it turns out, NSS supported >> it, but it hadn't been turned on. > So the consensus seems to be to require 1.0 for now. > If there will be a change in the future, a separate RFC will change = that to 1.2. Right? >=20 > Best regards > Michael >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Jul 3 01:39:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A931A0B12 for ; Thu, 3 Jul 2014 01:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e06gSu9iw-FJ for ; Thu, 3 Jul 2014 01:39:45 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48DD01A03AC for ; Thu, 3 Jul 2014 01:39:44 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s638deme004167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Jul 2014 03:39:43 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s638deQj001964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Jul 2014 10:39:40 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.71]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 3 Jul 2014 10:39:40 +0200 From: "DRAGE, Keith (Keith)" To: Jim Spring , Michael Tuexen Thread-Topic: [rtcweb] DTLS version Thread-Index: AQHPlL1NQia+CLBEBkOxqOTgqEBL35uKMLWAgAABu4CAAAc1AIADn0aAgAACWACAAC9JQA== Date: Thu, 3 Jul 2014 08:39:39 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B1FC18D@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <6355614E-44DA-4729-97C2-E903548EBA8B@gmail.com> In-Reply-To: <6355614E-44DA-4729-97C2-E903548EBA8B@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_tizynihf1UvS1177EOEp8JQmgk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS version X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Jul 2014 08:39:48 -0000 Can someone elaborate what this massive apparent step change is from 1.0 to= 1.2? Will those implementations that choose to stay with 1.0 still interwork wit= h 1.2? If everything interworks reasonably OK, I would prefer to specify 1.2, and = then maybe a note acknowledging that 1.0 implementations might be out there= . Otherwise the security people are wasting their time producing 1.2. Keith > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Jim Spring > Sent: 03 July 2014 08:48 > To: Michael Tuexen > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] DTLS version >=20 > Personally, given the lack of widespread adoption of DTLS 1.2=20 > at this point, I would prefer a requirement of 1.0 for this=20 > round of things. >=20 > That said, I believe there will be a pull request in the next=20 > week addressing this section of security-arch does expire in=20 > mig august, so we should make progress soon. Hopefully any=20 > of the "TBDs" in the document can be fleshed out before Toronto. >=20 > -jim >=20 > On Jul 3, 2014, at 12:39 AM, Michael Tuexen=20 > wrote: >=20 > > On 01 Jul 2014, at 02:20, Martin Thomson=20 > wrote: > >=20 > >> On 30 June 2014 16:55, Michael Tuexen=20 > wrote: > >>>> "Wouldn't that imply that it makes sense to use DTLS 1.2=20 > in all documents?" > >>>>=20 > >>>> [BA] Not necessarily. As I understand it, existing=20 > implementations only support 1.0 - and if we were to mandate=20 > only 1.2 ciphersuites, then this would create an=20 > interoperability problem. > >>> There are also several clarifications and corrections to=20 > handshake=20 > >>> issues. This really helps in interoperability.... > >>=20 > >> Bernard is right. But there are several advantages to an=20 > update to=20 > >> referencing (D)TLS 1.2. For one, we get better=20 > ciphersuites (AES-GCM=20 > >> and all the AEAD modes). > >>=20 > >> That said, there are enough implementations out there already that > >> *requiring* 1.2 might be too aggressive. I think that I'd prefer=20 > >> that (so that we can make modern ciphersuite=20 > recommendations to fit),=20 > >> but if someone has a strong need for 1.0, I don't have a problem=20 > >> suggesting that 1.0 be accepted. > >>=20 > >> p.s., DTLS 1.2 is coming in Firefox. As it turns out, NSS=20 > supported=20 > >> it, but it hadn't been turned on. > > So the consensus seems to be to require 1.0 for now. > > If there will be a change in the future, a separate RFC=20 > will change that to 1.2. Right? > >=20 > > Best regards > > Michael > >>=20 > >=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 Thu Jul 3 02:26:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AB41B2826 for ; Thu, 3 Jul 2014 02:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7d3UpHezsJWM for ; Thu, 3 Jul 2014 02:26:50 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727D81B280D for ; Thu, 3 Jul 2014 02:26:50 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id r20so1907532wiv.10 for ; Thu, 03 Jul 2014 02:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=R2GNa/y3Urd2oV9PU30gt++BHJUX+whqQQgjbbnfhJ8=; b=XOZsclmTQOpUzXYGZJnSY75VxCEetNpjYiG4YFRQfQfTX9Fzl3F7WQExVgOp8xWCD6 BUDuIluXPXoRqlj+6cAqHIWlJrbTJ4F09chpm1x4QZ/AqU5LcpGGJwMxCErDv+64Fgmf dtejMudiIabiiAt9gNPjaKavizHVAZQhys/13lpHfQdj8OkMPCP+9JrM9vzLMeiImmoB OLmsrhtL3RwawTe1XWXJPbkfnqHUeu7w41detonHUpjlDvKXVdqfKfsgMcntcxuFCtKh ryEW7fsb6axnzfslD7H+TgofOCeQj+VQYf3ZNt72jFdVi1Cs0XX70Bo3wnlfo2k0GavY jWsw== X-Received: by 10.194.133.1 with SMTP id oy1mr3566397wjb.87.1404379609007; Thu, 03 Jul 2014 02:26:49 -0700 (PDT) Received: from [192.168.1.47] (207.Red-79-146-136.dynamicIP.rima-tde.net. [79.146.136.207]) by mx.google.com with ESMTPSA id ec8sm46114376wic.10.2014.07.03.02.26.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Jul 2014 02:26:48 -0700 (PDT) Message-ID: <53B521D8.3030404@gmail.com> Date: Thu, 03 Jul 2014 11:26:48 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7X6Fdizkzj-Zah4l1JK5vw70eUc Subject: Re: [rtcweb] Dummy ports X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Jul 2014 09:26:52 -0000 On 03/07/2014 1:22, Eric Rescorla wrote: > Folks, > > https://github.com/rtcweb-wg/jsep/issues/41 > > > We ran into a place where bundle and trickle conflict. > > Trickle requires that you use port 9 for the c-line if you are doing full > trickle: > http://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-01#section-5.1 > > > However, JSEP explicitly requires that we use distinct ports for > each m= line: > http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-06#section-5.2.1 > > Obviously 9 is equal to itself, so this isn't going to work. > > > The JSEP editors got together and came to the conclusion that > we probably needed to use sequential numbers < 1024. Does > anyone object to this? If not, perhaps Emil can edit this into Trickle. > Using well know valid port numbers as dummy values does not seem a wise idea for me. I don't have enough knowledge of ice trickle to know how this should be solved, but it seems that you are trying to hack SDP RFCs instead of fixing the ice trickle draft. Best regards Sergio From nobody Thu Jul 3 10:58:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A241A03B1 for ; Thu, 3 Jul 2014 10:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KsnnAj7u7VY for ; Thu, 3 Jul 2014 10:58:39 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25F231B2966 for ; Thu, 3 Jul 2014 10:58:37 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id a1so619074wgh.0 for ; Thu, 03 Jul 2014 10:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0X9nbckTrPP9etgyaQ9q2DoBgM99nHWAUvj2hLNSvlU=; b=VqpjUuzKulYIKFZkuQiNInTvYCQfpU/qrTD3fBW0pqpZaJsbccZdgqCZ9Cl2Hqw6zb EqSA3f2+jibwUUkMRnGPHKDGu6EdN7NkTqeguxyGYtcZCfchsGmd2A9afZRMV3xK9Uib UCaxhhH8MErYWT9utd1vEAsBjJcLwa7RxS87+u1ynvuRspNfIG4RdPdYFYxdiAhNWOxI 2hibyWaUABj1qPcrsP5hhhBLASxMixdVzvCJ8+uQuCjKIBDTleehNp48iyutpVgFCyY9 Q4VARzMbQ95u1eec/B2w/U4LjrHZD0ThR9kA7W/cUyMxIcuONzu/OJaNoRBfHn1/GQI4 ChQw== MIME-Version: 1.0 X-Received: by 10.180.37.230 with SMTP id b6mr12520903wik.47.1404410316049; Thu, 03 Jul 2014 10:58:36 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Thu, 3 Jul 2014 10:58:35 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B1FC18D@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <6355614E-44DA-4729-97C2-E903548EBA8B@gmail.com> <949EF20990823C4C85C18D59AA11AD8B1FC18D@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Thu, 3 Jul 2014 10:58:35 -0700 Message-ID: From: Martin Thomson To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Ku_dk7g3iF8TjGP0JArKq4xtVko Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS version X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Jul 2014 17:58:45 -0000 On 3 July 2014 01:39, DRAGE, Keith (Keith) wrote: > Can someone elaborate what this massive apparent step change is from 1.0 to 1.2? Actually, it's not a massive step. TLS 1.2 (DTLS 1.2 depends on this, DTLS 1.0 depends on TLS 1.1) adds AEAD modes, but doesn't require their use, so you can pretty much just bump the version number and advertise 1.2. That's exactly what we did with NSS, though NSS already supports TLS 1.2. That said, I agree with Jim about 1.0. There's enough 1.0 out there now to make mandating 1.2 - as much as I might prefer that - a little too aggressive. > Will those implementations that choose to stay with 1.0 still interwork with 1.2? That depends. We could say "MUST NOT negotiate 1.0", which would prevent that. I don't think that we're there. From nobody Fri Jul 4 01:07:42 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20AB51A01AC for ; Fri, 4 Jul 2014 01:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNOObELrx1d0 for ; Fri, 4 Jul 2014 01:07:30 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4E61A064E for ; Fri, 4 Jul 2014 01:07:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 54F847C38A3 for ; Fri, 4 Jul 2014 10:07:29 +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 AzCCV4QGVvPo for ; Fri, 4 Jul 2014 10:07:27 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:101:1bc:3f43:82ea]) by mork.alvestrand.no (Postfix) with ESMTPSA id 99C067C3855 for ; Fri, 4 Jul 2014 10:07:25 +0200 (CEST) Message-ID: <53B660BC.4090907@alvestrand.no> Date: Fri, 04 Jul 2014 10:07:24 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <6355614E-44DA-4729-97C2-E903548EBA8B@gmail.com> <949EF20990823C4C85C18D59AA11AD8B1FC18D@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0nXhrm2CA_5IxituRz5JghrJwdU Subject: Re: [rtcweb] DTLS version X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Jul 2014 08:07:38 -0000 On 07/03/2014 07:58 PM, Martin Thomson wrote: > On 3 July 2014 01:39, DRAGE, Keith (Keith) > wrote: >> Can someone elaborate what this massive apparent step change is from 1.0 to 1.2? > Actually, it's not a massive step. TLS 1.2 (DTLS 1.2 depends on this, > DTLS 1.0 depends on TLS 1.1) adds AEAD modes, but doesn't require > their use, so you can pretty much just bump the version number and > advertise 1.2. That's exactly what we did with NSS, though NSS > already supports TLS 1.2. > > That said, I agree with Jim about 1.0. There's enough 1.0 out there > now to make mandating 1.2 - as much as I might prefer that - a little > too aggressive. > >> Will those implementations that choose to stay with 1.0 still interwork with 1.2? > That depends. We could say "MUST NOT negotiate 1.0", which would > prevent that. I don't think that we're there. Sounds to me like MUST implement 1.2 (in order to move forward), MUST accept 1.0 (in order to not lose the long tail). > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Jul 4 01:26:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FC21B2C7B for ; Fri, 4 Jul 2014 01:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 0sgD90BM6aky for ; Fri, 4 Jul 2014 01:26:41 -0700 (PDT) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 769471B2C6D for ; Fri, 4 Jul 2014 01:26:41 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id z60so1192767qgd.24 for ; Fri, 04 Jul 2014 01:26:40 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=Aumc4PerOUx3XBuhKRx7g0aLLCAAhHeWIzP4vgTtq7c=; b=GyI4vabZ8AouhQZyLquaXIN9IKL3Y1Qn5c0imieSlnTvttFpf7HYSjav0Y+z45yJ2t HsMl9BudmaVfHJVoKpQqXjd2fHtJwI+3QysbaYohE5dx2Kz+MGZaFIqu8lxOR57DGSRx DKAsO6TCu4ig7283baB34EJnJl8ovLCFdHOIwpizInjSYA9yL29SPzaHWWk4T1e6J3cA fiyeteM7CWtHZRyAp/lQiwixo++zQut8lBYQQv5hiU9iNZFEcNafypGNNuMeYiuPa3mv IW60ahnJZGKy1TCfidZNEmRhxbLfO/rN+xilm30dcQjRvFaiI0eCrrO0WAJKaotu6vjT lSzQ== X-Gm-Message-State: ALoCoQmNeeLf/MgmtQPspQB0Z7Z5cYOF1kZj96UWfZJxKRhAENX7rENhS+erLywx2ALIRdnNFUGC X-Received: by 10.140.40.81 with SMTP id w75mr15363853qgw.112.1404462400662; Fri, 04 Jul 2014 01:26:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.234.131 with HTTP; Fri, 4 Jul 2014 01:26:20 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 4 Jul 2014 10:26:20 +0200 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qjxYW11JFqAyCWDwBPy8bkV8FEs Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [rtcweb] [MMUSIC] Dummy ports X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Jul 2014 08:26:43 -0000 2014-07-03 1:22 GMT+02:00 Eric Rescorla : > Trickle requires that you use port 9 for the c-line if you are doing full > trickle: > http://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-01#section-5.1 Isn't there any other way to indicate it instead of setting port to 9? =C2=BFany attribute? Section 5.1 [*] in draft-ietf-mmusic-trickle-ice-01 is really exasperating. [*] http://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-01#section-5.1 --=20 I=C3=B1aki Baz Castillo From nobody Fri Jul 4 03:23:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9233A1B2CE3 for ; Fri, 4 Jul 2014 03:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Asuue_5GCdXR for ; Fri, 4 Jul 2014 03:23:50 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F1F71B2816 for ; Fri, 4 Jul 2014 03:23:50 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s64ANeuW027112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Jul 2014 05:23:42 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s64ANdi3005055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jul 2014 12:23:40 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.71]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 4 Jul 2014 12:23:39 +0200 From: "DRAGE, Keith (Keith)" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] DTLS version Thread-Index: AQHPluhoQia+CLBEBkOxqOTgqEBL35uPbqEAgABGAyA= Date: Fri, 4 Jul 2014 10:23:39 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B1FD11D@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <6355614E-44DA-4729-97C2-E903548EBA8B@gmail.com> <949EF20990823C4C85C18D59AA11AD8B1FC18D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <53B660BC.4090907@alvestrand.no> In-Reply-To: <53B660BC.4090907@alvestrand.no> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3OS4CEFVvub4EbWCpJzNTgKk8Tc Subject: Re: [rtcweb] DTLS version X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Jul 2014 10:23:52 -0000 This is the direction I am tending in as well. Although what or if the second statement needs from RFC 2119 language would= need to be debated. Obviously, new versions are not being put out there just to make it look li= ke the WG is performing. In any referencing (not just this issue), I would = need a good technical reason why the latest version cannot be made the norm= ative reference. I am not seeing that at the moment. There is always be non-conforming equipment on the market (as an example lo= ok at the number of SIP implementations that still use UDP for large messag= es, or that can at least be configured that way). Just because we mandate 1= .2 does not mean that everyone will conform from day 1, but at least a mark= er is established for what should be addressed if interoperability issues a= re identified. Keith=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of=20 > Harald Alvestrand > Sent: 04 July 2014 09:07 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] DTLS version >=20 > On 07/03/2014 07:58 PM, Martin Thomson wrote: > > On 3 July 2014 01:39, DRAGE, Keith (Keith)=20 > > wrote: > >> Can someone elaborate what this massive apparent step=20 > change is from 1.0 to 1.2? > > Actually, it's not a massive step. TLS 1.2 (DTLS 1.2=20 > depends on this,=20 > > DTLS 1.0 depends on TLS 1.1) adds AEAD modes, but doesn't require=20 > > their use, so you can pretty much just bump the version number and=20 > > advertise 1.2. That's exactly what we did with NSS, though NSS=20 > > already supports TLS 1.2. > > > > That said, I agree with Jim about 1.0. There's enough 1.0=20 > out there=20 > > now to make mandating 1.2 - as much as I might prefer that=20 > - a little=20 > > too aggressive. > > > >> Will those implementations that choose to stay with 1.0=20 > still interwork with 1.2? > > That depends. We could say "MUST NOT negotiate 1.0", which would=20 > > prevent that. I don't think that we're there. >=20 > Sounds to me like MUST implement 1.2 (in order to move=20 > forward), MUST accept 1.0 (in order to not lose the long tail). >=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 Fri Jul 4 06:15:35 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049AA1B28F8 for ; Fri, 4 Jul 2014 06:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 o9HagPLXARnX for ; Fri, 4 Jul 2014 06:15:33 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE5621B2875 for ; Fri, 4 Jul 2014 06:15:32 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id l6so1500049qcy.15 for ; Fri, 04 Jul 2014 06:15:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=5W4kVFJgnUEPcHB98mloMnAKoZUpFrdS0pzXM8+C7dg=; b=hdcMZoe4UYm9UVGO+jZI7MOIx5KSJuNyngSNpP/1X4o/hePcBdD3CzaSO5NoDXz2aw AtLrydrrYhpGikPPJVNtJkd5MLsC8Oi08Pvbs51YdI6YCf6DTgTziz8Wbx5b2USd0Fk7 ohlJBWKuoC6TdDV0r5jW8BQ0fwcT8Vm2zk6X8N7b473F6XdWKB6Vjss5f+jXtTicI6Wz kd2PHEq+bN6TJzVGujwmCqp0ZkJonHrsahZkuoBer+zYzDVMPslT1X/GuWBmhk0CgtwP ZOq7XyPr362hGjW1E5ypIsq9oVo2eVo1wbSQlxw0Su4pwHQQ8j29OUb6Bu09zV9grdq6 vrrw== X-Gm-Message-State: ALoCoQkjFqZCty+7jRF1NrZCZnbStPITAB5U7mHjQa6AGmhcNfoT+wwAhWHO5RfeGsc8NxQeWcgP X-Received: by 10.140.34.55 with SMTP id k52mr17346587qgk.13.1404479731577; Fri, 04 Jul 2014 06:15:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.234.131 with HTTP; Fri, 4 Jul 2014 06:15:11 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 4 Jul 2014 15:15:11 +0200 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qP4aOHj5zSm34N94omWtUD5CJII Subject: [rtcweb] Question about ICE-Lite server X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Jul 2014 13:15:34 -0000 Hi, In case of aggressive ICE the controlling agent (let's say: the client), and assuming the client has IPv4 and IPv6 and the ICE-Lite server as well, the server will receive multiple STUN Requests with USE-CANDIDATE and will decide which one to select based on computed candidate-pair priorities (so both the client and server select the same as they follow the same algorithm). Now my question is: let's assume that the server is just provided with local ICE username and password, but knows nothing about the fields in ICE candidates (let's assume that the SDP is negotiated by other entity which does not notify the media server about ICE candidate parameters others than local username and password). So the media server just knows its local ICE username and password, but it receives a ICE Request with USE-CANDIDATE on the IPv4 interface and another on the IPv6 interface. Can the ICE server determine which pair to select (the IPv4 or the IPv6) by just inspecting the PRIORITY attribute in both STUN Requests and select the one with highest value? Or does the server need to assign priority, component and all the ICE stuff to its interfaces and also be provided with the client's and its own ICE candidates? Thanks a lot. --=20 I=C3=B1aki Baz Castillo From nobody Fri Jul 4 06:43:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DED1B2942 for ; Fri, 4 Jul 2014 06:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACoLk7_bkfpA for ; Fri, 4 Jul 2014 06:43:27 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6F031B2932 for ; Fri, 4 Jul 2014 06:43:26 -0700 (PDT) Received: from [192.168.1.200] (p508F1178.dip0.t-ipconnect.de [80.143.17.120]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 49AA41C0E97A0; Fri, 4 Jul 2014 15:43:21 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B1FD11D@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Fri, 4 Jul 2014 15:43:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6355614E-44DA-4729-97C2-E903548EBA8B@gmail.com> <949EF20990823C4C85C18D59AA11AD8B1FC18D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <53B660BC.4090907@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8B1FD11D@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/O_NEp0LEPPXXCTR0rnX61E4B77w Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS version X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Jul 2014 13:43:29 -0000 On 04 Jul 2014, at 12:23, DRAGE, Keith (Keith) = wrote: > This is the direction I am tending in as well. >=20 > Although what or if the second statement needs from RFC 2119 language = would need to be debated. >=20 > Obviously, new versions are not being put out there just to make it = look like the WG is performing. In any referencing (not just this = issue), I would need a good technical reason why the latest version = cannot be made the normative reference. I am not seeing that at the = moment. >=20 > There is always be non-conforming equipment on the market (as an = example look at the number of SIP implementations that still use UDP for = large messages, or that can at least be configured that way). Just = because we mandate 1.2 does not mean that everyone will conform from day = 1, but at least a marker is established for what should be addressed if = interoperability issues are identified. Hmm, the submission deadline is approaching and I try to figure out if = there is consensus which DTLS version to use: We used DTLS 1.2 on the SCTP over DTLS ID, and both data channel IDs. During the WG LC I got the comment that RTCWeb uses 1.0, so please = change it. I haven't got these comments on the data channel IDs during WG LC. It looks like I'll change the documents to use 1.0 for now, submit them. = Then we have a consistent state. If the WG (or the IESG) decides that we want = 1.2, the IDs have to be resubmitted after the IETF. Best regards Michael >=20 > Keith=20 >=20 >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of=20 >> Harald Alvestrand >> Sent: 04 July 2014 09:07 >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] DTLS version >>=20 >> On 07/03/2014 07:58 PM, Martin Thomson wrote: >>> On 3 July 2014 01:39, DRAGE, Keith (Keith)=20 >>> wrote: >>>> Can someone elaborate what this massive apparent step=20 >> change is from 1.0 to 1.2? >>> Actually, it's not a massive step. TLS 1.2 (DTLS 1.2=20 >> depends on this,=20 >>> DTLS 1.0 depends on TLS 1.1) adds AEAD modes, but doesn't require=20 >>> their use, so you can pretty much just bump the version number and=20= >>> advertise 1.2. That's exactly what we did with NSS, though NSS=20 >>> already supports TLS 1.2. >>>=20 >>> That said, I agree with Jim about 1.0. There's enough 1.0=20 >> out there=20 >>> now to make mandating 1.2 - as much as I might prefer that=20 >> - a little=20 >>> too aggressive. >>>=20 >>>> Will those implementations that choose to stay with 1.0=20 >> still interwork with 1.2? >>> That depends. We could say "MUST NOT negotiate 1.0", which would=20 >>> prevent that. I don't think that we're there. >>=20 >> Sounds to me like MUST implement 1.2 (in order to move=20 >> forward), MUST accept 1.0 (in order to not lose the long tail). >>=20 >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Fri Jul 4 08:38:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CC31B2CC7 for ; Fri, 4 Jul 2014 08:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.852 X-Spam-Level: X-Spam-Status: No, score=-14.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxRB8pPcMkG6 for ; Fri, 4 Jul 2014 08:38:06 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D5DF1B2CAE for ; Fri, 4 Jul 2014 08:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4167; q=dns/txt; s=iport; t=1404488286; x=1405697886; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=f63n206iQP8uzUGIgNf7qdKpOWyWxSIQLPc/dCARV+c=; b=YEe3Cqmn/T8EnKT0lln0ffkr2ZYb0JbTVFq6ikMtvaToFCiRbvjT6vE3 itOgX5AzRiIpZK7qoM5EFSBdMCzi8A2y8BTiQ0TfRXh3AciEuJHZ1rNNu xwDNJeGF9L/7EemTAJL+EE9SKwMsZCuRo2MkjAd0jBOM0SrrAQ9a2iQTR k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIKAHDJtlOtJV2Y/2dsb2JhbABagw5SUwe+aoZsUwGBCxZ1hAMBAQEEAQEBaxcEAgEIEQMBAQEoBycLFAkIAgQBEgmIOQgFykkXjncyBoQ9BYoXkF+BSJJEg0OBbgc7 X-IronPort-AV: E=Sophos;i="5.01,601,1400025600"; d="scan'208";a="58361832" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP; 04 Jul 2014 15:38:05 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s64Fc5fl010209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jul 2014 15:38:05 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.10]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 10:38:04 -0500 From: "Ram Mohan R (rmohanr)" To: "Rauschenbach, Uwe (NSN - DE/Munich)" , "ext Christer Holmberg" , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-04.txt Thread-Index: AQHPl53x93N3RnQenEqxwMutVlFpdg== Date: Fri, 4 Jul 2014 15:38:04 +0000 Message-ID: References: <20140618031726.3502.90813.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D3ACBF8@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8338BC2@DEMUMBX005.nsn-intra.net> In-Reply-To: <56C2F665D49E0341B9DF5938005ACDF8338BC2@DEMUMBX005.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.55.100] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2DEEFDCFB416A14AA145B963EB51A7DC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kyJRShW0whu1w2f2FKwDgRU2Z1c Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Jul 2014 15:38:08 -0000 Thanks for the comments. We have added some text at the end of the introduction section and published a new revision. Please review and provide your feedback. Regards, Ram -----Original Message----- From: , "Uwe (NSN - DE/Munich)" Date: Wednesday, 2 July 2014 9:50 pm To: ext Christer Holmberg , I=F1aki Baz Castillo , "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-04.txt >Same here.=20 >It makes sense to clarify that they must respond to consent requests, but >don't need to send them. > >Kind regards, >Uwe=20 > >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Christer >> Holmberg >> Sent: Tuesday, July 01, 2014 11:19 AM >> To: I=F1aki Baz Castillo; rtcweb@ietf.org >> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent- >> freshness-04.txt >>=20 >> +1 >>=20 >> I get this question every now and then, so I think it would be good to >> clarify in the draft. >>=20 >> Regards, >>=20 >> Christer >>=20 >> ________________________________________ >> From: rtcweb [rtcweb-bounces@ietf.org] on behalf of I=F1aki Baz Castillo >> [ibc@aliax.net] >> Sent: Tuesday, 01 July 2014 12:12 PM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent- >> freshness-04.txt >>=20 >> Hi, >>=20 >> May the draft include some text clarifying that ICE-Lite endpoints do >> not need to send Consent Freshness STUN requests to the remote peer? >>=20 >> Best regards. >>=20 >>=20 >> 2014-06-18 5:17 GMT+02:00 : >> > >> > 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 Working Group of the IETF. >> > >> > Title : STUN Usage for Consent Freshness >> > Authors : Muthu Arul Mozhi Perumal >> > Dan Wing >> > Ram Mohan Ravindranath >> > Tirumaleswar Reddy >> > Martin Thomson >> > Filename : draft-ietf-rtcweb-stun-consent-freshness- >> 04.txt >> > Pages : 9 >> > Date : 2014-06-17 >> > >> > Abstract: >> > To prevent sending excessive traffic to an endpoint, periodic >> consent >> > needs to be obtained from that remote endpoint. >> > >> > This document describes a consent mechanism using a new STUN usage. >> > This same mechanism can also determine connection loss ("liveness") >> > with a remote peer. >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent- >> freshness/ >> > >> > There's also a htmlized version available at: >> > http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-04 >> > >> > A diff from the previous version is available at: >> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent- >> freshness-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/ >> > >> > _______________________________________________ >> > rtcweb mailing list >> > rtcweb@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >>=20 >>=20 >> -- >> I=F1aki Baz Castillo >> >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Jul 4 08:40:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A0B1B2ADA; Fri, 4 Jul 2014 08:40:37 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VzZt-oAdEeQ; Fri, 4 Jul 2014 08:40:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 432E21B2DBB; Fri, 4 Jul 2014 08:40:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704154017.13144.3674.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 08:40:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qDyuogjCadZzJxsmzkexYg-K6lg Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-constraints-registry-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-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, 04 Jul 2014 15:40: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 Working Group of the IETF. Title : IANA Registry for RTCWeb Constrainable Properties Author : Daniel C. Burnett Filename : draft-ietf-rtcweb-constraints-registry-00.txt Pages : 5 Date : 2014-07-04 Abstract: Specifications in W3C's Media Capture Task Force and WebRTC Working Group have need of a registry in which to maintain a list of constrainable properties for HTML media and other constrainable objects. This document defines this registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-constraints-registry/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-constraints-registry-00 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 Jul 4 08:42:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C0E1B2DCD; Fri, 4 Jul 2014 08:42:10 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTQiaKGeMsNb; Fri, 4 Jul 2014 08:42:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A534A1B2DC9; Fri, 4 Jul 2014 08:42:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704154209.13282.96755.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 08:42:09 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zVOOJyiZZkfaccUyYjCFvp08YKM Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-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, 04 Jul 2014 15:42:11 -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 Working Group of the IETF. Title : STUN Usage for Consent Freshness Authors : Muthu Arul Mozhi Perumal Dan Wing Ram Mohan Ravindranath Tirumaleswar Reddy Martin Thomson Filename : draft-ietf-rtcweb-stun-consent-freshness-05.txt Pages : 9 Date : 2014-07-04 Abstract: To prevent sending excessive traffic to an endpoint, periodic consent needs to be obtained from that remote endpoint. This document describes a consent mechanism using a new STUN usage. This same mechanism can also determine connection loss ("liveness") with a remote peer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshness-05 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 Jul 4 08:44:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDFD1A0176 for ; Fri, 4 Jul 2014 08:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSI-sCnwkYXs for ; Fri, 4 Jul 2014 08:44:39 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3FC1A014E for ; Fri, 4 Jul 2014 08:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2202; q=dns/txt; s=iport; t=1404488679; x=1405698279; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=49dRZ1u5kiO4qjFXm2GpC8C1t4WDFVwHHAd9aAVnedM=; b=Ue5f/u733ZQEe0RWYK9b48RmHB6Xg4aAHHlii/FpN5WjXx9bp2uFEMWh QyltcAAVw+wOCLLpkGKcGcjxAhk1elBobN1pnEvK3LH4aGlSJRx7Ra6xs h3/JlNTkAJQNk8DONv5uEl2f7uyOAkfP01DtK8MiCXBSBw0eoRTcLp9SP c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoEKAOTKtlOtJA2K/2dsb2JhbABagw5SUwe+aoZsUwGBCxZ1hAMBAQEEAQEBaxcEAgEIEQMBAi8nCx0IAgQTCYg5CAXKSBeObzoGhD0FiheQX4FIkkSDQ4Iw X-IronPort-AV: E=Sophos;i="5.01,601,1400025600"; d="scan'208";a="58372155" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP; 04 Jul 2014 15:44:39 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s64FicD1024333 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 4 Jul 2014 15:44:38 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.10]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 10:44:38 -0500 From: "Ram Mohan R (rmohanr)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-05.txt Thread-Index: AQHPl57cRxiLrwcSqEK3PGmDCGv8cg== Date: Fri, 4 Jul 2014 15:44:37 +0000 Message-ID: References: <20140704154209.13282.96755.idtracker@ietfa.amsl.com> In-Reply-To: <20140704154209.13282.96755.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.55.100] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <767BC765A0BF434BA89683E3E514D48A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9ZbQCrPM9GwUa7RCvq4XE830wPs Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Jul 2014 15:44:41 -0000 New revision changes includes: Added a line at the end of Introduction section for ICE lite Re-worded the text that had the word =B3inverted=B2. Regards, Ram -----Original Message----- From: "internet-drafts@ietf.org" Date: Friday, 4 July 2014 9:12 pm To: "i-d-announce@ietf.org" Cc: "rtcweb@ietf.org" Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-05.txt > >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 >Working Group of the IETF. > > Title : STUN Usage for Consent Freshness > Authors : Muthu Arul Mozhi Perumal > Dan Wing > Ram Mohan Ravindranath > Tirumaleswar Reddy > Martin Thomson > Filename : draft-ietf-rtcweb-stun-consent-freshness-05.txt > Pages : 9 > Date : 2014-07-04 > >Abstract: > To prevent sending excessive traffic to an endpoint, periodic consent > needs to be obtained from that remote endpoint. > > This document describes a consent mechanism using a new STUN usage. > This same mechanism can also determine connection loss ("liveness") > with a remote peer. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-05 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent-freshnes= s- >05 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Jul 4 10:01:23 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1DB51A019C for ; Fri, 4 Jul 2014 10:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-7O692ELHb8 for ; Fri, 4 Jul 2014 10:01:17 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 346961A019A for ; Fri, 4 Jul 2014 10:01:17 -0700 (PDT) Received: from [192.168.1.200] (p508F1178.dip0.t-ipconnect.de [80.143.17.120]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 0A09B1C0E97A0; Fri, 4 Jul 2014 19:01:14 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D35CD5E@ESESSMB209.ericsson.se> Date: Fri, 4 Jul 2014 19:01:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1B36D110-8318-40A6-84B3-B8425C52CB77@lurchi.franken.de> References: <7594FB04B1934943A5C02806D1A2204B1D35B976@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D35CD5E@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Q78TBSkTXTxzxH52tuYpapydB-M Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WGLC for data channel drafts - sub-protocol usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Jul 2014 17:01:20 -0000 On 11 Jun 2014, at 19:24, Christer Holmberg = wrote: > Hi Michael, >=20 > I agree that we need to keep text about the encoding. OK. Best regards Michael >=20 > Regards, >=20 > Christer >=20 > ________________________________________ > From: Michael Tuexen [Michael.Tuexen@lurchi.franken.de] > Sent: Wednesday, 11 June 2014 5:28 PM > To: Christer Holmberg > Cc: Ted Hardie; rtcweb@ietf.org > Subject: Re: [rtcweb] WGLC for data channel drafts - sub-protocol = usage >=20 > On 10 Jun 2014, at 21:22, Christer Holmberg = wrote: >=20 >> Hi, >>=20 >> A comment on draft-ietf-rtcweb-data-protocol-06: >>=20 >> Section 5.1 says: >>=20 >> "Protocol: Variable Length (sequence of characters) >> The sub-protocol for the channel as a UTF-8 encoded string. If >> this is an empty string the protocol is unspecified. If it is a >> non-empty string, it specifies an protocol registered in the >> 'WebSocket Subprotocol Name Registry' created in [RFC6455]." >>=20 >>=20 >> I think "The sub-protocol for the channel as a UTF-8 encoded string." = part is a little confusing, because there is no such thing as = sub-protocol in DCEP itself (DCEP only uses the WebSocket sub-protocol = registry for registering DCEP *protocol* values). >>=20 >> Perhaps we could just remove the sentence, and keep: >>=20 >> "Protocol: Variable Length (sequence of characters) >> If this is an empty string the protocol is unspecified. If it = is a >> non-empty string, it specifies an protocol registered in the >> 'WebSocket Subprotocol Name Registry' created in [RFC6455]." >>=20 >> Section 4 gives more information about the usage of the protocol. > Do you intend to drop the statement about the UTF-8 encoding? > I think we should keep a statement about the encoding. >=20 > Best regards > Michael >>=20 >> (Alternatively, we could use sub-protocol terminology also in DCEP) >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Ted Hardie = [ted.ietf@gmail.com] >> Sent: Tuesday, 10 June, 2014 9:52 PM >> To: rtcweb@ietf.org >> Subject: [rtcweb] WGLC for data channel drafts >>=20 >> Dear WG, >>=20 >> This starts a working group last call for our core Data Channel = drafts: >>=20 >> draft-ietf-rtcweb-data-protocol-06.txt >> draft-ietf-rtcweb-data-channel-10.txt >>=20 >> Please review them in detail, especially for areas which may be of = concern to the broader IETF community. This WGLC will end on June 27, = 2014. >>=20 >> Ted, Sean, Cullen >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Jul 4 10:23:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915621B2C76 for ; Fri, 4 Jul 2014 10:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEgrdVonAzVd for ; Fri, 4 Jul 2014 10:23:01 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B739D1B2B22 for ; Fri, 4 Jul 2014 10:23:00 -0700 (PDT) Received: from [192.168.1.200] (p508F1178.dip0.t-ipconnect.de [80.143.17.120]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id EB89F1C104D83; Fri, 4 Jul 2014 19:22:58 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <53A9824D.9090401@nteczone.com> Date: Fri, 4 Jul 2014 19:22:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53A9824D.9090401@nteczone.com> To: Christian Groves X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DevpdVoYqjaJZbP4seaX0wXYW28 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WGLC for data channel drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Jul 2014 17:23:03 -0000 On 24 Jun 2014, at 15:51, Christian Groves = wrote: > Some comments: >=20 > draft-ietf-rtcweb-data-channel talks about unreliable use cases. = Draft-ietf-rtcweb-data-protocol-06 in clause 4 also mentions "reliable = or unreliable message transmission". However there is no channel type = for "unreliable" only "DATA_CHANNEL_RELIABLE_xxx" and = "DATA_CHANNEL_PARTIAL_RELIABLE_xxx". Are the "unreliable" use cases/text = actually "partial reliable"? The requirements suggest that unreliable = transport is needed but the solution offered is for reliable and partial = reliability. unreliable is not reliable for me. Partial reliable is another term for = it. In PR-SCTP terminology, partial reliable is used. So you have two incarnations of = unreliable: * timer based * number of retransmission based. >=20 > draft-ietf-rtcweb-data-channel-10 > --------------------------------- > Cl. 6.1 bullet 1: Would "stream reconfiguration" be a better term than = "stream reset"? RFC6525 allows reset and addition of streams. You are right, the extension is called stream reconfiguration. However, = WebRTC doesn't use the addition of streams. The maximum number is always negotiated. > Cl. 6.1 bullet 2: "dynamic address reconfiguration" is the name of the = RFC 5061. Is the part that Data Channel supports only the "Supported = Extensions" parameter (cl.4.2.7/RFC5061)? Correct. Thanks for your comments. Best regards Michael >=20 > Regards, Christian >=20 > On 11/06/2014 4:52 AM, Ted Hardie wrote: >> Dear WG, >>=20 >> This starts a working group last call for our core Data Channel = drafts: >>=20 >> draft-ietf-rtcweb-data-protocol-06.txt >> draft-ietf-rtcweb-data-channel-10.txt >>=20 >> Please review them in detail, especially for areas which may be of = concern to the broader IETF community. This WGLC will end on June 27, = 2014. >>=20 >> Ted, Sean, Cullen >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Fri Jul 4 10:23:14 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5AE81B2D79 for ; Fri, 4 Jul 2014 10:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCQ_IKeXA7Ld for ; Fri, 4 Jul 2014 10:23:05 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE01A1B2B22 for ; Fri, 4 Jul 2014 10:23:04 -0700 (PDT) Received: from [192.168.1.200] (p508F1178.dip0.t-ipconnect.de [80.143.17.120]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id EF0C41C104D9D; Fri, 4 Jul 2014 19:23:02 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <53A7BF3E.8010505@nteczone.com> Date: Fri, 4 Jul 2014 19:23:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D35B976@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D35CD5E@ESESSMB209.ericsson.se> <53A7BF3E.8010505@nteczone.com> To: Christian Groves X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/s2fuHxZQkG_Xdwmmne4VRXm0BrQ Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WGLC for data channel drafts - sub-protocol usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Jul 2014 17:23:07 -0000 On 23 Jun 2014, at 07:46, Christian Groves = wrote: > Do you need that statement? I guess formally you don't. But having it make it simpler for the = reader... Best regards Michael > [RFC6455] section 11.5 says: >=20 > Subprotocol Identifier > The identifier of the subprotocol, as will be used in the > |Sec-WebSocket-Protocol| header field registered in Section = 11.3.4 > of this specification. The value must conform to the = requirements > given in item 10 of Section 4.1 of this specification -- namely, > the value must be a token as defined by RFC 2616 [RFC2616]. >=20 > "Token" is RFC2616 is defined as: > CHAR =3D > token =3D 1* >=20 > Regards, Christian >=20 > On 12/06/2014 3:24 AM, Christer Holmberg wrote: >> Hi Michael, >>=20 >> I agree that we need to keep text about the encoding. >>=20 >> Regards, >>=20 >> Christer >>=20 >> ________________________________________ >> From: Michael Tuexen [Michael.Tuexen@lurchi.franken.de] >> Sent: Wednesday, 11 June 2014 5:28 PM >> To: Christer Holmberg >> Cc: Ted Hardie; rtcweb@ietf.org >> Subject: Re: [rtcweb] WGLC for data channel drafts - sub-protocol = usage >>=20 >> On 10 Jun 2014, at 21:22, Christer Holmberg = wrote: >>=20 >>> Hi, >>>=20 >>> A comment on draft-ietf-rtcweb-data-protocol-06: >>>=20 >>> Section 5.1 says: >>>=20 >>> "Protocol: Variable Length (sequence of characters) >>> The sub-protocol for the channel as a UTF-8 encoded string. = If >>> this is an empty string the protocol is unspecified. If it is = a >>> non-empty string, it specifies an protocol registered in the >>> 'WebSocket Subprotocol Name Registry' created in [RFC6455]." >>>=20 >>>=20 >>> I think "The sub-protocol for the channel as a UTF-8 encoded = string." part is a little confusing, because there is no such thing as = sub-protocol in DCEP itself (DCEP only uses the WebSocket sub-protocol = registry for registering DCEP *protocol* values). >>>=20 >>> Perhaps we could just remove the sentence, and keep: >>>=20 >>> "Protocol: Variable Length (sequence of characters) >>> If this is an empty string the protocol is unspecified. If it = is a >>> non-empty string, it specifies an protocol registered in the >>> 'WebSocket Subprotocol Name Registry' created in [RFC6455]." >>>=20 >>> Section 4 gives more information about the usage of the protocol. >> Do you intend to drop the statement about the UTF-8 encoding? >> I think we should keep a statement about the encoding. >>=20 >> Best regards >> Michael >>> (Alternatively, we could use sub-protocol terminology also in DCEP) >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Ted Hardie = [ted.ietf@gmail.com] >>> Sent: Tuesday, 10 June, 2014 9:52 PM >>> To: rtcweb@ietf.org >>> Subject: [rtcweb] WGLC for data channel drafts >>>=20 >>> Dear WG, >>>=20 >>> This starts a working group last call for our core Data Channel = drafts: >>>=20 >>> draft-ietf-rtcweb-data-protocol-06.txt >>> draft-ietf-rtcweb-data-channel-10.txt >>>=20 >>> Please review them in detail, especially for areas which may be of = concern to the broader IETF community. This WGLC will end on June 27, = 2014. >>>=20 >>> Ted, Sean, Cullen >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Fri Jul 4 10:23:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85501B2DE4 for ; Fri, 4 Jul 2014 10:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XKapoXJiLF1 for ; Fri, 4 Jul 2014 10:23:13 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7D7A1B2D79 for ; Fri, 4 Jul 2014 10:23:10 -0700 (PDT) Received: from [192.168.1.200] (p508F1178.dip0.t-ipconnect.de [80.143.17.120]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id D865F1C104D83; Fri, 4 Jul 2014 19:23:08 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D35B9DC@ESESSMB209.ericsson.se> Date: Fri, 4 Jul 2014 19:23:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <51BB47C4-CBA2-4F52-B62B-8FF1A643911D@lurchi.franken.de> References: <7594FB04B1934943A5C02806D1A2204B1D35B9DC@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/l0_DDglvemm5lnUXkAXJdoCa-rw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WGLC for data channel drafts - web terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Jul 2014 17:23:18 -0000 On 10 Jun 2014, at 21:42, Christer Holmberg = wrote: > Hi, > =20 > A comment (which has been raised before) on = draft-ietf-rtcweb-data-channel-10: > =20 > The name of the mechanism is "WebRTC Data Channel", and much of the = text gives a picture that the mechanism is only to be used within the = WebRTC context. > =20 > If we want to call it "WebRTC Data Channel", we should make it clear = that WebRTC is only one scenario where it can be used, but that it can = also be used elsewhere. For example, we are using it in CLUE. > =20 > A few places, where I think we need modifications to reflect it. > =20 > Section 3: > ------------ > =20 > Q3_1: s/For general use cases see = [I-D.ietf-rtcweb-use-cases-and-requirements]./For WebRTC use cases see = [I-D.ietf-rtcweb-use-cases-and-requirements]. Taken. > =20 > Q3_2: In sections 3.1 and 3.2, there are a number of WebRTC specific = requirements, and "PeerConnection", "JavaScript" etc terminology is = used. I think it should be clear that those requirements come from = WebRTC. I think it is... > =20 > =20 > Section 5: > ------------ > =20 > Q5_1: I suggest to replace: > =20 > "SCTP multihoming will not be used in WebRTC." > =20 > ...with something like: > =20 > "The WebRTC Data Channel mechanism does not support SCTP = multihoming." OK. > =20 > =20 > Section 6: > ------------ > =20 > Q6_1: In section 6.2, the follwoing sentence: > =20 > "The SCTP association will be set up when the two endpoints of the > WebRTC PeerConnection agree on opening it, as negotiated by JSEP > (typically an exchange of SDP) [I-D.ietf-rtcweb-jsep]." > =20 > ...only applies to WebRTC. But, it needs to be clear that, in other = contexts, other mechanisms can be used. OK, I prepended 'In the WebRTC context, ' > =20 > =20 > Q6_2: In section 6.4, I suggest to re-order the paragraphs in the = following way: > =20 > "The realization of a bidirectional Data Channel is a pair of one > incoming stream and one outgoing SCTP stream having the same stream > SCTP identifier. >=20 > How stream values are selected is protocol and implementation > dependent. >=20 > Each data channel also has a priority, which is an 2 byte unsigned > integer value. These priorities MUST be interpreted as weighted- > fair-queuing scheduling priorities per the definition of the > corresponding stream scheduler supporting interleaving in > [I-D.ietf-tsvwg-sctp-ndata]. For use in WebRTC, the values used > SHOULD be one of 128 ("below normal"), 256 ("normal"), 512 ("high") > or 1024 ("extra high"). >=20 > The W3C has consensus on defining the application API for WebRTC > DataChannels to be bidirectional. They also consider the notions = of > in-sequence, out-of-sequence, reliable and unreliable as properties > of Channels. One strong wish is for the application-level API to = be > close to the API for WebSockets, which implies bidirectional = streams > of data and waiting for onopen to fire before sending, a textual > label used to identify the meaning of the stream, among other = things." > =20 > ...because, the realization is the important part :) I think one can leave the last paragraph as the first, but I agree, the sequence of the others is better. So some reordering done. Thanks for the comments. Best regards Michael > =20 > Regards, > =20 > Christer > =20 > =20 > =20 > =20 > =20 > From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Ted Hardie = [ted.ietf@gmail.com] > Sent: Tuesday, 10 June, 2014 9:52 PM > To: rtcweb@ietf.org > Subject: [rtcweb] WGLC for data channel drafts >=20 > Dear WG, >=20 > This starts a working group last call for our core Data Channel = drafts: >=20 > draft-ietf-rtcweb-data-protocol-06.txt > draft-ietf-rtcweb-data-channel-10.txt >=20 > Please review them in detail, especially for areas which may be of = concern to the broader IETF community. This WGLC will end on June 27, = 2014. >=20 > Ted, Sean, Cullen > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Jul 4 10:23:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262861B2DDE for ; Fri, 4 Jul 2014 10:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgYsLybWoTjD for ; Fri, 4 Jul 2014 10:23:18 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CBF21B2B22 for ; Fri, 4 Jul 2014 10:23:16 -0700 (PDT) Received: from [192.168.1.200] (p508F1178.dip0.t-ipconnect.de [80.143.17.120]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 549DB1C104DEE; Fri, 4 Jul 2014 19:23:14 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <53AD6AE4.4050707@alvestrand.no> Date: Fri, 4 Jul 2014 19:23:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <12EED657-F653-4AEF-996D-5EFAE67D3E3E@lurchi.franken.de> References: <53AD6AE4.4050707@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Zqg0QwrnyC1IG5aLzSe8dNNNd6E Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WGLC review for data channel drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Jul 2014 17:23:28 -0000 On 27 Jun 2014, at 15:00, Harald Alvestrand = wrote: > On 06/10/2014 08:52 PM, Ted Hardie wrote: >> Dear WG, >>=20 >> This starts a working group last call for our core Data Channel = drafts: >>=20 >> draft-ietf-rtcweb-data-protocol-06.txt >> draft-ietf-rtcweb-data-channel-10.txt >>=20 >> Please review them in detail, especially for areas which may be of = concern to the broader IETF community. This WGLC will end on June 27, = 2014. >=20 > This is my Last Call review of these two drafts. First of all, thank you very much for the comments. >=20 > First of all: The drafts are ready for IETF Last Call. > Second: There are a number of details that should be fixed. Whether = that happens before IETF Last Call or not is not of great concern to me. I'll submit an update. That gives all the same basis for further = discussions. >=20 > draft-ietf-rtcweb-data-channel-10 > ---------------------------------------------- > Abstract >=20 > Ten years from now, the RFC will exist, but the RTCWEB WG will not. I = suggest replacing "The Real-Time Communication in Web browsers working = group is charged to" with "The WebRTC framework specifies". OK so it reads: The WebRTC framework specifies protocol support for direct = interactive rich communication using audio, video, and data between two peers' = web-browsers. >=20 > 1. Introduction >=20 > It's a little abrupt. Some more words of introduction may be needed = here. Something like this: >=20 > In the WebRTC framework, communication between the parties consists of = media (for example audio and video) and non-media data. Media is sent = using SRTP, and is not specified further here. Non-media data is handled = by...." Done. Good suggestion. >=20 > I suggest a global replace of "non-SRTP media data" with "non-media = data" (3 occurences total). "non-SRTP media data" can be parsed as = "media data that is not carried over SRTP", which is not the intended = meaning. Done. >=20 > 4. Requirements >=20 > Suggest striking "and that the WebRTC PeerConnection as a whole is = fair with competing traffic such as TCP". The RMCAT discussions have = proved how difficult it is just to define that, far less achieve it. > If we want to say something in relation to TCP, I would suggest "and = that the WebRTC PeerConnection does not cause excessive problems when = run in parallel with TCP connections". Taken. >=20 > 5. SCTP over DTLS over UDP Considerations >=20 > In the paragraph on SCTP multihoming, I suggest using "the DTLS layer" = instead of "the lower layer". There are multiple lower layers, = identifying which one is mentioned here improves clarity. OK. >=20 > The term "user-land" is used here, while Req. 10 uses "user = application space". I suggest using "user application space" in both = places. OK. >=20 > The paragraph "When using DTLS as the lower layer..." repeats the info = that SCTP multihoming is not used. It may be enough to say this once. Taken out. >=20 > "The partial reliability extension MUST support policies..." - this = paragraph would be more implementable if specific policies, specified in = an I-D or RFC, were referenced. References added. >=20 > The split between section 5 and section 6 seems odd. In particular, = the section "This SCTP stack and its upper layer...." down to "exactly = once and delivered in the order received." seems to belong to section 6 = not section 5. Text reorganised and removed duplicate text. >=20 > 6.1 SCTP Protocol Considerations >=20 > I think the -ndata messsage interleaving MUST be implemented, = according to previous consensus. > "SHOULD be used" seems both meaningless and unneccssary. I think the current text covers the case that it is not available in = implementations yet. If you write MUST be implemented, a conformant implementation would = reject interworking with currently existing implementations. >=20 > 6.2 Association setup >=20 > Nit: "that can negotiated" -> "that can be negotiated" Fixed. >=20 > 6.4 Channel definition >=20 > The title should probably be "WebRTC Data Channel Definition". OK. >=20 > As part of getting the WGs out of the document, the first sentence = should be "The WebRTC DataChannels are bidirectional." OK. > "Among other things" is a bad term to have in a document at Last Call = time. Can we remove it? Done. >=20 > The SHOULD for -ndata- interleaving should be MUST implement and MUST = offer. If it is not successfully negotiated at association setup time = (is that how it works?), the "SHOULD limit" clause is appropriate. But if it is MUST implement and MUST offer, how could it be not = negotiated? If it is offered by both sides, it is used. The SHOULD covers that it might = not be supported. So I think the text is in tune with other parts of the data channel = documents. >=20 > 6.7 Closing a channel >=20 > Nit: "available to reuse" -> "available for reuse" > Nit: "before resetting the stream" -> "before the stream is reset" Both fixed. >=20 > 7 Security considerations >=20 > Is there a security worry with an attacker sending over-long messages = in an attempt to cause OOM situations? OK, I added: I should be noted that a receiver must be prepared that the sender = tries to send arbitrary large messages. >=20 > draft-ietf-rtcweb-data-protocol-06 > --------------------------------------------- > Abstract: Same worry about WG reference. Same as above. >=20 > 3. Terminology >=20 > Stream is defined in terms of stream, which is unhealthy. A reference = to a section of a relevant SCTP document would be better. >=20 > The term "SCTP stream" occurs at least 18 times in the document (out = of approx 41 occurences of "stream" overall). We should either use "SCTP = stream" consistently" or stick to "Stream" consistently. Changed to Stream consistently. >=20 > The term "SCTP stream identifier" (or "stream identifier") should be = called out in the terminology. OK. >=20 > The term "data channel" occurs 36 times. Consider standardizing on = either Channel or Data Channel, and either capitalizing it or not. OK. Using Data Channel consistently. >=20 > 6 Procedures > Nit: "the sender of it can start" -> "the sender of the = DATA_CHANNEL_OPEN can start" Done. >=20 > "If a DATA_CHANNEL_OPEN message is received .... the stream identifier = corresponds to the role of the peer" - is there a reason to insist that = the protocol machine enforce the odd/even rule? I would like to define what happens if the peer does not follow the = rule... It has to be handled by any implementation, so why leave it up to the implementer? > `(actually the next paragraph does not cover the odd/even rule = violation case, which is probably just an unintentional mistake - I = prefer writing this kind of thing in "IF ... ELSE .... Jepp, that was unintentional... > - because if one writes it as "IF ; IF ", the risk of losing some edge cases is high. >=20 > An alternative formulation for the second paragraph is "If the = DATA_CHANNEL_OPEN message doesn't satisfy the conditions above, for = instance if..." Good point. I will use: If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions = above, for instance if a DATA_CHANNEL_OPEN message is received on an already = used Stream or there are any problems with parameters within the = DATA_CHANNEL_OPEN message, the odd/even rule is violated or the DATA_CHANNEL_OPEN message = itself is not well-formed, the receiver MUST close the corresponding channel = using the procedure described in = and MUST NOT send a DATA_CHANNEL_ACK message in response to the received = message. >=20 > 7 Security Considerations >=20 > The "When using..." paragraph sounds a bit off. What about saying >=20 > This protocol does not provide privacy, integrity or authentication. = It needs to be used as part of a protocol suite that contains all these = things. Such a protocol suite is specified in [-dtls-encaps]. Taken. >=20 > Dependency worries > --------------------------- > -protocol- depends normatively on these non-WG documents: >=20 > draft-ietf-tsvwg-sctp-ndata ("I-D exists") This is currently being worked on. > draft-ietf-tsvwg-sctp-dtls-encaps ("AD is watching") This is passed WG LC, just incorporating the comments. So there will be = a new rev tomorrow. > draft-ietf-tsvwg-sctp-prpolicies ("I-D exists") The WG LC started yesterday. Reviews very welcome! > draft-ietf-mmusic-sctp-sdp ("I-D exists") I don't know about the status of this. >=20 > None of these are in the IESG queue. Are we confident of their speed = of progress? >=20 >=20 > This concludes my review. I think the protocol definition is ready, = and needs no changes. >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Jul 4 10:27:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D129B1B2DEF for ; Fri, 4 Jul 2014 10:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 v7X3lYNKezWp for ; Fri, 4 Jul 2014 10:27:51 -0700 (PDT) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B59301B2817 for ; Fri, 4 Jul 2014 10:27:51 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id q107so1640179qgd.41 for ; Fri, 04 Jul 2014 10:27:51 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=fJmFFui9/k6aRRyUj5eEyNtCrrohJChq3PZrhyQWrTw=; b=jIleMcObqP6SIqKx5//sZ1rs+d8EKrLziQJzNBPtlskjQ/TDrLtbsxcBS5XyQntoHL lcfY8AdfYjl9SSP4s+OBQtt+7h10aTjcNE/W4oS1Mly6nfYLknBGx1mCRJEI6+aJcSNU s2iruF5f0jIiPGMcrtuN+QMr+Qn7PU7/OboH/AR+hnWjEfZl6A564v8/lSn9QKU0wnTn P00SKs1HuCpdW8YNfhrP4zSXj5i9RUVXb7d3RHnEz7FVSS3NxxeD2iPv39oCqFcmIfCz BrNcxGd+amajOwmBOJkLFa2rfurq/dxPsfePUn15GrjMJxo73z5EpHswJSBmgn5n2Ws2 vtBA== X-Gm-Message-State: ALoCoQlntMlBcRxxXtv5ipy6e8qU2zbR+o2LqjtSaPjOCXxfB0PKn71qR0vvEhIoBk7nonZeQntS X-Received: by 10.140.34.55 with SMTP id k52mr19661112qgk.13.1404494870984; Fri, 04 Jul 2014 10:27:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.234.131 with HTTP; Fri, 4 Jul 2014 10:27:30 -0700 (PDT) In-Reply-To: References: <20140618031726.3502.90813.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D3ACBF8@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8338BC2@DEMUMBX005.nsn-intra.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 4 Jul 2014 19:27:30 +0200 Message-ID: To: "Ram Mohan R (rmohanr)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zPM8MyAkDHsijGyJuQU7lgXD1rQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Jul 2014 17:27:53 -0000 2014-07-04 17:38 GMT+02:00 Ram Mohan R (rmohanr) : > Thanks for the comments. We have added some text at the end of the > introduction section and published a new revision. Please review and > provide your feedback. IMHO it is clear. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From nobody Fri Jul 4 10:37:29 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C141B2B1D; Fri, 4 Jul 2014 10:37:25 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IVOVSXiuC4K; Fri, 4 Jul 2014 10:37:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E04241B2B1F; Fri, 4 Jul 2014 10:37:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704173720.10132.32732.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 10:37:20 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bL3xE8zjKilP4eXuXCwfTYP4YuU Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-07.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-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, 04 Jul 2014 17:37:26 -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 Working Group of the IETF. Title : WebRTC Data Channel Establishment Protocol Authors : Randell Jesup Salvatore Loreto Michael Tuexen Filename : draft-ietf-rtcweb-data-protocol-07.txt Pages : 12 Date : 2014-07-04 Abstract: The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document specifies a simple protocol for establishing symmetric Data Channels between the peers. It uses a two way handshake and allows sending of user data without waiting for the handshake to complete. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-data-protocol-07 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 Jul 4 10:37:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016CE1B2E19; Fri, 4 Jul 2014 10:37:35 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2z0Kv005K59; Fri, 4 Jul 2014 10:37:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D26421B2E0B; Fri, 4 Jul 2014 10:37:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704173730.15119.70784.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 10:37:30 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qxx1HIY3DJw_Rp9yHvjU3Zl25eE Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-11.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-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, 04 Jul 2014 17:37:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : WebRTC Data Channels Authors : Randell Jesup Salvatore Loreto Michael Tuexen Filename : draft-ietf-rtcweb-data-channel-11.txt Pages : 15 Date : 2014-07-04 Abstract: The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document specifies the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service allowing WEB-browsers to exchange generic data from peer to peer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-data-channel-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 12:49:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C421A0538 for ; Fri, 4 Jul 2014 12:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiB5rUnDw5Ml for ; Fri, 4 Jul 2014 12:49:30 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBE921A009E for ; Fri, 4 Jul 2014 12:49:29 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id cc10so12650421wib.3 for ; Fri, 04 Jul 2014 12:49:28 -0700 (PDT) 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:content-type; bh=4+LBvmPjLlfpX4Q76LXbp6RUq3jeOBNf/GHNMaXhg/M=; b=eZ9HX8jPxACooP5xg9cAD19gk/BZGQjctr4iG0YNhOy7SKLwwqycFO+/vzlTBpqhTE MyZNxh0SNT7c14OFTeTmddhiauCiDRHATCNFO88KQ0to7fdE6/33yaGICMD3vKIMkOGE koKfD8Gz2qmJUa8zyi3u4yz118wHqEEr+u4fD1hrC6DIjfdnx2r3Tq4ABEfepPK8nNZg LO2kWkczFrYvQzKLPMb0qSWcsVs01yutTEeIS2ilPcP4wT2ewJajIKb0+KSswzAj5cJN AlmwKiDEnZgsmsEr0o3qKdaBh0HUat6BbBKwIeIroRiqSCsMB9vJ4KGBwcd6PgckvsKL OhIA== X-Gm-Message-State: ALoCoQlqbqdyM+82jc4kOq2wgswrotSIdx8mBqOh9qnYTemIC7sUl+HeQIJ0/d8fxC6IzygHc2sJ X-Received: by 10.180.76.20 with SMTP id g20mr19128696wiw.7.1404503368394; Fri, 04 Jul 2014 12:49:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.57.202 with HTTP; Fri, 4 Jul 2014 12:48:48 -0700 (PDT) X-Originating-IP: [63.245.221.34] In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B1FD11D@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <6355614E-44DA-4729-97C2-E903548EBA8B@gmail.com> <949EF20990823C4C85C18D59AA11AD8B1FC18D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <53B660BC.4090907@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8B1FD11D@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Eric Rescorla Date: Fri, 4 Jul 2014 12:48:48 -0700 Message-ID: To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=f46d043439465c0c7d04fd636c84 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/oBw-6HbOszbyB486hWHtC0cmMFc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS version X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Jul 2014 19:49:32 -0000 --f46d043439465c0c7d04fd636c84 Content-Type: text/plain; charset=UTF-8 I made this change in the current draft at: https://github.com/rtcweb-wg/security-arch/commit/c2af2bf7fd032abd367dff8d4d16f7ec435fa663 Note that the TLS WG is currently discussing whether to bring ECC onto Standards Track. If they do, we probably want ot require support of ECDHE. We should discuss in YYZ. On Fri, Jul 4, 2014 at 3:23 AM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > This is the direction I am tending in as well. > > Although what or if the second statement needs from RFC 2119 language > would need to be debated. > > Obviously, new versions are not being put out there just to make it look > like the WG is performing. In any referencing (not just this issue), I > would need a good technical reason why the latest version cannot be made > the normative reference. I am not seeing that at the moment. > > There is always be non-conforming equipment on the market (as an example > look at the number of SIP implementations that still use UDP for large > messages, or that can at least be configured that way). Just because we > mandate 1.2 does not mean that everyone will conform from day 1, but at > least a marker is established for what should be addressed if > interoperability issues are identified. > > Keith > > > -----Original Message----- > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of > > Harald Alvestrand > > Sent: 04 July 2014 09:07 > > To: rtcweb@ietf.org > > Subject: Re: [rtcweb] DTLS version > > > > On 07/03/2014 07:58 PM, Martin Thomson wrote: > > > On 3 July 2014 01:39, DRAGE, Keith (Keith) > > > wrote: > > >> Can someone elaborate what this massive apparent step > > change is from 1.0 to 1.2? > > > Actually, it's not a massive step. TLS 1.2 (DTLS 1.2 > > depends on this, > > > DTLS 1.0 depends on TLS 1.1) adds AEAD modes, but doesn't require > > > their use, so you can pretty much just bump the version number and > > > advertise 1.2. That's exactly what we did with NSS, though NSS > > > already supports TLS 1.2. > > > > > > That said, I agree with Jim about 1.0. There's enough 1.0 > > out there > > > now to make mandating 1.2 - as much as I might prefer that > > - a little > > > too aggressive. > > > > > >> Will those implementations that choose to stay with 1.0 > > still interwork with 1.2? > > > That depends. We could say "MUST NOT negotiate 1.0", which would > > > prevent that. I don't think that we're there. > > > > Sounds to me like MUST implement 1.2 (in order to move > > forward), MUST accept 1.0 (in order to not lose the long tail). > > > > > > > > _______________________________________________ > > > rtcweb mailing list > > > rtcweb@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d043439465c0c7d04fd636c84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I made this change in the current draft at:

=

Note that the TLS WG is currently discussing whet= her to bring ECC onto Standards Track.
If they do, we probably wa= nt ot require support of ECDHE. We should discuss in YYZ.



O= n Fri, Jul 4, 2014 at 3:23 AM, DRAGE, Keith (Keith) <<= a href=3D"mailto:keith.drage@alcatel-lucent.com" target=3D"_blank">keith.dr= age@alcatel-lucent.com> wrote:
This is the direction I am tending in as wel= l.

Although what or if the second statement needs from RFC 2119 language would= need to be debated.

Obviously, new versions are not being put out there just to make it look li= ke the WG is performing. In any referencing (not just this issue), I would = need a good technical reason why the latest version cannot be made the norm= ative reference. I am not seeing that at the moment.

There is always be non-conforming equipment on the market (as an example lo= ok at the number of SIP implementations that still use UDP for large messag= es, or that can at least be configured that way). Just because we mandate 1= .2 does not mean that everyone will conform from day 1, but at least a mark= er is established for what should be addressed if interoperability issues a= re identified.

Keith

> -----Original Message-----
> From: rtcweb [mailto:rtcweb= -bounces@ietf.org] On Behalf Of
> Harald Alvestrand
> Sent: 04 July 2014 09:07
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] DTLS version
>
> On 07/03/2014 07:58 PM, = Martin Thomson wrote:
> > On 3 July 2014 01:39, DRAGE, Keith (Keith)
> > <keith.drage= @alcatel-lucent.com> wrote:
> >> Can someone elaborate what this massive apparent step
> change is from 1.0 to 1.2?
> > Actually, it's not a massive step. =C2=A0TLS 1.2 (DTLS 1.2 > depends on this,
> > DTLS 1.0 depends on TLS 1.1) adds AEAD modes, but doesn't req= uire
> > their use, so you can pretty much just bump the version number an= d
> > advertise 1.2. =C2=A0That's exactly what we did with NSS, tho= ugh NSS
> > already supports TLS 1.2.
> >
> > That said, I agree with Jim about 1.0. =C2=A0There's enough 1= .0
> out there
> > now to make mandating 1.2 - as much as I might prefer that
> - a little
> > too aggressive.
> >
> >> Will those implementations that choose to stay with 1.0
> still interwork with 1.2?
> > That depends. =C2=A0We could say "MUST NOT negotiate 1.0&quo= t;, which would
> > prevent that. =C2=A0I don't think that we're there.
>
> Sounds to me like MUST implement 1.2 (in order to move
> forward), MUST accept 1.0 (in order to not lose the long tail).
>
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--f46d043439465c0c7d04fd636c84-- From nobody Fri Jul 4 12:54:01 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7432B1B2C83; Fri, 4 Jul 2014 12:53:57 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpjivmvXFkqr; Fri, 4 Jul 2014 12:53:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47CE41B2AEE; Fri, 4 Jul 2014 12:53:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704195354.9574.18912.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 12:53:54 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Rn00qqixq0n1LlvsxjvUpJgZ7X4 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-arch-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-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, 04 Jul 2014 19:53:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : WebRTC Security Architecture Author : Eric Rescorla Filename : draft-ietf-rtcweb-security-arch-10.txt Pages : 45 Date : 2014-07-04 Abstract: The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for enabling real-time communications within user-agents using web technologies (commonly called "WebRTC"). This document defines the security architecture for WebRTC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-security-arch-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 13:52:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05151B2F37; Fri, 4 Jul 2014 13:52:27 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5wMlgBiTJ3H; Fri, 4 Jul 2014 13:52:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 284AE1B2A3D; Fri, 4 Jul 2014 13:52:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704205226.24397.55929.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 13:52:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ovuuWEuEVpk-iCbZj0SqW_0nclM Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-07.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-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, 04 Jul 2014 20:52:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Security Considerations for WebRTC Author : Eric Rescorla Filename : draft-ietf-rtcweb-security-07.txt Pages : 25 Date : 2014-07-04 Abstract: The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for real-time communications between Web browsers, generally called "WebRTC". The major use cases for WebRTC technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems (e.g., SIP-based soft phones) WebRTC communications are directly controlled by a Web server, which poses new security challenges. For instance, a Web browser might expose a JavaScript API which allows a server to place a video call. Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, capturing any activity which passed in front of their camera. This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-security-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-security-07 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 Jul 4 14:11:54 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39FB1B2DA8 for ; Fri, 4 Jul 2014 14:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1pQgE13D6Ha for ; Fri, 4 Jul 2014 14:11:44 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA4C61B2D43 for ; Fri, 4 Jul 2014 14:11:42 -0700 (PDT) Received: from [192.168.1.200] (p508F0AD6.dip0.t-ipconnect.de [80.143.10.214]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id AB5601C0B4620; Fri, 4 Jul 2014 23:11:40 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: Date: Fri, 4 Jul 2014 23:11:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9D7AEC5F-2955-4044-B8DE-A80006994AEB@lurchi.franken.de> References: <6355614E-44DA-4729-97C2-E903548EBA8B@gmail.com> <949EF20990823C4C85C18D59AA11AD8B1FC18D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <53B660BC.4090907@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8B1FD11D@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: Eric Rescorla X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/pHUtIjS7W2X6oZuNeIXpgpBE_Y4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS version X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Jul 2014 21:11:50 -0000 On 04 Jul 2014, at 21:48, Eric Rescorla wrote: > I made this change in the current draft at: >=20 > = https://github.com/rtcweb-wg/security-arch/commit/c2af2bf7fd032abd367dff8d= 4d16f7ec435fa663 If implementations MUST implement both DTLS 1.0 and 1.2, when will they = use 1.0? Wouldn't they always use DTLS 1.2? Best regards Michael >=20 > Note that the TLS WG is currently discussing whether to bring ECC onto = Standards Track. > If they do, we probably want ot require support of ECDHE. We should = discuss in YYZ. >=20 >=20 >=20 > On Fri, Jul 4, 2014 at 3:23 AM, DRAGE, Keith (Keith) = wrote: > This is the direction I am tending in as well. >=20 > Although what or if the second statement needs from RFC 2119 language = would need to be debated. >=20 > Obviously, new versions are not being put out there just to make it = look like the WG is performing. In any referencing (not just this = issue), I would need a good technical reason why the latest version = cannot be made the normative reference. I am not seeing that at the = moment. >=20 > There is always be non-conforming equipment on the market (as an = example look at the number of SIP implementations that still use UDP for = large messages, or that can at least be configured that way). Just = because we mandate 1.2 does not mean that everyone will conform from day = 1, but at least a marker is established for what should be addressed if = interoperability issues are identified. >=20 > Keith >=20 > > -----Original Message----- > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of > > Harald Alvestrand > > Sent: 04 July 2014 09:07 > > To: rtcweb@ietf.org > > Subject: Re: [rtcweb] DTLS version > > > > On 07/03/2014 07:58 PM, Martin Thomson wrote: > > > On 3 July 2014 01:39, DRAGE, Keith (Keith) > > > wrote: > > >> Can someone elaborate what this massive apparent step > > change is from 1.0 to 1.2? > > > Actually, it's not a massive step. TLS 1.2 (DTLS 1.2 > > depends on this, > > > DTLS 1.0 depends on TLS 1.1) adds AEAD modes, but doesn't require > > > their use, so you can pretty much just bump the version number and > > > advertise 1.2. That's exactly what we did with NSS, though NSS > > > already supports TLS 1.2. > > > > > > That said, I agree with Jim about 1.0. There's enough 1.0 > > out there > > > now to make mandating 1.2 - as much as I might prefer that > > - a little > > > too aggressive. > > > > > >> Will those implementations that choose to stay with 1.0 > > still interwork with 1.2? > > > That depends. We could say "MUST NOT negotiate 1.0", which would > > > prevent that. I don't think that we're there. > > > > Sounds to me like MUST implement 1.2 (in order to move > > forward), MUST accept 1.0 (in order to not lose the long tail). > > > > > > > > _______________________________________________ > > > rtcweb mailing list > > > rtcweb@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Jul 4 14:20:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF721A0022 for ; Fri, 4 Jul 2014 14:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlCEqHZQ_z4o for ; Fri, 4 Jul 2014 14:20:39 -0700 (PDT) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8618B1A0031 for ; Fri, 4 Jul 2014 14:20:38 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id u56so2093028wes.21 for ; Fri, 04 Jul 2014 14:20:37 -0700 (PDT) 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:content-type; bh=3QRtDy7GrsxAabgJLpceA3p+fYDCM0Vbe0r0S8AeVOs=; b=j+297xUhvpoovQyMA9vrkcdmXUxj03onVoFDyDTwinSxRI8hN+rPUbTMhOrbwsAgN4 aiH2CzGGecQv8ByKn2A88HzQk9KRVR0lwHCAVH/2tc4dWukyTXu5PXNTL7KwSrOH19Hv cw+rw45/965ZFe6YAmHxJhnyHZd/qBD+ni4X8ABMQMu8lIbPMsBnnZ1kX9UpbaM2kMmO /5tBpjEQXGklksC0T7WffsrJyAlHlylcwpBDpsCIn8x2aOBgItxdsHByh9kpHvMapZRY 6knp2MfvezN/PsRf3h0P1Ak1v22je/HUqpmTxybhYPFdow5EXW60md6vkowdPgrAmMsu x42g== X-Gm-Message-State: ALoCoQnNcP4gSbf23mC6Lfc6rN01yIZS6IGHWJ5M93YaST/a8jrk3aw1xHi/A/KqKgsyuLDCpdP9 X-Received: by 10.180.81.72 with SMTP id y8mr20387334wix.7.1404508837148; Fri, 04 Jul 2014 14:20:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.57.202 with HTTP; Fri, 4 Jul 2014 14:19:56 -0700 (PDT) X-Originating-IP: [63.245.221.34] In-Reply-To: <9D7AEC5F-2955-4044-B8DE-A80006994AEB@lurchi.franken.de> References: <6355614E-44DA-4729-97C2-E903548EBA8B@gmail.com> <949EF20990823C4C85C18D59AA11AD8B1FC18D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <53B660BC.4090907@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8B1FD11D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <9D7AEC5F-2955-4044-B8DE-A80006994AEB@lurchi.franken.de> From: Eric Rescorla Date: Fri, 4 Jul 2014 14:19:56 -0700 Message-ID: To: Michael Tuexen Content-Type: multipart/alternative; boundary=f46d04428cf452956304fd64b266 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VFyG06tBS8vO0UOl0qQWdgmvhtw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS version X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Jul 2014 21:20:41 -0000 --f46d04428cf452956304fd64b266 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 4, 2014 at 2:11 PM, Michael Tuexen < Michael.Tuexen@lurchi.franken.de> wrote: > On 04 Jul 2014, at 21:48, Eric Rescorla wrote: > > > I made this change in the current draft at: > > > > > https://github.com/rtcweb-wg/security-arch/commit/c2af2bf7fd032abd367dff8d4d16f7ec435fa663 > If implementations MUST implement both DTLS 1.0 and 1.2, when will they > use 1.0? Wouldn't > they always use DTLS 1.2? > There are non-RTCWEB implementations of these protocols. -Ekr > Best regards > Michael > > > > Note that the TLS WG is currently discussing whether to bring ECC onto > Standards Track. > > If they do, we probably want ot require support of ECDHE. We should > discuss in YYZ. > > > > > > > > On Fri, Jul 4, 2014 at 3:23 AM, DRAGE, Keith (Keith) < > keith.drage@alcatel-lucent.com> wrote: > > This is the direction I am tending in as well. > > > > Although what or if the second statement needs from RFC 2119 language > would need to be debated. > > > > Obviously, new versions are not being put out there just to make it look > like the WG is performing. In any referencing (not just this issue), I > would need a good technical reason why the latest version cannot be made > the normative reference. I am not seeing that at the moment. > > > > There is always be non-conforming equipment on the market (as an example > look at the number of SIP implementations that still use UDP for large > messages, or that can at least be configured that way). Just because we > mandate 1.2 does not mean that everyone will conform from day 1, but at > least a marker is established for what should be addressed if > interoperability issues are identified. > > > > Keith > > > > > -----Original Message----- > > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of > > > Harald Alvestrand > > > Sent: 04 July 2014 09:07 > > > To: rtcweb@ietf.org > > > Subject: Re: [rtcweb] DTLS version > > > > > > On 07/03/2014 07:58 PM, Martin Thomson wrote: > > > > On 3 July 2014 01:39, DRAGE, Keith (Keith) > > > > wrote: > > > >> Can someone elaborate what this massive apparent step > > > change is from 1.0 to 1.2? > > > > Actually, it's not a massive step. TLS 1.2 (DTLS 1.2 > > > depends on this, > > > > DTLS 1.0 depends on TLS 1.1) adds AEAD modes, but doesn't require > > > > their use, so you can pretty much just bump the version number and > > > > advertise 1.2. That's exactly what we did with NSS, though NSS > > > > already supports TLS 1.2. > > > > > > > > That said, I agree with Jim about 1.0. There's enough 1.0 > > > out there > > > > now to make mandating 1.2 - as much as I might prefer that > > > - a little > > > > too aggressive. > > > > > > > >> Will those implementations that choose to stay with 1.0 > > > still interwork with 1.2? > > > > That depends. We could say "MUST NOT negotiate 1.0", which would > > > > prevent that. I don't think that we're there. > > > > > > Sounds to me like MUST implement 1.2 (in order to move > > > forward), MUST accept 1.0 (in order to not lose the long tail). > > > > > > > > > > > _______________________________________________ > > > > rtcweb mailing list > > > > rtcweb@ietf.org > > > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > _______________________________________________ > > > rtcweb mailing list > > > rtcweb@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > --f46d04428cf452956304fd64b266 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 4, 2014 at 2:11 PM, Michael Tuexen &l= t;Mic= hael.Tuexen@lurchi.franken.de> wrote:
On 04 Jul 2014, at 21:48, Er= ic Rescorla <ekr@rtfm.com> wrote:=

> I made this change in the current draft at:
>
> https://github.com/rtcwe= b-wg/security-arch/commit/c2af2bf7fd032abd367dff8d4d16f7ec435fa663
If implementations MUST implement both DTLS 1.0 and 1.2, when will th= ey use 1.0? Wouldn't
they always use DTLS 1.2?

There are non= -RTCWEB implementations of these protocols.

-Ekr
=C2=A0
Best regards
Michael
>
> Note that the TLS WG is currently discussing whether to bring ECC onto= Standards Track.
> If they do, we probably want ot require support of ECDHE. We should di= scuss in YYZ.
>
>
>
> On Fri, Jul 4, 2014 at 3:23 AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com>= wrote:
> This is the direction I am tending in as well.
>
> Although what or if the second statement needs from RFC 2119 language = would need to be debated.
>
> Obviously, new versions are not being put out there just to make it lo= ok like the WG is performing. In any referencing (not just this issue), I w= ould need a good technical reason why the latest version cannot be made the= normative reference. I am not seeing that at the moment.
>
> There is always be non-conforming equipment on the market (as an examp= le look at the number of SIP implementations that still use UDP for large m= essages, or that can at least be configured that way). Just because we mand= ate 1.2 does not mean that everyone will conform from day 1, but at least a= marker is established for what should be addressed if interoperability iss= ues are identified.
>
> Keith
>
> > -----Original Message-----
> > From: rtcweb [mailto:r= tcweb-bounces@ietf.org] On Behalf Of
> > Harald Alvestrand
> > Sent: 04 July 2014 09:07
> > To: rtcweb@ietf.org
> > Subject: Re: [rtcweb] DTLS version
> >
> > On 07/03/2014 07:58 PM, Martin Thomson wrote:
> > > On 3 July 2014 01:39, DRAGE, Keith (Keith)
> > > <keith.= drage@alcatel-lucent.com> wrote:
> > >> Can someone elaborate what this massive apparent step > > change is from 1.0 to 1.2?
> > > Actually, it's not a massive step. =C2=A0TLS 1.2 (DTLS 1= .2
> > depends on this,
> > > DTLS 1.0 depends on TLS 1.1) adds AEAD modes, but doesn'= t require
> > > their use, so you can pretty much just bump the version numb= er and
> > > advertise 1.2. =C2=A0That's exactly what we did with NSS= , though NSS
> > > already supports TLS 1.2.
> > >
> > > That said, I agree with Jim about 1.0. =C2=A0There's eno= ugh 1.0
> > out there
> > > now to make mandating 1.2 - as much as I might prefer that > > - a little
> > > too aggressive.
> > >
> > >> Will those implementations that choose to stay with 1.0<= br> > > still interwork with 1.2?
> > > That depends. =C2=A0We could say "MUST NOT negotiate 1.= 0", which would
> > > prevent that. =C2=A0I don't think that we're there.<= br> > >
> > Sounds to me like MUST implement 1.2 (in order to move
> > forward), MUST accept 1.0 (in order to not lose the long tail). > >
> > >
> > > _______________________________________________
> > > rtcweb mailing list
> > > rtcweb@ietf.org
> > > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--f46d04428cf452956304fd64b266-- From nobody Fri Jul 4 14:24:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8471A0035 for ; Fri, 4 Jul 2014 14:24:10 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XxYFznjKmiS for ; Fri, 4 Jul 2014 14:24:08 -0700 (PDT) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) (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 455B21A0033 for ; Fri, 4 Jul 2014 14:24:07 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTPS for ; Fri, 4 Jul 2014 23:24:14 +0200 (CEST) Received: from [192.168.2.41] (81-224-110-16-no227.business.telia.com [81.224.110.16]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-05-01.atm.binero.net (Postfix) with ESMTPA id 8CD743A175 for ; Fri, 4 Jul 2014 23:23:58 +0200 (CEST) Message-ID: <53B71B6E.2010604@omnitor.se> Date: Fri, 04 Jul 2014 23:23:58 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070808020601050509060600" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zposICoMx4u0EkwW07VQ5psRak0 Subject: Re: [rtcweb] WGLC for data channel drafts - missing descriptions of error situations X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Jul 2014 21:24:10 -0000 This is a multi-part message in MIME format. --------------070808020601050509060600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I cannot find that what happens in transmission error situations is described in any of these drafts. Both reliable and partially reliable transmission can fail, and the application designer need to know what happens. We discussed it earlier, and came to the conclusion that A failing reliable channel will tear down the connection and some indication will be provided if possible to the application. A failing partially reliable channel will enable transmission of next data item. ( I do not remember if the application will get any error indication or if it needs to have its own sequence checking if it is interested in knowing if there are no gaps. ) I suggest that a section on failure handling is added. I get the impression that it is in the data-channel draft it would be best suited. Regards Gunnar ------------------------------------------------------------------------ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se On 2014-06-10 20:52, Ted Hardie wrote: > Dear WG, > > This starts a working group last call for our core Data Channel drafts: > > draft-ietf-rtcweb-data-protocol-06.txt > draft-ietf-rtcweb-data-channel-10.txt > > Please review them in detail, especially for areas which may be of > concern to the broader IETF community. This WGLC will end on June 27, > 2014. > > Ted, Sean, Cullen > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------070808020601050509060600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I cannot find that what happens in transmission error situations is described in any of these drafts.

Both reliable and partially reliable transmission can fail, and the application designer need to know what happens.

We discussed it earlier, and came to the conclusion that
A failing reliable channel will tear down the connection and some indication will be provided if possible to the application.
A failing partially reliable channel will enable transmission of next data item. ( I do not remember if the application will get any error indication or if it needs to have its own sequence checking if it is interested in knowing if there are no gaps. )

I suggest that a section on failure handling is added. I get the impression that it is in the data-channel draft it would be best suited.

Regards

Gunnar
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
On 2014-06-10 20:52, Ted Hardie wrote:
Dear WG,

This starts a working group last call for our core Data Channel drafts:

draft-ietf-rtcweb-data-protocol-06.txt
draft-ietf-rtcweb-data-channel-10.txt

Please review them in detail, especially for areas which may be of concern to the broader IETF community.  This WGLC will end on June 27, 2014.

Ted, Sean, Cullen


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

--------------070808020601050509060600-- From nobody Fri Jul 4 14:28:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1E21A002D for ; Fri, 4 Jul 2014 14:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATKGNFMy8f3e for ; Fri, 4 Jul 2014 14:28:12 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04CDE1A000F for ; Fri, 4 Jul 2014 14:28:12 -0700 (PDT) Received: from [192.168.1.200] (p508F0AD6.dip0.t-ipconnect.de [80.143.10.214]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id EFCFB1C0B4620; Fri, 4 Jul 2014 23:28:09 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: Date: Fri, 4 Jul 2014 23:28:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6355614E-44DA-4729-97C2-E903548EBA8B@gmail.com> <949EF20990823C4C85C18D59AA11AD8B1FC18D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <53B660BC.4090907@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8B1FD11D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <9D7AEC5F-2955-4044-B8DE-A80006994AEB@lurchi.franken.de> To: Eric Rescorla X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QIiBm0LKgoxCUiztZZxA_3mijnY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS version X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Jul 2014 21:28:13 -0000 On 04 Jul 2014, at 23:19, Eric Rescorla wrote: >=20 >=20 >=20 > On Fri, Jul 4, 2014 at 2:11 PM, Michael Tuexen = wrote: > On 04 Jul 2014, at 21:48, Eric Rescorla wrote: >=20 > > I made this change in the current draft at: > > > > = https://github.com/rtcweb-wg/security-arch/commit/c2af2bf7fd032abd367dff8d= 4d16f7ec435fa663 > If implementations MUST implement both DTLS 1.0 and 1.2, when will = they use 1.0? Wouldn't > they always use DTLS 1.2? >=20 > There are non-RTCWEB implementations of these protocols. OK. Any suggested test for the SCTP over DTLS spec? It currently says = MUST be based on DTLS 1.0 (as you suggested). Best regards Michael >=20 > -Ekr > =20 > Best regards > Michael > > > > Note that the TLS WG is currently discussing whether to bring ECC = onto Standards Track. > > If they do, we probably want ot require support of ECDHE. We should = discuss in YYZ. > > > > > > > > On Fri, Jul 4, 2014 at 3:23 AM, DRAGE, Keith (Keith) = wrote: > > This is the direction I am tending in as well. > > > > Although what or if the second statement needs from RFC 2119 = language would need to be debated. > > > > Obviously, new versions are not being put out there just to make it = look like the WG is performing. In any referencing (not just this = issue), I would need a good technical reason why the latest version = cannot be made the normative reference. I am not seeing that at the = moment. > > > > There is always be non-conforming equipment on the market (as an = example look at the number of SIP implementations that still use UDP for = large messages, or that can at least be configured that way). Just = because we mandate 1.2 does not mean that everyone will conform from day = 1, but at least a marker is established for what should be addressed if = interoperability issues are identified. > > > > Keith > > > > > -----Original Message----- > > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of > > > Harald Alvestrand > > > Sent: 04 July 2014 09:07 > > > To: rtcweb@ietf.org > > > Subject: Re: [rtcweb] DTLS version > > > > > > On 07/03/2014 07:58 PM, Martin Thomson wrote: > > > > On 3 July 2014 01:39, DRAGE, Keith (Keith) > > > > wrote: > > > >> Can someone elaborate what this massive apparent step > > > change is from 1.0 to 1.2? > > > > Actually, it's not a massive step. TLS 1.2 (DTLS 1.2 > > > depends on this, > > > > DTLS 1.0 depends on TLS 1.1) adds AEAD modes, but doesn't = require > > > > their use, so you can pretty much just bump the version number = and > > > > advertise 1.2. That's exactly what we did with NSS, though NSS > > > > already supports TLS 1.2. > > > > > > > > That said, I agree with Jim about 1.0. There's enough 1.0 > > > out there > > > > now to make mandating 1.2 - as much as I might prefer that > > > - a little > > > > too aggressive. > > > > > > > >> Will those implementations that choose to stay with 1.0 > > > still interwork with 1.2? > > > > That depends. We could say "MUST NOT negotiate 1.0", which = would > > > > prevent that. I don't think that we're there. > > > > > > Sounds to me like MUST implement 1.2 (in order to move > > > forward), MUST accept 1.0 (in order to not lose the long tail). > > > > > > > > > > > _______________________________________________ > > > > rtcweb mailing list > > > > rtcweb@ietf.org > > > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > _______________________________________________ > > > rtcweb mailing list > > > rtcweb@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 From nobody Fri Jul 4 14:34:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788931A006D for ; Fri, 4 Jul 2014 14:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40mQcGVNIbJS for ; Fri, 4 Jul 2014 14:34:47 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C57001A0033 for ; Fri, 4 Jul 2014 14:34:46 -0700 (PDT) Received: from [192.168.1.200] (p508F0AD6.dip0.t-ipconnect.de [80.143.10.214]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id A6F681C0B4620; Fri, 4 Jul 2014 23:34:44 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <53B71B6E.2010604@omnitor.se> Date: Fri, 4 Jul 2014 23:34:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <470AD025-E40B-43BD-B141-599489FB892C@lurchi.franken.de> References: <53B71B6E.2010604@omnitor.se> To: Gunnar Hellstrom X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/J_uyw3e-ktqLXNOBkfqegj_wCH0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WGLC for data channel drafts - missing descriptions of error situations X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Jul 2014 21:34:48 -0000 On 04 Jul 2014, at 23:23, Gunnar Hellstrom = wrote: > I cannot find that what happens in transmission error situations is = described in any of these drafts. >=20 > Both reliable and partially reliable transmission can fail, and the = application designer need to know what happens. I don't understand the notion of "reliable and partially reliable = transmission can fail"... If a user message gets abandoned (so the stack gives up = transmitting/retransmitting it, but the association stays alive), I don't think it is signalled via the JS = API, but that might be an issue of W3C. If the association fails, all data channel fail. = This is signalled. However, this is something for the W3C document. >=20 > We discussed it earlier, and came to the conclusion that > A failing reliable channel will tear down the connection and some = indication will be provided if possible to the application. > A failing partially reliable channel will enable transmission of next = data item. ( I do not remember if the application will get any error = indication or if it needs to have its own sequence checking if it is = interested in knowing if there are no gaps. ) >=20 > I suggest that a section on failure handling is added. I get the = impression that it is in the data-channel draft it would be best suited. But this is about the API. So it should go into the W3C document. Best regards Michael >=20 > Regards >=20 > Gunnar > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > On 2014-06-10 20:52, Ted Hardie wrote: >> Dear WG, >>=20 >> This starts a working group last call for our core Data Channel = drafts: >>=20 >> draft-ietf-rtcweb-data-protocol-06.txt >> draft-ietf-rtcweb-data-channel-10.txt >>=20 >> Please review them in detail, especially for areas which may be of = concern to the broader IETF community. This WGLC will end on June 27, = 2014. >>=20 >> Ted, Sean, Cullen >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >>=20 >> 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 Fri Jul 4 15:29:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37C51A0123; Fri, 4 Jul 2014 15:29:20 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbHjppTxbE1b; Fri, 4 Jul 2014 15:29:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A63001A0027; Fri, 4 Jul 2014 15:29:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704222919.14425.70024.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 15:29:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_s6-FW3CVLLSI6PbUL14Q2ZBxyY Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-07.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-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, 04 Jul 2014 22:29:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Javascript Session Establishment Protocol Authors : Justin Uberti Cullen Jennings Eric Rescorla Filename : draft-ietf-rtcweb-jsep-07.txt Pages : 50 Date : 2014-07-04 Abstract: This document describes the mechanisms for allowing a Javascript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-07 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 Jul 4 18:26:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15371A00FE for ; Fri, 4 Jul 2014 18:26:42 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -5.834 X-Spam-Level: X-Spam-Status: No, score=-5.834 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNIhxH_YmTeg for ; Fri, 4 Jul 2014 18:26:40 -0700 (PDT) Received: from mailout4.samsung.com (mailout4.samsung.com [203.254.224.34]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A9A21A0011 for ; Fri, 4 Jul 2014 18:26:39 -0700 (PDT) Received: from epcpsbgr1.samsung.com (u141.gpu120.samsung.co.kr [203.254.230.141]) by mailout4.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N8700024TCDE680@mailout4.samsung.com> for rtcweb@ietf.org; Sat, 05 Jul 2014 10:26:37 +0900 (KST) Received: from epcpsbgx4.samsung.com ( [172.20.52.126]) by epcpsbgr1.samsung.com (EPCPMTA) with SMTP id 71.80.24374.C4457B35; Sat, 05 Jul 2014 10:26:37 +0900 (KST) X-AuditID: cbfee68d-b7fd46d000005f36-4e-53b7544ce5c9 Received: from epmailer03 ( [203.254.219.143]) by epcpsbgx4.samsung.com (EPCPMTA) with SMTP id 84.10.26169.C4457B35; Sat, 05 Jul 2014 10:26:36 +0900 (KST) Message-id: <94.10.26169.C4457B35@epcpsbgx4.samsung.com> Date: Sat, 05 Jul 2014 01:26:36 +0000 (GMT) From: Kiran Kumar Guduru To: public-webrtc@w3.org, rtcweb@ietf.org MIME-version: 1.0 X-MTR: 20140705012454956@kiran.guduru Msgkey: 20140705012454956@kiran.guduru X-EPLocale: en_US.windows-1252 X-Priority: 3 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML X-EPTrCode: X-EPTrName: X-MLAttribute: X-RootMTR: 20140705012454956@kiran.guduru X-ParentMTR: X-ArchiveUser: X-CPGSPASS: N MIME-version: 1.0 Content-type: multipart/related; boundary="=_NamoWEC-9ba1fakmai" X-Generator: Namo ActiveSquare 7 7.0.0.45 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJKsWRmVeSWpSXmKPExsWyRsSkTtc3ZHuwweR/bBZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr49D1ZvaCU9sZK+a+vc3WwHh6E2MXIyeHkIC6xIbV99hAbAkB E4lLNz+yQNhiEhfurQeKcwHVLGWU+Pz3BVADB1jRt5ZaiPgcRon36+aANfAKWEgcOryLFcRm EVCROHj7G9gCNqD6XyfWgNnCAuESG+7dB7NFBEwlzl7pYYM4Qkli7dWbrBBzBCVOznwCdYSq xJfuG2wQcTWJPYtfMkPE5SSWTL3MBGHzSsxof8oCE5/2dQ1UjbTE+VkbGGGeWfz9MVScX+LY 7R1MEL/wSjy5HwwzZvfmL9BwEJCYeuYgVKuWxPcV26HifBJrFr5lgRmz69RyZpje+1vmMqE7 n1nASeLl9RlQvZoSjxa1soDCTULgAIfEgzPLmCcwKs1C0oPOhumHsA0lvsx7zAhhK0pM6X7I DmHbSTx4tpAJU1xV4sqRa8wLGDlWMYqmFiQXFCelFxnqFSfmFpfmpesl5+duYgSmn9P/nvXu YLx9wPoQYxUw3iYyS4km5wPTV15JvKGxmZGFqYmpsZG5pRlVhJXEeZMeJgUJCaQnlqRmp6YW pBbFF5XmpBYfYmTi4JRqYGyYV3D45xr2jbs7WPRcG8yWKCb/EwnznGJZsnod1/bDxv+28t9/ vIn1VsFFtq0Lf2ZLa7Z2tkmpf5FuFi+vWzSB/XXour6zeu4bBBNUJ+Svsu1sPso77f1mYfUJ f7uaPzO6zmcs/7/l9Ol2LgbWhYVOTVmNG382ZMQ4CUwyuPDeyHX5gts7vimxFGckGmoxFxUn AgCqlI2RbAMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKJsWRmVeSWpSXmKPExsVy+t/tfl2fkO3BBg/+WVqs/dfO7sDosWTJ T6YAxqg0m4zUxJTUIoXUvOT8lMy8dFsl7+B453hTMwNDXUNLC3MlhbzE3FRbJRefAF23zByg qUoKZYk5pUChgMTiYiV9O5ui/NKSVIWM/OISW6VoQ3MjPSMDPVMjPUPTWCtDAwMjU6CahLSM Q9eb2QtObWesmPv2NlsD4+lNjF2MnBxCAuoSG1bfY+ti5OCQEDCR+NZSCxKWEBCTuHBvPVCY C6hkDqPE+3VzWEASLAIqEgdvfwPrZQOq/3ViDZgtLBAuseHefTBbRMBU4uyVHjaI+UoSa6/e ZAWxeQUEJU7OfMICsUBV4kv3DTaIuJrEnsUvmSHichJLpl5mgrB5JWa0P2WBiU/7ugaqRlri /KwNjDCHLv7+GCrOL3Hs9g4miF94JZ7cD4YZs3vzFzYIW0Bi6pmDUK1aEt9XbIeK80msWfiW BWbMrlPLmWF672+Zy4TufGYBJ4mX12dA9WpKPFrUyjKBUWYWkjJ0NkwLhG0o8WXeY0YIW1Fi SvdDdgjbTuLBs4VMmOKqEleOXGNewMixilE0tSC5oDgpvcJErzgxt7g0L10vOT93EyM4pT1b soOx4YL1IUYBDkYlHt6KE9uChVgTy4orcw8xqgDNebRh9QVGKZa8/LxUJRHetZ7bg4V4UxIr q1KL8uOLSnNSiw8xTmQExvJEZinR5HxgIs4riTc0NjE3NTa1MDA0NzejpbCSOO+CW0lBQgLp iSWp2ampBalFMEcxcXBKNTDKNs2wifuzTL4sderXvsgHqpIfO/I+bLg28Y+7Xld4YbPyA/vQ roQKn1IvsU4Nri1fnwhZvF3bpMflOGOWx3T7viPn/ot335iptDZextrRY2b3DE9t5fjup/NV VjRPshUvnfX+pnz8Rv1nk5Ted28y2T5jSd3alfGLT5w/kRO/6Ao3Z+Yb6xAlluKMREMt5qLi RACST+QP6AMAAA== DLP-Filter: Pass X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jbetvmZkjj3apMxXWptwt3U_VZ8 Subject: [rtcweb] Fwd: New Version Notification for draft-guduru-rtcweb-codec-preferences-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kiran.guduru@samsung.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: Sat, 05 Jul 2014 01:26:42 -0000 --=_NamoWEC-9ba1fakmai Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PHRpdGxlPlNhbXN1bmcgRW50ZXJwcmlzZSBQb3J0YWwgbXlTaW5nbGU8L3Rp dGxlPgo8bWV0YSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9d2luZG93cy0xMjUyIiBodHRw LWVxdWl2PSJDb250ZW50LVR5cGUiPgo8c3R5bGUgaWQ9Im15c2luZ2xlX3N0eWxlIiB0eXBlPSJ0 ZXh0L2NzcyI+UCB7CglNQVJHSU4tVE9QOiA1cHg7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJpYWw7 IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiA5cHQKfQpURCB7CglNQVJHSU4tVE9QOiA1 cHg7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJpYWw7IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1T SVpFOiA5cHQKfQpMSSB7CglNQVJHSU4tVE9QOiA1cHg7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJp YWw7IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiA5cHQKfQpCT0RZIHsKCUxJTkUtSEVJ R0hUOiAxLjQ7IE1BUkdJTjogMTBweDsgRk9OVC1GQU1JTFk6IEFyaWFsLCBhcmlhbDsgRk9OVC1T SVpFOiA5cHQKfQo8L3N0eWxlPgoKPG1ldGEgbmFtZT0iR0VORVJBVE9SIiBjb250ZW50PSJBY3Rp dmVTcXVhcmUiPgo8L2hlYWQ+PGJvZHk+CjxwPkhpLDwvcD4KPHA+QSBuZXcgdmVyc2lvbiBvZiBj b2RlYyBwcmVmZXJlbmNlcyBkcmFmdCBoYXMgYmVlbiBwdWJsaXNoZWQsIGJ5IG1vZGlmeWluZyBh cyBwZXIgdGhlIHJldmlldyBjb21tZW50cyByZWNlaXZlZC48L3A+CjxwPlBsZWFzZSByZXZpZXcg YW5kIGxldCBtZSBrbm93IHlvdXIgY29tbWVudHMuPC9wPgo8cD4mbmJzcDs8L3A+CjxwPlRoYW5r cyAmYW1wOyBSZWdhcmRzLDwvcD4KPHA+S2lyYW4uPC9wPgo8cD4mbmJzcDs8L3A+CjxwPi0tLS0t LS0gPGI+T3JpZ2luYWwgTWVzc2FnZTwvYj4gLS0tLS0tLTwvcD4KPHA+PGI+U2VuZGVyPC9iPiA6 IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyZsdDtpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcmZ3Q7 PC9wPgo8cD48Yj5EYXRlPC9iPiA6IEp1bCAwMiwgMjAxNCAxODoyOCAoR01UKzA5OjAwKTwvcD4K PHA+PGI+VGl0bGU8L2I+IDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1ndWR1 cnUtcnRjd2ViLWNvZGVjLXByZWZlcmVuY2VzLTAxLnR4dDwvcD4KPHA+Jm5ic3A7PC9wPjxicj5B IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZ3VkdXJ1LXJ0Y3dlYi1jb2RlYy1wcmVmZXJlbmNl cy0wMS50eHQ8YnI+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBLaXJhbiBLdW1h ciBHdWR1cnUgYW5kIHBvc3RlZCB0byB0aGU8YnI+SUVURiByZXBvc2l0b3J5Ljxicj48YnI+TmFt ZTogZHJhZnQtZ3VkdXJ1LXJ0Y3dlYi1jb2RlYy1wcmVmZXJlbmNlczxicj5SZXZpc2lvbjogMDE8 YnI+VGl0bGU6IFdlYlJUQyBDb2RlYyBQcmVmZXJlbmNlczxicj5Eb2N1bWVudCBkYXRlOiAyMDE0 LTA3LTAyPGJyPkdyb3VwOiBJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+UGFnZXM6IDc8YnI+VVJM OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO2h0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWd1ZHVydS1ydGN3ZWItY29kZWMtcHJlZmVyZW5jZXMtMDEudHh0PGJyPlN0YXR1czombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ3VkdXJ1LXJ0Y3dlYi1jb2RlYy1wcmVmZXJlbmNlcy88 YnI+SHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWd1ZHVydS1ydGN3ZWItY29kZWMtcHJlZmVyZW5jZXMt MDE8YnI+RGlmZjombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtZ3Vk dXJ1LXJ0Y3dlYi1jb2RlYy1wcmVmZXJlbmNlcy0wMTxicj48YnI+QWJzdHJhY3Q6PGJyPiZuYnNw OyZuYnNwOyBXZWJSVEMgc3BlY2lmaWVzIHRvIGltcGxlbWVudCBhIG1pbmltdW0gc2V0IG9mIHJl cXVpcmVkIGNvZGVjcyB0bzxicj4mbmJzcDsmbmJzcDsgZW5zdXJlIGd1YXJhbnRlZWQgaW50ZXJv cGVyYWJpbGl0eSBiZXR3ZWVuIFdlYlJUQyBwZWVycy4mbmJzcDsmbmJzcDtXZWJSVEM8YnI+Jm5i c3A7Jm5ic3A7IGFsbG93cyBicm93c2VyIGltcGxlbWVudGVycyB0byBzdXBwb3J0IHZlbmRvciBz cGVjaWZpYyBjb2RlY3MgYXBhcnQ8YnI+Jm5ic3A7Jm5ic3A7IGZyb20gbWFuZGF0b3J5IGNvZGVj cy4mbmJzcDsmbmJzcDtUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGUgd2F5IGZvcjxicj4mbmJz cDsmbmJzcDsgSmF2YVNjcmlwdCBhcHBsaWNhdGlvbnMgdG8gZ2l2ZSBwcmVmZXJlbmNlcyBmb3Ig bWVkaWEgY29kZWNzIGluPGJyPiZuYnNwOyZuYnNwOyBXZWJSVEMgY29udGV4dCBvdXQgb2YgdGhl IGF2YWlsYWJsZSBjb2RlY3MgaW4gYnJvd3NlciBmb3IgY3JlYXRpbmc8YnI+Jm5ic3A7Jm5ic3A7 IHRoZSBvZmZlciAvIGFuc3dlci48YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxicj48YnI+PGJyPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+dW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48YnI+ PGJyPlRoZSBJRVRGIFNlY3JldGFyaWF0PGJyPjxicj4KPHA+Jm5ic3A7PC9wPjwhLS1TUDpraXJh bi5ndWR1cnUtLT48IS0ta2lyYW4uZ3VkdXJ1OkVQLS0+CjxwPiZuYnNwOzwvcD4KPHRhYmxlIGlk PSJjb25maWRlbnRpYWxzaWduaW1nIj4KPHRib2R5Pgo8dHI+Cjx0ZCBOQU1PX0xPQ0s9IiI+Cjxw PjxpbWcgYm9yZGVyPSIwIiBzcmM9ImNpZDpCRUkwWFQ0Tlo1SkVAbmFtby5jby5rciI+PC9wPjwv dGQ+PC90cj48L3Rib2R5PjwvdGFibGU+PC9ib2R5PjwvaHRtbD48aW1nIHNyYz0naHR0cDovL2V4 dC5zYW1zdW5nLm5ldC9tYWlsY2hlY2svU2VlblRpbWVDaGVja2VyP2RvPTViMGY2N2FmOTA5MGRh MzUyNzU4NTU1MjI3MDVjOTc4YTZlZWMyM2JmZmQ2ZjgyMzUyY2NhYWE1ZTc4ZDc5MTdhNTg2YThj OTlkZmJmYmFiMGVkYmU2ODNjODUzZmU3MWRiOWZkZGRkYTMzZTgyY2JlNGEzOTE0MjRlNjJmY2Y2 Y2Y4NzhmOWEyNmNlMTVhMCcgYm9yZGVyPTAgd2lkdGg9MCBoZWlnaHQ9MCBzdHlsZT0nZGlzcGxh eTpub25lJz4= --=_NamoWEC-9ba1fakmai Content-Type: image/gif; name="201407050656727_QKNMBDIF.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhCAKQAMQAAAAAAP///8k6OspMTNRiYtt0dOSOjumiovLExPfZ2fvt7f/+/uvr69TU1Lm5 uYyMjG9vb0dHRzMzMyoqKgICAv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEA ABUALAAAAAAIApAAAAX/ICOOZGmeaKqubOu+cCzPdG3feK7vfO//uYBwSCwaj8ikcslsOp/QqHRK rVqv2Kx2y+16v1YReEwum8/otHrNbhcX8Lh8Tq/b73al2M3v+/+AgYKDVniGh4h1egyEjY6PkJGS k0OJlpd5SXsBDQ6engwNjFKilHoNSaVYqkisTK5CoUqdo02waLJMubGogg6Nt1S/a3IIeAoJmHAJ CnTIipq1EBETFBERDRHDUdqmSQ8PSd1GENzbR+NN6UPgqRPYr+Hrae1MDhFE94MUfA3hRvOKlHPC z8xAIXIG4EFQAJGBOQWMzWEIDckmIfqEBFR3zhuWgk82DhGJrmOAekcy/zJpR5IMSiUqA8T8A5LN yyc1l+QEU9MSxUMKD/2cs6iIyggQKExAxSCCtVoBmlKgIC/pBEZSIzBw8I/ryWr/hDSYRjUpvq9U ozpdGiBp2rZTyzUAO9BqLyHt3IZt22Cs03Jm0YbzS2HgA2sTfj0AixfxNqlsszLqtjgtuAfDMA+p BlgpqgdJh82d8ACpZ7VPiUA4HNlp2tVKHVT7NbewWKUR9kpNy4Azvt6F8SGdIBg1W71C7CY/rTru ycr/kiYlAm620+hxm4o9K5ax5Las+04gvTschL5kD8LFBmFCZ9twp8NlO6S21uJfE7dNygD6+kpx NGTAAQMQkIwCBAxggP+AySTw0AEJPmTAAAU4SIABBiQDIYUKDCVHUflwd81JgJWomlz8UMMABCay OFdyDzBAgXh3OTBjA1T1JsqNS5VG4lxbEVeaCEut1hQ+i/VHHDsPACkbEdrYuGNfFDggI41SXnml jVbyiGWV7CDZYjnaXDmXP+CcNWOY/ly12En3xeLiiKDtZ+dISOLDIicpCucmPuTlFkBiMu61J47g HZnoiFWK4KWPoDkppJuTKkmdVjomieiQ8uHl5o38DKkjW3Vu5gCOK5pIp1YuHpqiJzNeWV+VNjIi ao+shkoplPLE6OWVbyLlKI04bpPQAgU0dICAByiQLLLGUDSAMQMkkMD/tAgMoICzCChQLbIHeBgH iEMc9Ys+a8pIhBg2BiCoumsiqh8F/dUVVkYFaVPqaj6KIBsjvQCcGL0yCTcMfc8ByQmUnpzVTaj2 ZqTvQIntCw7F2/TLSLyvWgyOjEGG6O7BaBbB0rn4pFtTN/qw++pzBb8Y85KrrctIuwT7mHPKeNmr 8b8Lj7OU0HdFxUnF/7yMKJMFC1GQwA7sqV93GMmKKMtIhuPyyBKfw49KUHdzNckjDUYijKXKo5i9 AfQUh0IRLSBtM8tCK3dD3yazgEI/xd3ggOLCQS5GIqLc9lRTEWHfy2037jR4Lx6G+L1qasQV4jlS E2N8TK01MOHuYp6x/3mFFR2lw7+EijlmqNej7+quP6b5xkN0DHuvNZdrsOU3ndw05isbvvjIMN9j I+LanPXS8AWhC3pBkk8V4+ych474PaIPARnSj49TUzv4GpcYkDXFBNLL+rQz/OmWE/H1Wdsb3332 3QkaPVUvUba64wi9bbe0cKBI3CgCobjt7W5wiNuECECAcDWEDoNrWvucJxYiTO1l8MLK19xTjnoU LXwj82BUQtGeqPiDXnsaGcH0MY6iqa8/BLNc1xonwq7FToSx0x4JiUMwdenrH58JB2jWpDviDYor e4EZ1vhnOsNdkHjgS14stqK8vTyxeTz7HV6AOMKxECcUh2mKaIxYtP8U/rB7w/heOMJnxl9wUGQy AVlU0Je1QSWNa6hznwTb6D0yKq5g/KpgPdQGs4XxLwDHGiDeAtgQRS6AGcs6wAH7hoBl0c2BFTnC RSRIPBaucUlOs1WKOigcIZ5lPKgAmqBA57goXcVdoNEaVU4pv2KxSFH9QthlaDmShrVvg5NhneVe VCxVYoY4xRpCzXxoSq69MjftkBEoQeejTSXRd56UyTSXmLOXRbFtnynHmkjjPlHCsi2lRKfjjLnM WQqhYr/BVVQQJrYq1QNiJ1GjBJUGptAUgV4gs9/u0heObuKxfbWTYD250sFQxfMuhLqHwnLzoiex 7JkFxQgi/efIAkj/ckHgWsCyEkCAZgxokg+MyAEegiBMQjAaRilc03DklHO0xz30okY1UEFTIjpF meOZJgi7cVNkIiZGQcWHjaiRG+BMY57UUM/HksqwGY5nRUFV6C+KutWstiWo26ApOXuKCqJm1XVJ bNl4wNS7WQrPGmDqZdNuyh/KrBFJ71jTYsZjqPHwR6z4GM07+FdUPs2Oqr2JKlTdkw/EQPOOvckr de76uKW+Y4072SuKnFJWwx0GNH7NqS+N+M7EnMWyTR3PTxPLWHYc9avjSc5sjFjYQV2FH4mMVkNI ysCGZCtZAiJAAQy0AAZS0lvDxVDgFhDBJpzKCH0xSi22ApUidAIK/9eNxXMxcpfsnsRW3NluSoqm BytxwiT5gIp342iErdyFutA1CcLGOwvylsu+0MVvfGsR3fyuq2i7sO5jxCtemXzQvutNCXbPUSrr vte8reCpfjUJYbF05ML2ha+F84Ff71I3HIh4RhysVQyJLKBDzZgDig3RXI9MYTGHQa+Ln+CXGdsY DIuR8Y2x0B+PiEAZQA6ykO/AJB0bYchITrIcFNAsJTs5yDvOgieiTGUt/BgTzLhElp9siS0X48R6 C7KXtZxiMSNgzGM2hIjn4OU1TyTMSXYzi1NRXezWeRBGhgkYaHNn66q3zyaUQp4DrQmeArrQTbgy HB5yCAMmwtFcbv+0if13AEkKudJAxnSQfwtpSN/hIct19HIN0EAlg/qBiDiCP0grhZtoQTNLWJFO qLATLYQqiSVhWBJm0oRaxxQmu3tCOXitSQYcS9KX8HSkM23pIGsaE89WRrQDNOk7BMUOyqZDtoF8 bUscwXeEaAkrk+BrJpT7CucuwjpIQmwstHvcUHhfoo29aAqJtECWJhBxC7DAZAyoQAcqAIfs1u9H ChxDzoJDwkccoQSSesQLGoAkLYShBBQgxRlS1sQbfm9+N4jj1xJusx+ZoH0T6OKPLJBHi8FASTpr 4P82EG9XqiEKEcAYG5p4xCVEIQedWOASt9syJKTvBBT95SjHULX/Ir5Se9+bQxOqEEsFnvSij0sy siGNaVqTGhY9JRtb7Q/pyDkfF1ZmbVWqTUOXovbupOUvZV9OpwqZNb7KvSDKGWJYq8GW3FhDI4ep HPjsXh53WWUyilHKXlrmGsw00ysjeY7d10NFvnCiHE7VE3rgHrqnKtMasuE8a3RD75SfWebaIqnR CYAsZT3kWXXD0AJkr9KLQ2j2BnBWQ4i7Ujk0sKV761YcstUsbWVrWxE5KUkPiOnfe9RbHZpWcZu1 8ptfa+SlrlvQq3/moMfh5seXPe2VdfGKR0T12Tp9t4xfLW9ZC1sCesjyRd1I8jurWeJ/fe6z9f5m ydzk14IAFJF//60nUqhmJ7c0J2KCgGQCAWJkI76SMFfxJEPyJK7VCUJyH+QRKEg1PeEwPvSyGP6g FRSYK5P1OEnSLpziUCHzJhbUTIXRFAXlgIJya0dUK4dCHCqyJ9pwJqhSRK7CQvyQOyg4gSyIFCxk ODxoMFkyIyuoOLQSK/TigzE0QsfSe7NXaYwmSR2lW3vTIHDDEJZmINqCQLJ3cwzHSAfEcovmUrUn Ug+hEJWGAKx3N1gIfnXIEMuXhUt2YtoHB5W2hye1DHnofin3PxoHLXdYSYwGOClFLQi0LXIThsPX SF4YN3lDiT8RFH7zc5LEN3gDhog4LhyjRIajMlCUJlIEDkBTVv//oEsUUzIWmISziA2vZCXZNChg xycnSEN3VE/npIs3gRU6k0opY4y+KDNWsjWr1DFsAzpbww/WsIsJdU/EsxVJ+DvgdVAj0w3qokc2 9IxWSGkDUI4SF21diEDXFoYGFBFBQRGq120/AUDF8EBz+IjFZTdyGC7mSCGaFhHZYo4RYY8jp2/P EhT3CIjN5iHrOIqYplKWplL96IaQCI8JInBCh0Dp2JCOtIYKVCClBopreEAdyVznY4q/gzmdhBQw JkSkcx7WMxWjwzuU1TRRgjlSVESuIZN9xDS+iEbzcz1t9Q5ZREHOw4rccTRwZUS2MzlFNDyJ4R7t okfWmA7ZaJT/TIg6PZlQNrQ/U3SFlqYh+TaKjlSG3gItBnRzZfgTF8JoAZSHi1SPCklJ01eG+/gT 27KIeNkhBMlwyUCPCSlSC/lA69cMZ+lID1lJEamYy4BA+ohAaEiSJiZAl0gthqmJD8SJlYRymCaS ZomZpKhBKElBQUMboAd6MANGQzNGPnlGtciN/nJalddCTNmLNtg4fUSby8MWWLlOPIOUVfNE3tgx XFRETzQNuUEN/1RISuNL3AQ67NONv/CNXNk6xfmV/kNSzeBRy0eHZHmJklQ3b3gtuKd79VZt37Jy 3TaJyWAgdAkhjLaPXwiH1xJ91KIhcdgMpfaWCRSXnamfI6ct/+63cuLphYm5fAGoneBCl55JN5So hulIoJbomJrZe8AnkhI6ioIjUKOZThZ1MDqYM2nyTlzxG1X4JtbkNK5IPHolTsOSPiZaL/lEHcN2 m/h0GHAyR2KXD0vCKOZRUD/6kwA1IwaFFDnagxhVRAYFYzaiHj9JQx0EAdnkI4LyVNGpLyYIjqgz UWGhaMVVUqTGQIuWIMaQjvBIIenZLQxUagiiIIS5npPIQM2wnnTIQKeWQMZwfXAgnyf3LfqGhn1a cy3ne3bKeggZniBZkHaacgKXDIjJhd0SpmgoqY4ZN8YVXBdSLfT3nYyaphSKp8jVll96po2qocxF VvlUGm9VU/9G9FMlBDOIpVNSFVQu6SlX9VWXw1n5gSI06FeLVRM09VPWyFr80BS+ehNBVUKI8UrL SjvtoFmwlRTZsFadBVtCpSehRSW+kkQ2ClUzog9LNSKClZXtIx05MR4zVFvYqXDClwCTJnyJsGJv Boh0Y49uKQfuegd6WG2WsGJGBwfEdWLwCmZ1MLB1IGfLEGbyiggGm692sLAkFmQLewgLW7EG+1Ia xgn4lbFOUGAF9hwfu2HlghUV1l/nxV35QGFLgGEwUQv0sg0vmwrdRV7olWCKM2FOwLGExgtLoBlL oz0Vpjgd4aXLhgcQQiA4F5mXsFxAhiALUodFG7VSO7VAFgj/rlZly6lHWCsMs+SkUUC0VDsHcxhA /IoI/+pkRtdkYbu2bNu2gTBlW4sE1xS3wnC1ULAJuxBgQgtdgIZEYJC3OGsEnxC0W6C3WsAKnTC4 h8azMPExXICNcFu4gdtegwYgIwZnbftIZXYMmMu5dUBiZbtpSztkz5Bmn7stnXuwqZsHm6ASxLZU ACFj17AYXhsGHWQenNRr16CrWzBsSbkF6TAN1XANk/tuXwFai9uz2xCut6oJtUsOudsEItgKezEH F5K5jwSpiDBtC4FqctCZTwandRAuIwlklEkH9wotTKtwDzJyLNa64fW7WwQFPjJPlduxSZluSAAS DZYF+msF//NgvL9Gbr1AhFNglSKCa3A0awe8SkbwEvg6XNibmMu2XNy7ttu2tN47B+K7vo55CSNU RNQEHaMxPdLDF150EAjzXP5BGEMUWGSBHWwBFhczjZjnFPfhd3HyONBZQtAha2qhlHKRHusxFkIM eKlRH3y3efAReFMjwilceJmHGjvcNqNQCt8hFVGaGLJhG3vVCyrBEiWkHIyhHFpcxHLBGUhcxYOi HW7XJJO3UQppABIRc+5qaZUUB/8omAnickD3UX8zc/wGcCSnIA7XQAdgccD1cwPXpiA1YirHhYV8 cS9HXCRlyODij3KKLFlIyC93jgxkcfVGXHZ8sBHCIJdcfv89R2oVV6dB53Ozd8mVtnGG7CAH9yHw W0SagkLn4SpcA1AJVQQycipLISU4glSdkCMhuCsiCA7FpCcm8nZ7wb/itIxSeCZnw4FNSCW+xIFt 0ysWpBjacM1nwiUDXCupwotGMiJ7kkLJQVHKNCa9wRWvxIFzsTmcVIOKwcw9siu3BILd7IHfHIwY UQ6vdESo4iKWW1xGx2iwVyGc2GyaJoclRZ6yR56KpADm53rTd3/Bx2TNIoAgRYADYp7ft36fGFIe VTe953yf6H+vl9IPjXskR1LFJ1IldXszjb7UZ4krx53YIqAAKXHo94gQkrYd3UD8Z4iCk8sjjIJa czOvMhP/mRUxleNMMEI0BNU46MJT0ji/tXMNO+U4FlMzFLUkxpNH7yMzOgPWFdQfOTkxJHrO8CPV VpyjqEijp4GKK1QyyhhsMmENOsXDWh1sS9HXXG2LeJFFL1EzNaOMO2q5y4cgeAqZhanHliafBySJ 2eKQ2ssQ3mmAa6hpqjefZ1mGdUOIbUiSEyfaqAuXHolzMu2FnE2JD2ogJZkQ9YqWrY1SeBrajvjb GreHK0WXTV0LrltHP7k+o1U70xXZwNlKo5UmorPV8naS0DPNnxDM9yNMRog8M/Q+GUFBLyE512BD /xDAp3UWzPM8KtleewI8hwQ+OElasuEJd5Evw8A+O1kl/zkh3utN1lb0DowVExAcQBRSqog5IN47 0YK5p5MMmhQM2oTpn2OY2f24hkPxE+BLUivnLL8XkOUYl3EDvo6UyrYtdAPphXTwjpbo4ZldqQJI kJREQC5F4ZV93Eqsy3fUDmQ31b+bDrFk1YQ93apaQdatjXMk4FqrtSJUKMSREbH5SwXzmtmtxMaI 3gglwhlxRc9TH+UCSqSJCs0ji3Vt3/Kr3ySajQtT5olt5W49F58gb3F04AuKACd14gpSkDHu4JEp 4Z8dEbB9qKIN4Y3p4pWokAf0l/yGuqS2l7H94KC5nymelqD9wcdGmYwehzL+E8GtvhoX2jiekSFc O71gP/89XlDmFJ1hjhXjcxU6MlSwggryFOt1JG8ceuXBrLXG5C7NGE7h/TsrquvapBFx7QlGdWEB ftc4WqUeOk1xVSeC8qGwdE/hhOZGAD2BJW/1K1rndN3D7tZE+DDDEk2o4D+q3ZECt7m919kOjtpw E56JWJaOmtKCWZ8BIkneuXKPvKftmdI3x5cnddr4Gekm7oXw/ph1g9G0DWf8boloCEA13n7uyXre MuOSXu90aQyl7ilMZSupHq2ixWvtcR2y5R6VJ91Zh/Ksxas+blqGtSbEfkg8bK2N0QuLwVlWBfN7 xaxubVvuAfPEw1V0ffJ/5Vgxfw42ElQAA1e0cVb/kPP/a9Iew8BrT7NWpumABJ7GsWVb6cP0TP5O d1En0PpZ7QCI3qstHZnakJwsmq0QYToh0bfIBLIsBrqmc6qQBGKO3SdwebqmDb6mKX1yDXQtwxWe wvUtminpoxj32vLoCoEgZOrZ+Ar4imhzknSpv72mjAb43TcgiC+nDMpcm+RetjC5FlY0NhtT6yVe HlZhOksKOkYLFlGylRuy6YVdAEaz+PWxrl+zFYb7SPD7KCuyUWH7VGCyJosJg7hkoZuw+ApnEctm z+8MZxYHCPtInSuvHRJm7rq5WgZn1z98q8tkKrb98DqxI/auZeawy/D8ktTxjSDAdFv/9n8EhkBq 4I+9//wPAos4kqV5oql4KKr7wqlyLAHDBLm+873/A4M5xkNoPCKTyiWz6XxCo9Kd65CIYbPaLbfr /YJdNkZYlGiV0yTEtYSInU8JBLocV8feWb25ruKLAOJxCboUqtxxJZosdi3GCR6eFNo05DQ44EA5 TD01aB4xWOrcpB3QDJYZEKAuHLwNxBQUKgwUtH0l0MymjryexGYFr7Se/A6LIPcKwxxn8cYYlECT /FJ7nVbTKMcqSKso1zhE2FBEjD5RdDo9FCGN75Quz2td84bvFZgWL1974ae4R2+gCH+pAE57Y3BL NhP4EOgDZyIAPHhS1K3L6MPiEDK+BhC4oqCArRYGDv+AnIMKwaldKAu0eGkA14IEBAZ8K7DKFyp9 NkvWvPltxE9pKEOuSIkTaNESM0/d3IVzgYGUrqoiOAkSwc03I0G+IsBqJlWrUFk5ZSq04EtXKX8i 1XcWVVWkZatqW1DgZZ2jCZbC1Ot2ajWrXwNrJcB1wJvEixUS08tXcNnAcHWl1HfYpF8SM7/aTTq1 6q1VBsj69bs34kgSe20V3Fn3yoECYmlkW5pT72ird8NRJBeBAoQh5GyQazCBeI7j7XYQN4dDOYUJ DR5wCoA9AITq6LR3d0C9OMUJE9x1t679QQRNED4Nb29jOYTjHYmGPECAqrTTevef9hdbubn0lwII MEb/AisKoMVYX6jEspdkCywo4QgLVsiCCCOxMIBLFLJgYUEsEXDgfvrpApN+rgRWgD62zaCPfwIG OIt+M5xYIoLVwKQTiAxuU+BeQLK4QCw37libiSx6gwyBE244pIcTxjLAGaHZpAuA/Unj4n8x6vVi ibUZGdmUEh7ZozRoKSklf296SeYINso1lJFXJvAXAggqMBIb+ZU45CxIHWAnThwaSYeSKyJ54jYG IHpkfjBxxSReJQSnnXo5qPdAcecxcF4AGD2nAwVFRFCEqOx5yul1EzDgwAQ7sIcDqKkGMIEDDlBA RHuyrgdBEcpxVxwExhYXgX1j+PLNNlcIaGEsitUy/8M2xBQqgmL4BaKPMg1FSAO0+y0AEbflvgiI QK5YQa65c7IEIbpQ5tfTG9mY22e5R+6SFSqKgeuaV392Wya7er0hEpn8JkNvArwIyJPBDY048bVW 1lSNs3fWFOG9NJjLC77emlkyLwcu0AKYAmEc7RvvjkimviO03PC7Nm7Myyz+bUvzFeYGYyHA8ub2 M8kh//twwsBVtOyxue46a6akupMD1TbYUKs6wArrqg7PARscsRQFgGuu12FHTqsUWMKAOr1qt6w8 B9NcNzRHniTXtew2RM27QJcQsE1oITiA4RHNO689sBBT+OECBxyyHjbae7C5P5F08CzQUN4wvCP8 Tf+y5vfe5CXDZZJkOGN35xUMxQhbXKZ+17w+jMeWp4t77K5fSztIXrJs98uIIzzSgtUQwPrN8QqM cJbcFBz05MzLvjfgIau+uh5Mk8NRAMo1sPVx8Fxtag7PPVCdsme3OhwF72e3HkXvvx+B9+7D347b ZXNC//uj5sB7c2vINlR2uzL95SQH4122KMSHSs3rW/IymgHeNbNyuSt3n+OdBf3QuTJJTlvUExnI 9NEzhm1OD0PzXMXmAEHAja4WRqtew6BxBdZJjHfN02EszlCbVhDQSAaE3ciIWMLdmSxhf5ohy4bI C5gVTwEJ2AlRYnSt5QVRZ28ggH9IEAwYQmOFNPz/4tE0eMPtTaRpPJjA08JGvvNVDYDrAV+mjqUr /l2CVkWwyA0skgn75fE5qYIbRr4nRwF6JCgYnBCZfCSnm5SMXQZCECAwhqbASWNH2wIabQx1w37t 0EydhJy8zEUmAfXtYxGMCQpZ4pPTOcko0rDk3rIxCwiajm5pStkAZmAUJ9WyGOsqWomo0gqbLFJC jVRlCItISyRmq1C4zF24ivRE4u2MBrXAD2dAGJFZILNSWiyLIKakQNe9UpcL/FAsTKmZXkazG7jI lPe4Q4HssK1sRcin2awGx7CtTzlSY085QFGqfK7tBmwjqNuIUIQHTOA4uAIWruoTj0RSpSsdI8kN /8ViFznlJjJH6VkgQFJMZfzFRUeyxbZegjHQmbQF11jFjg7mUpp8sJ2a8ShuKlfEVXDRSiipDR14 qs4RMIij+xJLC3RIU9twcT+wTBlUpZFUSOYwMiOgKQ8zahuarCJBKbUkM3P3U7FccoEpSx7GPCob xfTQFmRN3IhSipatJg8pYlleRhP01JeFg6Un3ZBRA5abvDa1Y5Cq6lpto9MR0HNZ8/uaeWDFHfP0 U47PqSwEpGYO45iHPHA8nzkQGlrknPY54XNH+IbDCYFG9KJuqMOB0HDLOigwBbrQFk1qIokNAaK2 SKUDI35brt4C1w95QC4iaJKnNTC3BMI1g3HZcP9cGFgXdISIbrkOQdzkeuG5LphuufyQ3ZR99wUH Qu6ehqvcQNThvA30Isomwd3hFjcQNJGEEFqlA0zsoAHfAUImgiCeIMQKFALewYERXOAhDJhZsgDE Kt5LgloYwDYE2TCHO+zhD4M4xK4gad1EPBEgQDR+GllxJ+b2Ag354r4bOoWFTWzjG+M4xzouQ3tN wA8bG1jFLB4yFG7QA1HEI8JENoKQEaxkIHxiyQaWsg+Q/L0m88DKQ9ayk5fMCS4nAcwQ3ggUFkyK J1P5yGhWsxKw/AQkRxkJYjaCkXVQHO/VM81AKGQQ7ixZIQBSzzzgM5X9PL8/2zlTRM7zRhC9DnX/ lGoJkdajDwg9BNFWuTiTnrSgG01nTcfRCJbehHCwjGkdMFoIdfZnqjsdhVG7egmwHjKfOT1oRQ+5 1Qx2dEZsfQRf+3rUuoaHr2P9BF3rWdfC5jUQVt0d+0WUOQ3QNH14ANE7jqc56UuVeXAwSG5b1jmo 2ra3kcMcTUnn2dM2t3yE5Z0dvGfawzk1RE/1vc4eqzuiqPa02diDb/vTnpvqjrSXI596x1He50a4 Pc/xHvOUygFVe7as5n2+5cSRAcNRj8alw530cZw+yal22TqLavPYWz5lA0XH2w1yWd3ze8tRj9oS PnNLfHs66kv4zmV+boykxxIYF/h3MM6eoT+H/+AZtzi6h1WfUz373sPx1GfXzR0BP70466YOet73 qVOpluQ53wE53K2r5XDC7DD/cnxwECrilN0S6Uv3Zxk+DokHMNRVVvA9eWUJtpGvf+hw26ty9QCN 7/Pw/sbVqUKVrH2ONuWQP1aoMsHPB4RvV2VHVtnUtiz7+Z3wpGAb+HjlbQjYSvHY6RUoTIV6xmuK CLOqVagagKtUEZ6OAWQb4d0mHutkfhwMOFb4tP3fvueT96TfVNzAU6znr4+gwtI4OW61zwfPD/PW 6drYcvC0p60vArAi6B0JCuk4lp8ckoea29BveVUdHvYQlb2mXkV/ykocVsBqh3JiJTXvo56u+P9e 6ZFe41mH361W7VkE6CkfJlSfePQK7VkHRKGN4SHeqIwbdHRe2YyfcAhHBz7f98VfqTWUPmVe7h3g OWBEZv3AqgHQAmreqFjCd/iX9p2P+jUHJzzHCuog5MnP1bwNDhzYDMIe+cygOgDS/cQgHp0PeQgL DMpcE6ZaPr1RoHGczI3DsDjfx6GaREmcE0IesamK5bWe+OSgf3XNDY6BDJYDHpEPDrDH2LwRg0nN E87K05hK2yBhD2ZK25if/PxX1uDgHNVh1YyNsMghDlqhAzIh84mhP/GfZX0H3IgHGqZNwIHecfAg DHLiOUhNgU2Hrojh2PwhIPoTIIFNqcmPEbb/IdwQFCBNh/yBITwIINyoWhkqWiZqSqCNVgCNzyCi og8Go2b54A7KkZ1Vh6iYYSHtIa7xDxSSFv1cohv+4hT6IgDhzz11nHn8Hq7M3ftUDQyWijE+oqcQ lAaKo/9UjcaByqj4DzUekv34zyB2YeTpntW84zASW/3g4KbxIzFaRKQF5OrRjyL6TwxmY/w8IgAl HXFMIqWth0VsoibmYCdWpP3IzcaJYs350SBOWjOmIh6FpP+8zTUCUnooo3aoI7EJC7ORAi5a5Cew yte4A3Z8IjDyIQ/+YOTxJEZU4sGFofq5XTMqITQCoiVAoRth5A/4pCJmhyXgof0gZQQIC2vt/9oZ guEL1tz3EEeomSH/lMp33EC/HSPOccIc3t1xGBmhWUTX2NGt5ZE+euJUMqQhqscctsNA1mNEqiUO NKMhwUOgfcdCnt/3EIEtHtJ1zCJFPiNj6mJjXqQfDR956GJe3iQxaqBciuQe0ePfmaTEAWVd5hE8 hE8a3iI6euE49B8XXsKsAMvlydEw6uQO4lwxQh4gpUqrhEpQ6lPzJeHnLSEvyoq3TWOgXZ5FxJnV FEHXQJom2t5r3ZMAqma4haMX9l/taSUgLkfrZSf/rGY/dc3+TNSs/GZvWhRCFQdb8t5dnpsOjOdm BgdA9WM4Ss36AKHQxVE+KaPcpWfzKaDnzf8HOhDmepzjHeWgCcLKf2LiEm7irPieRbIe2wBS8G0l bJbPKfJhYGaocOwReS5nqelmSg6nPi0gJZ6mDnBjapZdRDHfZcXctVnWbAojH3ZWRNkmAMFWOYjf 06QoVw6HWTrjY/LiZZlHLmYHjMaKF0IHi/rlfOzoodkoRInfclbWVeJRjaJerujKVjbfGm3pgdbo //moqLRWzJUnbKlNtHkmHYaWJuRTgJUWJ2gmZ81KYaJoaNXpaMFoHO3pLiafk/pbaYbKkx5fVUKi 4mFWgFUpkaKeRF7kgmqp+AVnDF7bnZmDjbqNoSIpZpqPZmpmmb5WZZWacuzop8BKmCraOc7/WkfE A/b1wK5sBDoAmCes2SXET4KRAvbhahTMKpQ1WYNZTazE6n+pGCYomJvxQK/uKrzp3bKeWZPFymCi GZcZaxCYWRQOqxAAK4Gt2bUG2HdUKw8A66xuq60aWIT16pVtAnf6wLWm67siqxRE65kdma4WWLp6 n961ILsaW792mlf6KxB0Fr8GLJOxYMEibMIqbJoNrJwR7MJCbK9FrHbU6sR+j75abMZq7MbSSsW+ JMeCbMiK7MiSbMmaLBO44Mmq7MqybMu67MvK68PC7MzSbM3a7M0qbMri7M7ybM/67M+irMwC7dAS bdEarcrq7NEq7dIybdMWbNI6bdRK7dRS/+2bCW3VYm3Wam3U6qwE7IDXAgHYBoHXiq0EmO3X8oDZ qq3YCkHZrq0OgO3anm0AsK0P1C3coi3czm0OxO3b8u3Xym3Y7q3bsu3dBu7fhm3b9oDh6q3a4i3d +i3d8u3bxm3aPq7kjm3aRu7dQm7hNm7eJm7nDq4TRK7dYi7g+i3hgu7lli3qHu7klm4SOC7r7u3p /gDnrqHlPu7rGu7ski3inq7n6m7jUu7wIi7n4u7k3i7otu7xsu7lQu/z2u7iZi7wzq71bu7iym3t Tm/vXm/wAq/10m7g1m3zTm/wpq70gq/zii/1Gu/Ytm7ysu/yDq/50u/5Iu/2yu/+ou7qXv+U+4Zv ++Zt5VauAOPv/XYv7Bbw+w4w9ZrvAwtw4b5u/f6t/gaw5vqu+kIwA5evAgOw8IouBg9u7YJwBH/w 7hLvBmOuCvsv+m4v+/6u6a6w6GawCE+w/kpw7Oou4aavBa/vD2cZd8Zw5zKv+xKwCbsu966u5wrv C58v5AIu2qpw8z6wElfvDFdw/wIwFv8wD3vvDdtuB0MvFVPwBZdwF39w+iLx+rJwCn8vF2PxEFsu BOdwEYev/C7BAmfx58qwC1tx7rYv45qxB6tu9MquHQNxGDMBGSPxBuOwFV/vAtuv/0qyBhuy4hpw 345uAYtxIityEl/y9xYy9kayAk/yII//8e46Lu6Wbymjchc/Mg1PcANbMuwi8imzagDL8SfT8i5P wRDrMRzzMhJ0cB2rsitHQSWbsSBPsfoegRj3rRHjbTDz7hxf8hZfcR+38TNvMQhzMv6+sDKDMzLf cRPgcCOPLxrvXR638Dd7cSTHsjVf8O2esw3PcgszMPP6cBKf7Sg/sQw3synbsw4XLDALLh6Trgbv Mz9zb+m6MzHz8TwbQT3L8h8bsiivsRfvqz2/LzPvMQJD9PyaMh6TNDdnMzbnczmH7kpntDOj9Ehz dExrb+wyMumCcRl7Mj7rtC47L0JL9DwLMku/9E5rcy3/swsyc1AT70dT9D9T8jAbcEgT/7VTU3VT Gy8uw+9M6zM5v3RQK7VSv3Ix260Tc7AbjzAyW/VQL/M093Fbwy9ZV/Q7W/QykzVGR/RRtx5Yp7QU X3NfY3JYL7Ja/3RVK4E3F/ZgIzb/ovQpn/EB7/VP+/JFS/YV+/Qjk208y/Nj+7RjD3Zlx7NeTzXu MkAL8PNf/3VTp7Vbw3Vqt/NCU/RrLzRlx7by6u1JCzYrzzJcw/RYEzQHnzVvi/Js169wa0T+1rVw o/Y+s/Zb33NotyBpb210S/d0G+1o1wB1Y3d2azfMWvd2e/d3gzfHdnd4k3d5m3esjfd5q/d6s/cU jLcTa/Lo3rJAQzZV+/Vmi/BEV+9X2/92URuBAAC4AOgAgA94gBd4EBB4AAS4gSu4gB9Bgjd4gUM4 hPsAhR84ECx4hu9Ahlu4Eiz4hROxX/P2Ejc3Udv1Y9+3UI9zidc356Y3LUtxQ7u05AY3W/fvKtM3 Z4v4Uusyjuu4P39xP+94gnN4DhC5gx+5kSP5kit5kz+4g0d4lCd5g394lEs4g/dAh284lDt5lnO4 loO4Nsd2QO+0RW+zjBtx9tKzbv/4VcdvlUE3DJ8wQ89tNct5JzP2ZG/14TbxVb8yF+c5TmM4k0v5 klf5lCM6of83lCd6lW95l2M5lXu5EHw5pQv4hFc6gfuwYhu1LIcuK7u0HiMvUKu4Xp//MSNH9osb NA1HryNjMArTOE579UzntkqL9CeLtQdHNWdb9ZEfOqEnupMH+6L7OoNP+aNbuYd/OZczAYFbuKM7 umbLeh5L8JyjbxQ/cTBD9myjdhkf8ZHFefe+8bhL76gfr4/Xsp238xKncgLzeCCvsZ4jAbQzOpYX e6MbO7P/wK9feZgLu6Ev+xIse6TzgLNz+bCHeGdr9TET90STsEnvsFuD9GGH8LkLObhftwVru7i7 MnzD+i5XMSQ/vJ+PMVf3OU+Lc5BHtsDrO7Ij/BMkOZh3OaS3vMwPvMwjeMAXupOHPCL395DFdzgD 9Ij/vGV/NBsfPSmEe5qrcSc89Hxn/zut0/QbqzaMn3ZfUzFmTwHCD7ylbznOV3i9X7mGN7vO57yX Y3q873rbjrnWJ/PQD7XRT7wco/oTv/htL3Zpf7y7I70WT/xU8zSsu3GnC/q8F7m/DzvOg/2+iz2y z7zitzyVR3vYLzo77/rGr72J67etC74tc/w64Hm5J30uK7zD13U3v/mNX7zHqzglC73eNzaQD7R8 e73jd73kH/vtJ7u/F7zOEzymV/qk277ZDzraH37C6/j95jCL2zcQ1zPrQ79gOzM0Y3us80DK5PXP l/WfZ7b2c7zGu73mQzVhb37z737aOz7lz7zw9/7Zpz/7L/76oz+x+z6z43zQ3/Pvrv/6IWcuCEiB KAajiZ7pWq5o2b7uHM9unZLuojC5BAy2hMIbEfgr2mRLpg3XjD6lqhcxCr1ZjzOB9ytIgcdNL2oM Npm76HWg7Waf4ba2mE51wcPLbN8Jc+RXRQNoIjiY2CdoxPXXhMPjk0dZaXmJmam5ydnp+QkaKjpK Wmp6KiWJusra6voKGys7S1tLqmqbq7vL2+v7CxwcgCtcbHyMnKy8fNvD/AwdLT1NDUssFZQzckW4 nX2YOeQ4pEU5uKXdXYW4sqeG9sZnmpYXd2f/jh9v1x6mL/evnrx3ZQYKzBSHXz55awLe+0JwIUQ2 bszAizenosF9F+vwucbuD5SRLMD/lTz0TV0NcY7QKVFXbh3KloXu9ItoMyM9jmQeWpyYZg/DhhDJ 7Izy0+jGORwxSjyqBw9TnDp7OqWicapWOVcPOrWHjyhVnku3LiGK55pJlkp0xEzXtlwMGHJT4ljp JO8UkyrubuFmVuzNsQH1afyJMyvGpAMZF6QatOziogYRI62M2ezXjQ4HXwXrz45gShdBR306mHFk rJkjqu1bci4jlYQCjYMbO503wHzvzja09vc5skA5U04tNWdT5YoRH3V8NnQ/ywCP2+xM3PTYzVEV ek7Y0ePTiVw/h5862vzjy6ddOzs5FzjfbuTWysUtf7hu/TSQ6O0fEmsPBcYHduNp/6feZFYRt153 UPm04GSV/KNYTgY2aBpoFU7YmGTRVaiaTgS6o9UaPCiwwF9x9aZbbfDN15tdetFlzm/GiNahVRce ViB59MAD3WZhCUUQdaetdqBkQg2FVo7nCdTkktwtx1prnCSFXEQXTtcjCgygWFMS2iDC30y8vbUX mVmsRCYLjKhp5kvZkdeeFCQOSKWWxRUZWnN0kiZdYX1KV+eVe0bHpXcLbSced1LaOaiihuqJyY/y fJkimpeMdCaMe0ES5iOe+IUNopBeImiTN4nF6qCJ/VmVn12tap1nBSnUaoOodgmejl3OasmWDvZE omBD4srrpWBqGpJ+pLa4WzZ4Uf8x3LOQ2OhpgIUyumujjqkqYj6L9rpUhkNNGSuhtgLLFbm6cqsc lQjulF6V65qqWYk+GpdluAFgGic3pDqrBZyfenqwigJTy/BJXsWb6JJPcrloow5SVK6VTNVLa5JG 4luex792S5iHHD8G3sPwOjTkvcoBTO1s2iqsCZs0/RfzzdGm9N/MEM/JypYsK1mWpNd5+HPI77p8 mdGFOo1echlNDfSwD+ar2Z3lwVxN115/DXbY0XAtdtlmn4122qSQrXbbbr8Nd9psx0133XbfLczc eO/Nd99+r71stAjjDG3CMOU2U+GFv6mwf40j7NuKKs7Y6X4z7uf44SesCRPPirj/ia3DNeqs+Hyc s1R6zz6nrjl8L30uKi1cDxwmYM6GHheNMiVOuIvZJuybpprzZq3D9eWl+/HbyGAbXc/WZzuoB7Ml p/Cmx05C7tLzPnj38Qn+O4vGQz55964wMEn4JJFfquj2bS4+bPG/Ja31zb+ouB/KF5+E49+4Jb/d yQ+A9nkeOuRTsOltr2Dr856Y4pO9hcVPf4f7nuXGFxy78AyBvTtf+sCnuwu67wm4K+AET1iI462O gOIAh/8kSD/QbRCDLoJefkyIGwP+bobzQ94CrfAD0Z0OgQSMCfU+1UDahG9362tgEmeBvhh2Dmdl cuBu1pG55KkOiE8UYRd9WJfM/1kieuLTYhnr17/OZTFOWwxii2A3xvwxgRxFQN0Ns8UmIRqxEf6D 0f9qFyoopo9xU4ScGH+InyIisYMAstG0mnczC6LEep3Aix3L6ELLVbGQcVReD3f2OgFS0Ydm9IYA N5lJPy4OEM1inxpRGYooNoyGrAtY9WgEwFZ+EpSwpKQMK3et1dkSjnuEjQUVyUs/ilFNdOwZI6fg yVI185Ss3CAzmXc5Z+5SeNFsXStkqT7QUa6XNXGe9FSYhy8ukHQj3FnsKkFMDJrzevwJYQedGM5G hvJ9v/zjNNGJQsMxEVo6FCU/uWezXIAzme7E4ori2chUMtSUVCwhIlf5TCWiie1TLYGoG+FHn1cK jAvxtKQv04Q4ac7RoW9c4ztDGghm7ZOhtwnYQWGxUP7V0p7tVKn5AvnTzVHwpZIkKvCAyroqIhOk PX1pLefYpvYJFKlMpeo903lRQDbVmzz1YP+qt1VvDhOrY3VqgLLIUeKdaYXA9B0fXyec0G01rWBN Klk54VFf5tV89cyqEeXKSHKCYqF/K6xhD4vYJRA2sYxtrGPrttjHSnaylPVaZCuL2cxqNm8f3Kxn PwtaQYZ2tKQtbSnQh9rUqna1rG2ta18L29jKdra0ra1tb4vb3Op2t7ztrW9/C9zgCne4xP1tCAAA Ow== --=_NamoWEC-9ba1fakmai-- From nobody Fri Jul 4 23:14:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D621A017A for ; Fri, 4 Jul 2014 23:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyQAhTNmvovl for ; Fri, 4 Jul 2014 23:14:36 -0700 (PDT) Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) (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 6AA981A016A for ; Fri, 4 Jul 2014 23:14:35 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTPS; Sat, 5 Jul 2014 08:14:31 +0200 (CEST) Received: from [192.168.2.41] (81-224-110-16-no227.business.telia.com [81.224.110.16]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id 7E6673A235; Sat, 5 Jul 2014 08:14:25 +0200 (CEST) Message-ID: <53B797C1.3080609@omnitor.se> Date: Sat, 05 Jul 2014 08:14:25 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Michael Tuexen References: <53B71B6E.2010604@omnitor.se> <470AD025-E40B-43BD-B141-599489FB892C@lurchi.franken.de> In-Reply-To: <470AD025-E40B-43BD-B141-599489FB892C@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mCPBA0fg95TWknkLqJSoR0rRJL4 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WGLC for data channel drafts - missing descriptions of error situations X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Jul 2014 06:14:38 -0000 On 2014-07-04 23:34, Michael Tuexen wrote: > On 04 Jul 2014, at 23:23, Gunnar Hellstrom wrote: > >> I cannot find that what happens in transmission error situations is described in any of these drafts. >> >> Both reliable and partially reliable transmission can fail, and the application designer need to know what happens. > I don't understand the notion of "reliable and partially reliable transmission can fail"... > If a user message gets abandoned (so the stack gives up transmitting/retransmitting it, but > the association stays alive), I don't think it is signalled via the JS API, but that might > be an issue of W3C. If the association fails, all data channel fail. This is signalled. > However, this is something for the W3C document. The W3C mechanism makes use of the rtcweb-data-channel. The rtcweb-data-channel should tell what happens in error situations and if that is possible to be signaled to higher layers. The higher layers should have specified the requirements on the data-channel. If no requirements can be found, we should either propose behavior in error situations or request to get requirements stated from upper layers. >> We discussed it earlier, and came to the conclusion that >> A failing reliable channel will tear down the connection and some indication will be provided if possible to the application. >> A failing partially reliable channel will enable transmission of next data item. ( I do not remember if the application will get any error indication or if it needs to have its own sequence checking if it is interested in knowing if there are no gaps. ) >> >> I suggest that a section on failure handling is added. I get the impression that it is in the data-channel draft it would be best suited. > But this is about the API. So it should go into the W3C document. The API can only provide the functions provided by the mechanisms it has underneath. There was a mail discussion in webRTC about the error situations. A conclusion was that if a reliable channel reaches its retry limit ( that is usually only about 5 for WebRTC) or some other indication that the channel failed to convey the data, then the channel shall be broken (by the channel) and indications provided to both sides if possible. (another reasons mentioned was missed heartbeats for the whole association, setting a retry time limit of - what was it - - - 15 seconds?) If the retries or retransmission time is exceeded for a partially reliable channel, the conclusion was that communication can continue with next data item. I am not sure if the applications were to get any notification about that or if they need to introduce sequence number checking themselves if they are interested to know. I cannot see how we can avoid describing the mechanisms needed and what happens to the channel. I found a sentence about this in section 6.6 of the data-channel-11 draft. " If a message with an unsupported PPID is received or some error is detected by the receiver (for example, illegal ordering), the receiver SHOULD close the corresponding data channel." This paragraph could be extended to tell more about error situations in open channels. I suggest to move this sentence to a new section and add description of other situations. The sentence only tells about errors detected at the receiving end. But it can also be the transmitting end that detects the problem. It should be stated what shall be done then.T Something like this ( with my questions in paranthesis). -------------------------------------------------------Proposed error handling section in rtcweb-data-channel--------------------------------------------------------------------------- 6.7 Transmission failure and error handling Failures can occur when a data channel is open. If transmission in a reliable channel fails, the channel shall be closed by the party detecting the failure and an error indication provided. ( what does STCP do in this situation? ) If a watchdog times out, the channel shall be closed with an error indication. ( if this is part of the channel mechanisms, I have not seen where it is defined.) If retransmissions or transmission time is exceeded in a partially reliable channel, the transmission SHALL be allowed to continue with next data item. If reception out-of order is detected from an SCTP channel for which ordered transmission is requested, the receiver SHALL close the data channel. If a message with an unsupported PPID is received or some logical error is detected by the receiver, the receiver SHALL close the corresponding data channel. --------------------End of proposed section on failure handling--------------------------------------------------------------------------------------------------------------------------- Regards /Gunnar > > Best regards > Michael >> Regards >> >> Gunnar >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> On 2014-06-10 20:52, Ted Hardie wrote: >>> Dear WG, >>> >>> This starts a working group last call for our core Data Channel drafts: >>> >>> draft-ietf-rtcweb-data-protocol-06.txt >>> draft-ietf-rtcweb-data-channel-10.txt >>> >>> Please review them in detail, especially for areas which may be of concern to the broader IETF community. This WGLC will end on June 27, 2014. >>> >>> Ted, Sean, Cullen >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sat Jul 5 21:18:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036601A0195 for ; Sat, 5 Jul 2014 21:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 BPECHFjwt59p for ; Sat, 5 Jul 2014 21:18:17 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 121661A0190 for ; Sat, 5 Jul 2014 21:18:16 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id cc10so14325205wib.6 for ; Sat, 05 Jul 2014 21:18:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=M01vDCGP4eNRnNfZ8jrkvP84gLJnzWOSJX30wix5Q24=; b=i1Ga9PjJhuqM7UiZqsw3hsUDHFgCqI81MvyuPoR1e7hVWIsITIdfK6iHcrcEdUQgpd QH7ADuhmrEpKfa4JouSrvTPNd2aJwRaq6QM5BEBu8TkKbA7Xt9e7nm02/H07cL+i7Sch PY+o5A0D1Mv4PaEApqg/yuoudFwSzll//VzdhEv1LXcCo4TmIghxTTeOEbL8PgeeJzGV 5owucfTl9Bhx+KPHNTXcoeqgDEGQMn1Pz9cTodDRUKWGCmus+wW+k2kFXQIJ5RUu+p4O 8msiQ4z8XJ7msgozV1RJUQ7ipwRBNuwBVQQTmmi7Dtdg0Ki6+/c+dvmgQ4QXVZrSnJWX UZMA== X-Gm-Message-State: ALoCoQlxvsO6e/m3VBRdHPAoXeQmRlIVczVywcxnK72fuIc86BjRhWwZOC7+duvSCBxroTgh+R7V X-Received: by 10.180.13.47 with SMTP id e15mr68923074wic.28.1404620295658; Sat, 05 Jul 2014 21:18:15 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by mx.google.com with ESMTPSA id o9sm51756208wib.22.2014.07.05.21.18.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 05 Jul 2014 21:18:14 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u57so3025811wes.31 for ; Sat, 05 Jul 2014 21:18:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.37.42 with SMTP id v10mr27522890wij.43.1404620294054; Sat, 05 Jul 2014 21:18:14 -0700 (PDT) Received: by 10.217.131.17 with HTTP; Sat, 5 Jul 2014 21:18:14 -0700 (PDT) In-Reply-To: References: Date: Sun, 6 Jul 2014 00:18:14 -0400 Message-ID: From: Roman Shpount To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=e89a8f6473c7abec7504fd7ea506 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/CzWoN2WkQrAozRKNYK9OJ_bh73A Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about ICE-Lite server X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 04:18:19 -0000 --e89a8f6473c7abec7504fd7ea506 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable According to RFC 5245: "If its peer has a lite implementation, an agent MUST use a regular nomination algorithm." So, this whole problem cannot occur. _____________ Roman Shpount On Fri, Jul 4, 2014 at 9:15 AM, I=C3=B1aki Baz Castillo wro= te: > Hi, > > In case of aggressive ICE the controlling agent (let's say: the > client), and assuming the client has IPv4 and IPv6 and the ICE-Lite > server as well, the server will receive multiple STUN Requests with > USE-CANDIDATE and will decide which one to select based on computed > candidate-pair priorities (so both the client and server select the > same as they follow the same algorithm). > > Now my question is: let's assume that the server is just provided with > local ICE username and password, but knows nothing about the fields in > ICE candidates (let's assume that the SDP is negotiated by other > entity which does not notify the media server about ICE candidate > parameters others than local username and password). > > So the media server just knows its local ICE username and password, > but it receives a ICE Request with USE-CANDIDATE on the IPv4 interface > and another on the IPv6 interface. > > Can the ICE server determine which pair to select (the IPv4 or the > IPv6) by just inspecting the PRIORITY attribute in both STUN Requests > and select the one with highest value? > > Or does the server need to assign priority, component and all the ICE > stuff to its interfaces and also be provided with the client's and its > own ICE candidates? > > Thanks a lot. > > -- > I=C3=B1aki Baz Castillo > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --e89a8f6473c7abec7504fd7ea506 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
According to RFC 5245: "If its peer has a lite implem= entation, an agent MUST use a regular nomination algorithm." So, this = whole problem cannot occur.

_____________
Roman Shpount


On Fri, Jul 4, 2014 at 9:15 AM, I=C3=B1a= ki Baz Castillo <ibc@aliax.net> wrote:
Hi,

In case of aggressive ICE the controlling agent (let's say: the
client), and assuming the client has IPv4 and IPv6 and the ICE-Lite
server as well, the server will receive multiple STUN Requests with
USE-CANDIDATE and will decide which one to select based on computed
candidate-pair priorities (so both the client and server select the
same as they follow the same algorithm).

Now my question is: let's assume that the server is just provided with<= br> local ICE username and password, but knows nothing about the fields in
ICE candidates (let's assume that the SDP is negotiated by other
entity which does not notify the media server about ICE candidate
parameters others than local username and password).

So the media server just knows its local ICE username and password,
but it receives a ICE Request with USE-CANDIDATE on the IPv4 interface
and another on the IPv6 interface.

Can the ICE server determine which pair to select (the IPv4 or the
IPv6) by just inspecting the PRIORITY attribute in both STUN Requests
and select the one with highest value?

Or does the server need to assign priority, component and all the ICE
stuff to its interfaces and also be provided with the client's and its<= br> own ICE candidates?

Thanks a lot.

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

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

--e89a8f6473c7abec7504fd7ea506-- From nobody Sat Jul 5 21:54:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761CE1A01A9 for ; Sat, 5 Jul 2014 21:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PD68KMNl3gFw for ; Sat, 5 Jul 2014 21:54:24 -0700 (PDT) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F2621A019A for ; Sat, 5 Jul 2014 21:54:24 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id k48so2972505wev.20 for ; Sat, 05 Jul 2014 21:54:22 -0700 (PDT) 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:content-type; bh=bjTlGu56dkGfNDCHSyBnO84efN8lLqG14sNcXBt31KY=; b=RdjJHIJLCs6cB0quOMVl7EF9HCZo21Yig2bU4qBUtqFk0X5632Bba0RG9gjh9kBtXa HzUh/yg8wcYSglm8S0VbP3MEJzty65qoTlr4AmBdoC9648DOtLjHZFq4EyLV4frb8cCl pcNtBhO4Ypv2myuVS487bcKV59vyMAXiQLb10E4W/uDUkxgvOunba7yKBdwI2UTKWExS C54TfWhMgHXE8eIjV7hUR5MwDIdQdRQNNj0jMbHqsfSaSJiuLhw4FFHVsHevA6kUCwEF 7o+AGs5XcSo88Jq/8SWTEp8gyeKByBEzQeum/EPaFMOfeY/aRv8uKeFpS9RBAgXpeMw8 m/ig== X-Gm-Message-State: ALoCoQnvyOLOx0LgxueFqiIdhJLuaAOFMphN0dNg7JVEIDsXKWla/5d0VCvGsIkLAWHP4E9IvrGv X-Received: by 10.194.71.52 with SMTP id r20mr21562wju.113.1404622462830; Sat, 05 Jul 2014 21:54:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.57.202 with HTTP; Sat, 5 Jul 2014 21:53:42 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: From: Eric Rescorla Date: Sat, 5 Jul 2014 21:53:42 -0700 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=047d7bfcec50f0e3e304fd7f262a Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RDkyCN3tDi7AkmyC_cgPbJEH8TQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about ICE-Lite server X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 04:54:26 -0000 --047d7bfcec50f0e3e304fd7f262a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Jul 5, 2014 at 9:18 PM, Roman Shpount wrote: > According to RFC 5245: "If its peer has a lite implementation, an agent > MUST use a regular nomination algorithm." So, this whole problem cannot > occur. > Nice catch. That actually changes things, since Firefox always uses aggressive nomination and for performance reasons, I'm not excited about moving to regular nomination. This seems like an argument for perhaps forbidding ICE-Lite. I note that this section (8.1.1) actually requires regular nomination in another situation: The controlling agent nominates pairs to be selected by ICE by using one of two techniques: regular nomination or aggressive nomination. If its peer has a lite implementation, an agent MUST use a regular nomination algorithm. If its peer is using ICE options (present in an ice-options attribute from the peer) that the agent does not understand, the agent MUST use a regular nomination algorithm. I note that this has the impact that in the role conflict scenarios (see appendix B.11) offering half-trickle may throw the other side into regular nomination (though only if the other side doesn't support trickle). This is probably an edge case, but I thought I would point it out. -Ekr > _____________ > Roman Shpount > > > On Fri, Jul 4, 2014 at 9:15 AM, I=C3=B1aki Baz Castillo w= rote: > >> Hi, >> >> In case of aggressive ICE the controlling agent (let's say: the >> client), and assuming the client has IPv4 and IPv6 and the ICE-Lite >> server as well, the server will receive multiple STUN Requests with >> USE-CANDIDATE and will decide which one to select based on computed >> candidate-pair priorities (so both the client and server select the >> same as they follow the same algorithm). >> >> Now my question is: let's assume that the server is just provided with >> local ICE username and password, but knows nothing about the fields in >> ICE candidates (let's assume that the SDP is negotiated by other >> entity which does not notify the media server about ICE candidate >> parameters others than local username and password). >> >> So the media server just knows its local ICE username and password, >> but it receives a ICE Request with USE-CANDIDATE on the IPv4 interface >> and another on the IPv6 interface. >> >> Can the ICE server determine which pair to select (the IPv4 or the >> IPv6) by just inspecting the PRIORITY attribute in both STUN Requests >> and select the one with highest value? >> >> Or does the server need to assign priority, component and all the ICE >> stuff to its interfaces and also be provided with the client's and its >> own ICE candidates? >> >> Thanks a lot. >> >> -- >> I=C3=B1aki Baz Castillo >> >> >> _______________________________________________ >> 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 > > --047d7bfcec50f0e3e304fd7f262a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jul 5, 2014 at 9:18 PM, Roman Shpount <roman= @telurix.com> wrote:
According to RFC 5245: "If its peer = has a lite implementation, an agent MUST use a regular nomination algorithm= ." So, this whole problem cannot occur.

Nice catch. That actually changes things, = since Firefox always uses
aggressive nomination and for performan= ce reasons, I'm not excited
about moving to regular nominatio= n. This seems like an argument
for perhaps forbidding ICE-Lite.

I note that = this section (8.1.1) actually requires regular nomination in
anot= her situation:

=C2=A0 =C2=A0The controlling a= gent nominates pairs to be selected by ICE by using
=C2=A0 =C2=A0one of two techniques: regular nomination or aggressive n= omination.
=C2=A0 =C2=A0If its peer has a lite implementation, an= agent MUST use a regular
=C2=A0 =C2=A0nomination algorithm. =C2= =A0If its peer is using ICE options (present in
=C2=A0 =C2=A0an ice-options attribute from the peer) that the agent do= es not
=C2=A0 =C2=A0understand, the agent MUST use a regular nomi= nation algorithm.=C2=A0

I note that this has= the impact that in the role conflict scenarios
(see appendix B.11) offering half-trickle may throw the other side
into regular nomination (though only if the other side doesn't
support trickle). This is probably an edge case, but I thought I
would point it out.


-Ekr
=
=C2=A0
_____________
Roman Shpount


On Fri, Jul 4, 2014 at 9:15 AM, I=C3=B1a= ki Baz Castillo <ibc@aliax.net> wrote:
Hi,

In case of aggressive ICE the controlling agent (let's say: the
client), and assuming the client has IPv4 and IPv6 and the ICE-Lite
server as well, the server will receive multiple STUN Requests with
USE-CANDIDATE and will decide which one to select based on computed
candidate-pair priorities (so both the client and server select the
same as they follow the same algorithm).

Now my question is: let's assume that the server is just provided with<= br> local ICE username and password, but knows nothing about the fields in
ICE candidates (let's assume that the SDP is negotiated by other
entity which does not notify the media server about ICE candidate
parameters others than local username and password).

So the media server just knows its local ICE username and password,
but it receives a ICE Request with USE-CANDIDATE on the IPv4 interface
and another on the IPv6 interface.

Can the ICE server determine which pair to select (the IPv4 or the
IPv6) by just inspecting the PRIORITY attribute in both STUN Requests
and select the one with highest value?

Or does the server need to assign priority, component and all the ICE
stuff to its interfaces and also be provided with the client's and its<= br> own ICE candidates?

Thanks a lot.

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

_______________________________________________
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


--047d7bfcec50f0e3e304fd7f262a-- From nobody Sun Jul 6 00:56:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4461A0295 for ; Sun, 6 Jul 2014 00:56:04 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ULopSFO3StF for ; Sun, 6 Jul 2014 00:56:02 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D5111A0290 for ; Sun, 6 Jul 2014 00:56:02 -0700 (PDT) Received: from 4.224.120.153.east.global.crust-r.net ([153.120.224.4]:55022 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X3hHk-0008Au-Cu; Sun, 06 Jul 2014 17:54:57 +1000 Message-ID: <53B90103.7010907@nteczone.com> Date: Sun, 06 Jul 2014 17:55:47 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Michael Tuexen References: <7594FB04B1934943A5C02806D1A2204B1D35B976@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D35CD5E@ESESSMB209.ericsson.se> <53A7BF3E.8010505@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/A5xvUsxWOQSPN9gIG-6QN_fbF0Q Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WGLC for data channel drafts - sub-protocol usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 07:56:05 -0000 The definition of Token is ASCII not UTF-8. Christian On 5/07/2014 3:23 AM, Michael Tuexen wrote: > On 23 Jun 2014, at 07:46, Christian Groves wrote: > >> Do you need that statement? > I guess formally you don't. But having it make it simpler for the reader... > > Best regards > Michael >> [RFC6455] section 11.5 says: >> >> Subprotocol Identifier >> The identifier of the subprotocol, as will be used in the >> |Sec-WebSocket-Protocol| header field registered in Section 11.3.4 >> of this specification. The value must conform to the requirements >> given in item 10 of Section 4.1 of this specification -- namely, >> the value must be a token as defined by RFC 2616 [RFC2616]. >> >> "Token" is RFC2616 is defined as: >> CHAR = >> token = 1* >> >> Regards, Christian >> >> On 12/06/2014 3:24 AM, Christer Holmberg wrote: >>> Hi Michael, >>> >>> I agree that we need to keep text about the encoding. >>> >>> Regards, >>> >>> Christer >>> >>> ________________________________________ >>> From: Michael Tuexen [Michael.Tuexen@lurchi.franken.de] >>> Sent: Wednesday, 11 June 2014 5:28 PM >>> To: Christer Holmberg >>> Cc: Ted Hardie; rtcweb@ietf.org >>> Subject: Re: [rtcweb] WGLC for data channel drafts - sub-protocol usage >>> >>> On 10 Jun 2014, at 21:22, Christer Holmberg wrote: >>> >>>> Hi, >>>> >>>> A comment on draft-ietf-rtcweb-data-protocol-06: >>>> >>>> Section 5.1 says: >>>> >>>> "Protocol: Variable Length (sequence of characters) >>>> The sub-protocol for the channel as a UTF-8 encoded string. If >>>> this is an empty string the protocol is unspecified. If it is a >>>> non-empty string, it specifies an protocol registered in the >>>> 'WebSocket Subprotocol Name Registry' created in [RFC6455]." >>>> >>>> >>>> I think "The sub-protocol for the channel as a UTF-8 encoded string." part is a little confusing, because there is no such thing as sub-protocol in DCEP itself (DCEP only uses the WebSocket sub-protocol registry for registering DCEP *protocol* values). >>>> >>>> Perhaps we could just remove the sentence, and keep: >>>> >>>> "Protocol: Variable Length (sequence of characters) >>>> If this is an empty string the protocol is unspecified. If it is a >>>> non-empty string, it specifies an protocol registered in the >>>> 'WebSocket Subprotocol Name Registry' created in [RFC6455]." >>>> >>>> Section 4 gives more information about the usage of the protocol. >>> Do you intend to drop the statement about the UTF-8 encoding? >>> I think we should keep a statement about the encoding. >>> >>> Best regards >>> Michael >>>> (Alternatively, we could use sub-protocol terminology also in DCEP) >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> >>>> >>>> From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Ted Hardie [ted.ietf@gmail.com] >>>> Sent: Tuesday, 10 June, 2014 9:52 PM >>>> To: rtcweb@ietf.org >>>> Subject: [rtcweb] WGLC for data channel drafts >>>> >>>> Dear WG, >>>> >>>> This starts a working group last call for our core Data Channel drafts: >>>> >>>> draft-ietf-rtcweb-data-protocol-06.txt >>>> draft-ietf-rtcweb-data-channel-10.txt >>>> >>>> Please review them in detail, especially for areas which may be of concern to the broader IETF community. This WGLC will end on June 27, 2014. >>>> >>>> Ted, Sean, Cullen >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > From nobody Sun Jul 6 01:17:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3BD61A02BB for ; Sun, 6 Jul 2014 01:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 g2C0bxT9JoE6 for ; Sun, 6 Jul 2014 01:16:52 -0700 (PDT) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76BB91A02B9 for ; Sun, 6 Jul 2014 01:16:52 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id r5so2700787qcx.39 for ; Sun, 06 Jul 2014 01:16:51 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=VF7wi73APZQILB9hMS0o3ShICfPhf8sfWO7njBFoXYo=; b=e7j337wnFkEdnBlKCub3Par6H6ZyEN5ZYuUuLKjoPZX1rd4zFkTIvi0wYXsRFkQ0q1 oxnAQxAs0ChG7NOaI4pPhhnt5G37+3yYQlvqJqarlr8kBwsDtuIvdQrpUpe48pj67SXc 3Ez0UglCcng7YuXuNQ8l8CoPQ0e5hpPZ5xB5MbERZxi2rkceL/gbpv/uYA8Mz/G0RR3t v9/LrglFR9jtVjmtVck2KPlQr5XWXJ/e7YDZSx76+6r+uO8Qre62kOm7Gb+EpkNbib1J 2aND3+sJDWEqAst7V72TPa9UQmgPJRIhO6qPAeG1pWXsxeLRpBY4FDngY7oZqrrevs3k jpIg== X-Gm-Message-State: ALoCoQmtDdxM4L65Ss/t68kXAd0NqgJd/q3C62crYL+A+D+V0asKgCuz6NFEy71M+qp9WaKQhef9 X-Received: by 10.140.88.230 with SMTP id t93mr23592165qgd.47.1404634611473; Sun, 06 Jul 2014 01:16:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.234.131 with HTTP; Sun, 6 Jul 2014 01:16:31 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 6 Jul 2014 10:16:31 +0200 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RURhIIEZg3qw8P--tlT30w6r60E Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about ICE-Lite server X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 08:16:54 -0000 2014-07-06 6:53 GMT+02:00 Eric Rescorla : > On Sat, Jul 5, 2014 at 9:18 PM, Roman Shpount wrote: >> >> According to RFC 5245: "If its peer has a lite implementation, an agent >> MUST use a regular nomination algorithm." So, this whole problem cannot >> occur. Good point, thanks. Anyhow I don't think I should trust clients :) > Nice catch. That actually changes things, since Firefox always uses > aggressive nomination and for performance reasons, I'm not excited > about moving to regular nomination. This seems like an argument > for perhaps forbidding ICE-Lite. I don't understand, shouldn't that be fixed in Firefox? This is not about performance but about real issues in scenarios with IPv4 and IPv6 in which Firefox talks to an ICE Lite peer. Should I address an issue? or is it already known? Thanks a lot. --=20 I=C3=B1aki Baz Castillo From nobody Sun Jul 6 02:13:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E2C1A037F for ; Sun, 6 Jul 2014 02:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLBSkGeFE1V5 for ; Sun, 6 Jul 2014 02:13:15 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id B73F61A031D for ; Sun, 6 Jul 2014 02:13:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id B2B2A7C0193 for ; Sun, 6 Jul 2014 11:13:14 +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 K180LDgEVZ20 for ; Sun, 6 Jul 2014 11:13:13 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:65d2:58fb:7fb7:e81a] (unknown [IPv6:2001:470:de0a:27:65d2:58fb:7fb7:e81a]) by mork.alvestrand.no (Postfix) with ESMTPSA id BC8577C37D0 for ; Sun, 6 Jul 2014 11:13:13 +0200 (CEST) Message-ID: <53B91327.50401@alvestrand.no> Date: Sun, 06 Jul 2014 11:13:11 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/CPrSFDx9dWg9M2oJ9mHeNad-qRg Subject: Re: [rtcweb] Question about ICE-Lite server X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 09:13:18 -0000 On 07/04/2014 03:15 PM, Iñaki Baz Castillo wrote: > Hi, > > In case of aggressive ICE the controlling agent (let's say: the > client), and assuming the client has IPv4 and IPv6 and the ICE-Lite > server as well, the server will receive multiple STUN Requests with > USE-CANDIDATE and will decide which one to select based on computed > candidate-pair priorities (so both the client and server select the > same as they follow the same algorithm). > > Now my question is: let's assume that the server is just provided with > local ICE username and password, but knows nothing about the fields in > ICE candidates (let's assume that the SDP is negotiated by other > entity which does not notify the media server about ICE candidate > parameters others than local username and password). To me this sounds like "can an endpoint participate in ICE without participating in the exchange of candidates" - and my immediate reaction is "if it could, it would be a security risk". I don't think it's possible. And I think that's a Good Thing. > > So the media server just knows its local ICE username and password, > but it receives a ICE Request with USE-CANDIDATE on the IPv4 interface > and another on the IPv6 interface. > > Can the ICE server determine which pair to select (the IPv4 or the > IPv6) by just inspecting the PRIORITY attribute in both STUN Requests > and select the one with highest value? > > Or does the server need to assign priority, component and all the ICE > stuff to its interfaces and also be provided with the client's and its > own ICE candidates? > > Thanks a lot. > From nobody Sun Jul 6 05:09:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E881A03FD for ; Sun, 6 Jul 2014 05:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 40GSNu82lz3i for ; Sun, 6 Jul 2014 05:09:18 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F6C1A03FB for ; Sun, 6 Jul 2014 05:09:18 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so3232525wgg.20 for ; Sun, 06 Jul 2014 05:09:17 -0700 (PDT) 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:content-type; bh=o2aZXlTJ0cqCaPZqo9HsdUHrE2JvCenvyCxBFnJ6wJA=; b=KPxKkL0E5IHQU4+05aFeXgJ11eHBjQiAk1WbV8s0fd+saKZB0CfCJFMQJrS2a1b3hu z9c9PYCzXeGoY6Jc8/dTKws+Od8v5coQs01trks5CdbSxXk5RL0E4604Z7jum9UcHVa1 fEU975LJnAM47fxpeR2n0Xppam0LTa8yOxj/fuMY5AChFIR+xLFPtPZKQiLLu/cXX+oQ Yn+UdDidLoSXlwNNBSc0YDKdm0fCzoMxpHkqz7nL7/N0rZixJ7zfeyNB06ZMN9O4I7oT i7iOUhrY9CbYJ9GjWhAyjTymEw3cy07cSmCa9NwfC3N25jUgn429boIH4oH+uqWIZT8D YC6w== X-Gm-Message-State: ALoCoQnywQbSTfJrJ/CQE7pwjm0PpZ0qEZZikY+WNkUB06OtppCoixfEvfEIZOkbku5As/1EqzSN X-Received: by 10.194.90.228 with SMTP id bz4mr25459006wjb.65.1404648557219; Sun, 06 Jul 2014 05:09:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.57.202 with HTTP; Sun, 6 Jul 2014 05:08:37 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: From: Eric Rescorla Date: Sun, 6 Jul 2014 05:08:37 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7bfcff4e49a66204fd853aa3 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2pqRK4oTbBj0GJA3s2erNlIx-bM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about ICE-Lite server X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 12:09:19 -0000 --047d7bfcff4e49a66204fd853aa3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Jul 6, 2014 at 1:16 AM, I=C3=B1aki Baz Castillo wro= te: > 2014-07-06 6:53 GMT+02:00 Eric Rescorla : > > On Sat, Jul 5, 2014 at 9:18 PM, Roman Shpount wrote= : > >> > >> According to RFC 5245: "If its peer has a lite implementation, an agen= t > >> MUST use a regular nomination algorithm." So, this whole problem canno= t > >> occur. > > Good point, thanks. Anyhow I don't think I should trust clients :) > > > > Nice catch. That actually changes things, since Firefox always uses > > aggressive nomination and for performance reasons, I'm not excited > > about moving to regular nomination. This seems like an argument > > for perhaps forbidding ICE-Lite. > > I don't understand, shouldn't that be fixed in Firefox? That's one way to fix it. The other is to require that WebRTC peers do full ICE. I'd be interested in hearing what Chrome does. This is not > about performance but about real issues in scenarios with IPv4 and > IPv6 in which Firefox talks to an ICE Lite peer. > > Should I address an issue? or is it already known? Feel free to file an issue. -Ekr --047d7bfcff4e49a66204fd853aa3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sun, Jul 6, 2014 at 1:16 AM, I=C3=B1aki Baz Castillo <ibc@aliax.n= et> wrote:
2014-07-06 6:53 GMT+02:00 Eric Rescorla <= ekr@rtfm.com>:
> On Sat, Jul 5, 2014 at 9:18 PM, Roman Shpount <roman@telurix.com> wrote:
>>
>> According to RFC 5245: "If its peer has a lite implementation= , an agent
>> MUST use a regular nomination algorithm." So, this whole prob= lem cannot
>> occur.

Good point, thanks. Anyhow I don't think I should trust clients := )


> Nice catch. That actually changes things, since Firefox always uses > aggressive nomination and for performance reasons, I'm not excited=
> about moving to regular nomination. This seems like an argument
> for perhaps forbidding ICE-Lite.

I don't understand, shouldn't that be fixed in Firefox?

That's one way to fix it. The other is to re= quire that WebRTC peers do =C2=A0
full ICE. I'd be interested= in hearing what Chrome does.


This is not about performance but about real issues in scenarios with IPv4 and
IPv6 in which Firefox talks to an ICE Lite peer.

Should I address an issue? or is it already known?

Feel free to file an issue.

-Ekr

--047d7bfcff4e49a66204fd853aa3-- From nobody Sun Jul 6 05:36:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3242C1A0091 for ; Sun, 6 Jul 2014 05:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 Dw3Lz4-1EsCO for ; Sun, 6 Jul 2014 05:36:17 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1327D1A0079 for ; Sun, 6 Jul 2014 05:36:16 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id z60so2842252qgd.30 for ; Sun, 06 Jul 2014 05:36:16 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=1detnrOgnz3z5dXH/tBiRr+1fClXJ88x70JZjU8JPWs=; b=JF7vl+kMNtDBIsK7jgGUCMCPmQtpF6eXnUXqIkknqOhRU3KMp9tdRrHHTg5K62K3qX haldmQH8OYNa4pGiQ2GDnHagA2V5WNLa3Bjqqp6f6ROBWNvWLLBVYREPUsRtj30zs936 tx+jHxWAG9ikrAXWgFwdZl9Vj8a2GhK6g//s/EUR28ioG67SBcwzXA1rkNro063fEkXw y2HFeBd8A9WsTxGLnik2hgg+VdM1+yhVARGQzaDINzR9MqqmcHR7ImQznmd0yfPx/KgN CUxJ8JVFYNG/CRavAml7R+6rxRLxsQLH0RVoOVcGkdReLG2/BYN2mG2QBFnZBAsSAwgy dhcg== X-Gm-Message-State: ALoCoQmO+rUXfzE6f0N+4jEHm30tB7hcCYL6Fi14dLQ+PNffwnn83G/Tyi9eU3unoEM5YzFpCei0 X-Received: by 10.224.162.212 with SMTP id w20mr37743655qax.50.1404650176307; Sun, 06 Jul 2014 05:36:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.234.131 with HTTP; Sun, 6 Jul 2014 05:35:56 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 6 Jul 2014 14:35:56 +0200 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kzBXEE9PVA6fPScxHhJLLfxPztk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about ICE-Lite server X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 12:36:18 -0000 2014-07-06 14:08 GMT+02:00 Eric Rescorla : >> > Nice catch. That actually changes things, since Firefox always uses >> > aggressive nomination and for performance reasons, I'm not excited >> > about moving to regular nomination. This seems like an argument >> > for perhaps forbidding ICE-Lite. >> >> I don't understand, shouldn't that be fixed in Firefox? > > > That's one way to fix it. The other is to require that WebRTC peers do > full ICE. I'd be interested in hearing what Chrome does. I'm hope not. Implementing ICE-Lite in a server is trivial. Implementing full ICE is an overhead in a server. Please not. It is Firefox which must adhere to the standard and use regular nomination when the peer is ICE-Lite. >> This is not >> about performance but about real issues in scenarios with IPv4 and >> IPv6 in which Firefox talks to an ICE Lite peer. >> >> Should I address an issue? or is it already known? > > > Feel free to file an issue. I will. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From nobody Sun Jul 6 05:47:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2AA1A00EF for ; Sun, 6 Jul 2014 05:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 44zIIEfH17GW for ; Sun, 6 Jul 2014 05:47:46 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33BFE1A00A7 for ; Sun, 6 Jul 2014 05:47:46 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j7so2607945qaq.24 for ; Sun, 06 Jul 2014 05:47:45 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=PGYWMkj9UfIPAs0yzHDel8Hz1jQAc5eytgYbk5GAFh0=; b=BZuzI2WMdJH4zCcd5JyX0aOcIORoQ6mpJTSolpiCxOrMMrEeSIvFjfOHQc8J2hU8V4 3QxlqqcRJniHEUb++yopoXAxF86tF0Li7WYWv4aolGeonx2omo6msoQpxuWs5oW6dfZg k1MoSq4XGNW8+fMOXnZd1gPRRXnFK+K7Wjfgy39EFVTq7hIbpB2vvweeqoLqbMlMdPOm PazO7o7ud3beHo1QvusjDQLHG/o7+xU6YMYOymhZR+zrIzMFjV0/Z3YyZjUfPSHswDVf O89rdAV5F9anVdtMiaLITf1z1FkwMV+owY9rik3cS3Vorok9pK6DXux3FU4xMlOaLho1 ZcJA== X-Gm-Message-State: ALoCoQlJIFW6GNwdFxACNlMCLno1AfrBKkZCXd7vZsoeJlc89Rxn0EV1kJLeCHBH1bIp8BMGay42 X-Received: by 10.140.40.81 with SMTP id w75mr35899053qgw.112.1404650865350; Sun, 06 Jul 2014 05:47:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.234.131 with HTTP; Sun, 6 Jul 2014 05:47:25 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 6 Jul 2014 14:47:25 +0200 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2bGrqNSnxqX5OML_o4oLSYAdoFA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about ICE-Lite server X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 12:47:47 -0000 2014-07-06 14:35 GMT+02:00 I=C3=B1aki Baz Castillo : >> Feel free to file an issue. > > I will. Thanks a lot. Done: https://bugzilla.mozilla.org/show_bug.cgi?id=3D1034964 Thanks a lot. --=20 I=C3=B1aki Baz Castillo From nobody Sun Jul 6 05:52:05 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C991A013B for ; Sun, 6 Jul 2014 05:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 NrWFNmp-z05h for ; Sun, 6 Jul 2014 05:52:02 -0700 (PDT) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 347CC1A00FF for ; Sun, 6 Jul 2014 05:52:02 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id j5so2775202qga.9 for ; Sun, 06 Jul 2014 05:52:01 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=l/I7Mh6pOghraQ3L7sVv6U9YIY5KQLM+VuU9Koey4pI=; b=jnkcafLuUUhwSRDiKnRAJe1UVLjfKPTs4Ta4fhLW/GPxAEs0SpBAvFpySisegjx6He fZS8el5R8tvGDceKFLNc6VyNWIC8UxfEYLy5EOntd+sPxzi1bD4cMmOW/GYpH+nR1+Fs MeKspppSS9pZpmzVpN0NlWkwBpkMfglhn1m/Bq0veshNQyTfJF/Jj97nSpblcuAwERvS YqkuW1EboPohOlvINsIfNH8qs1FN/Y0A5AmCr+ym8Y5WEd5xD8tr8T0vfjSZ36HfRMjD kZbnCt2p2MUvMtAbZGpWRTURbEsW4U+1edLsHCzJ3ilqZW+kTUcxlCpovZsrEl6cQw3X A/VQ== X-Gm-Message-State: ALoCoQm8lq0ukpi2SWIvdQHRPq7PVWnjSebQmZjoYOD78Pm7EQIrplsFgyr03jtCo1I67qAEdOkb X-Received: by 10.140.40.81 with SMTP id w75mr35929013qgw.112.1404651121462; Sun, 06 Jul 2014 05:52:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.234.131 with HTTP; Sun, 6 Jul 2014 05:51:41 -0700 (PDT) In-Reply-To: <53B91327.50401@alvestrand.no> References: <53B91327.50401@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 6 Jul 2014 14:51:41 +0200 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/AHoLlnzEIur0JJGYHUe6Xu7efjg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about ICE-Lite server X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 12:52:04 -0000 2014-07-06 11:13 GMT+02:00 Harald Alvestrand : > To me this sounds like "can an endpoint participate in ICE without > participating in the exchange of candidates" - and my immediate reaction = is > "if it could, it would be a security risk". > > I don't think it's possible. And I think that's a Good Thing. Hi Harlad, it is not exactly like that. It is just that the signaling logic (the entity parsing and generating the SDP) and the media server are not co-located. The required information/parameters is transmitted via API between both servers. Regarding ICE the only information the media server needs (given that it is a ICE-Lite server) is the local username and password (so it can verify authentication for incoming Binding requests and can authenticate success responses). --=20 I=C3=B1aki Baz Castillo From nobody Sun Jul 6 06:06:23 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81ACE1A01AC for ; Sun, 6 Jul 2014 06:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 lzWcKEiSbaSz for ; Sun, 6 Jul 2014 06:06:21 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBCAB1A01A8 for ; Sun, 6 Jul 2014 06:06:20 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id w7so2898808qcr.35 for ; Sun, 06 Jul 2014 06:06:20 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=k0H88AFEF4b/mSoJwUl9Zqv0OHh+tuozLSVZVBDldec=; b=eAy9OksYUREbFg1SjC+iX0N4WHYMA5RtsEbdrj5k8lnuapDTFujfYKYgiWauD03p6q 3gEAXHaYSM8ZtbOQ0YEhreLN2Sd2FrCS4XHofnLlSNIxdWJkQExOQlUc6jKAMSXJRA2/ BZPpOsJKsUNrrNpNStXglY9nIzP6j/QRATAQjw+NF4I3vH8H71OBvqN+L9TzcQ82eDHh FPrOveKBQCtYNXbGP2MprL5eI9WYCqEw0K7kLErB3eG/K/+ZPIzau614wHRbGf+g0EUP Ze66vb456IHMGO1QoZ8/EC//Joc0/8D1NC3cgBVdho3ItEvmB7c4iEnHr5l8ixd0sEYl /OEA== X-Gm-Message-State: ALoCoQm1n2QFxl+hNvoshVrWDwbMz+TEJ5H14AMcviRDTzp7z+NMIJGGg2XTGBHnK3LyucvPLEBc X-Received: by 10.224.128.193 with SMTP id l1mr36762576qas.91.1404651980089; Sun, 06 Jul 2014 06:06:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.234.131 with HTTP; Sun, 6 Jul 2014 06:05:59 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 6 Jul 2014 15:05:59 +0200 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/TaMmHeAC_hIyGbBsT6J_bTP4tkk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about ICE-Lite server X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 13:06:21 -0000 2014-07-06 14:08 GMT+02:00 Eric Rescorla : > I'd be interested in hearing what Chrome does. Chrome does not perform aggressive nomination when talking to a ICE-Lite pe= er. --=20 I=C3=B1aki Baz Castillo From nobody Sun Jul 6 06:10:01 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC4A1A01BE for ; Sun, 6 Jul 2014 06:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 YjL1_P-htlmb for ; Sun, 6 Jul 2014 06:09:56 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 989B91A01BA for ; Sun, 6 Jul 2014 06:09:56 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id l18so568480wgh.6 for ; Sun, 06 Jul 2014 06:09:55 -0700 (PDT) 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:content-type; bh=jTXW9JWGTrdUq2vn85a2SaFgHYfy7XEX+/wDtQFwhRg=; b=lHYi3Spa2QBCCFIfN3W84xmjERISflk2jttWvNQGfusFKC4gfyZdIeye86t0M3dZQU QsiMwr/CpsGDdTxfAkzfzK2ci5V81rhaN4wkmY6l1iOkTwBxFt3dKnSQP/0dFztoBgWO lGpV5/CVt5QUIHhdD5stGUrzd2WYv0mfSOkILYRY8NMsfbSQQ4fGh6Yaw1lZXEdxfzgK AexLXgGSu+XVU+OkgBRWW2SW3rWJNpqy4BkDxUmfMRAQNWTu6RYu1rpmC3Gux6bWV40v UF5dcrIjox2AJPzHhNMFwrxQ2k2FoDSWpyuEoPsPvPGGlYTwjRI3QlF64g7StYlNMe85 A2Cw== X-Gm-Message-State: ALoCoQnQrOX8vAtGmcL3S9v1YhvWeGEJhQDnp1N6PeiiDS72dRiO7ZiY3sKqOKCx7Hvmmk42jsIs X-Received: by 10.194.80.7 with SMTP id n7mr25173138wjx.8.1404652195041; Sun, 06 Jul 2014 06:09:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.57.202 with HTTP; Sun, 6 Jul 2014 06:09:14 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: From: Eric Rescorla Date: Sun, 6 Jul 2014 06:09:14 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7beb9c801e8cfa04fd8613c1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/l9TFqRXwkmBKfbwJft2PhOaFRyU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about ICE-Lite server X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 13:09:57 -0000 --047d7beb9c801e8cfa04fd8613c1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Jul 6, 2014 at 5:35 AM, I=C3=B1aki Baz Castillo wro= te: > 2014-07-06 14:08 GMT+02:00 Eric Rescorla : > >> > Nice catch. That actually changes things, since Firefox always uses > >> > aggressive nomination and for performance reasons, I'm not excited > >> > about moving to regular nomination. This seems like an argument > >> > for perhaps forbidding ICE-Lite. > >> > >> I don't understand, shouldn't that be fixed in Firefox? > > > > > > That's one way to fix it. The other is to require that WebRTC peers do > > full ICE. I'd be interested in hearing what Chrome does. > > I'm hope not. Implementing ICE-Lite in a server is trivial. > Implementing full ICE is an overhead in a server. Please not. It is > Firefox which must adhere to the standard and use regular nomination > when the peer is ICE-Lite. Well, we're currently discussing what the standards should say. If we decide that counterparties to WebRTC do full ICE (just like we've required them to do a bunch of other stuff) then it will be the other side which needs to adjust. -Ekr > >> This is not > >> about performance but about real issues in scenarios with IPv4 and > >> IPv6 in which Firefox talks to an ICE Lite peer. > >> > >> Should I address an issue? or is it already known? > > > > > > Feel free to file an issue. > > I will. Thanks a lot. > > > -- > I=C3=B1aki Baz Castillo > > --047d7beb9c801e8cfa04fd8613c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sun, Jul 6, 2014 at 5:35 AM, I=C3=B1aki Baz Castillo <ibc@aliax.n= et> wrote:
2014-07-06 14:08 GMT+02:00 Eric Rescorla <= ;ekr@rtfm.com>:
>> > Nice catch. That actually changes things, sin= ce Firefox always uses
>> > aggressive nomination and for performance reasons, I'm no= t excited
>> > about moving to regular nomination. This seems like an argume= nt
>> > for perhaps forbidding ICE-Lite.
>>
>> I don't understand, shouldn't that be fixed in Firefox? >
>
> That's one way to fix it. The other is to require that WebRTC peer= s do
> full ICE. I'd be interested in hearing what Chrome does.

I'm hope not. Implementing ICE-Lite in a server is trivial.
Implementing full ICE is an overhead in a server. Please not. It is
Firefox which must adhere to the standard and use regular nomination
when the peer is ICE-Lite.

Well, we're = currently discussing what the standards should say.
If we decide = that counterparties to WebRTC do full ICE (just like
we've re= quired them to do a bunch of other stuff) then it will be
the other side which needs to adjust.

-Ekr



>> This is not
>> about performance but about real issues in scenarios with IPv4 and=
>> IPv6 in which Firefox talks to an ICE Lite peer.
>>
>> Should I address an issue? or is it already known?
>
>
> Feel free to file an issue.

I will. Thanks a lot.


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

--047d7beb9c801e8cfa04fd8613c1-- From nobody Sun Jul 6 06:20:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F9B1A0262 for ; Sun, 6 Jul 2014 06:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 p54SR2y-DVO6 for ; Sun, 6 Jul 2014 06:20:46 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DD7E1A0235 for ; Sun, 6 Jul 2014 06:20:46 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id l6so2823190qcy.18 for ; Sun, 06 Jul 2014 06:20:45 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=xO2DZlXxUC+ASy5QES8UEgojy3YenO3a2GgfijdUopw=; b=lWkZHRxg0FuelVqu0To2jajX/JcpUlieiYgVFwhENvGBAm4xL8O6GnMjYIfiN05vb0 5f9QUU4KN8yc9ePFBCzuMjCw4Yf4i90pg6deAOXOoIE9o28z/c3hkfMDmUrr8jwQUNtd WP/gpNRGJ77bqKT27LkZDeGV5Pv7oJmOl1yc2grlRkZ/filQyUB3O9LaLWBkUU69y/6l pjloITUs+PuAmQoWP/h4H0VRTfNqENQP6O9KZ9g/BcpH+aVkhscNFlCpBG8+Pm4Ucqhx uj3lHUl+hlC09vjnr0Tz6RRk7UhDmUON7os0yPSIDsH1IDTeLoeVc50IvaWxUjj0k3BF uKFA== X-Gm-Message-State: ALoCoQmYUdDksKoY9cHxYpssYNcLaWAGiNVdRBzZPCx4ug4Yrpwk0CqwOiF1HvE/GQezby26FBKG X-Received: by 10.229.51.201 with SMTP id e9mr36757514qcg.2.1404652845633; Sun, 06 Jul 2014 06:20:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.234.131 with HTTP; Sun, 6 Jul 2014 06:20:25 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 6 Jul 2014 15:20:25 +0200 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/pJKlJMSGW1kJGrf1ST2doDe1QGo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about ICE-Lite server X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 13:20:47 -0000 2014-07-06 15:09 GMT+02:00 Eric Rescorla : >> I'm hope not. Implementing ICE-Lite in a server is trivial. >> Implementing full ICE is an overhead in a server. Please not. It is >> Firefox which must adhere to the standard and use regular nomination >> when the peer is ICE-Lite. > > > Well, we're currently discussing what the standards should say. > If we decide that counterparties to WebRTC do full ICE (just like > we've required them to do a bunch of other stuff) then it will be > the other side which needs to adjust. Of course. I just hope such a decision is not taken given the amount of server side implementations relying on ICE-Lite (and the fact that it is not so hard for full ICE clients to behave correctly when talking to a lite peer). Regards. --=20 I=C3=B1aki Baz Castillo From nobody Mon Jul 7 02:03:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7281B27EA for ; Mon, 7 Jul 2014 02:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D_chaAZfnxxy for ; Mon, 7 Jul 2014 02:03:24 -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 89D951B27E0 for ; Mon, 7 Jul 2014 02:03:23 -0700 (PDT) X-AuditID: c1b4fb30-f79da6d000006b80-b7-53ba62593b31 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 4A.97.27520.9526AB35; Mon, 7 Jul 2014 11:03:21 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0174.001; Mon, 7 Jul 2014 11:03:20 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , Eric Rescorla Thread-Topic: [rtcweb] Question about ICE-Lite server Thread-Index: AQHPl4oNJSaeycfS3EWkey3p+g1y9puSUgAAgAAJ6QCAADirgIAAQNmAgAAHoQCAAAlOAIAAAyCAgAFrm24= Date: Mon, 7 Jul 2014 09:03:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3B608F@ESESSMB209.ericsson.se> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+JvjW5k0q5gg71PdSxWvD7HbjF9n43F 2n/t7A7MHuca3rN7LFnyk8lj8uM25gDmKC6blNSczLLUIn27BK6My1+fshd8Z6t4/24BawPj JtYuRk4OCQETiXkbfzND2GISF+6tZ+ti5OIQEjjKKDHjwWImkISQwEJGiQ0rqrsYOTjYBCwk uv9pg4RFBCIljnQdB+tlFlCXuLP4HDuILQw089jtDWwQNaYScx98YoKwkyQ2/+gH28sioCIx eXkzmM0r4Ctxd2MfM8Te/SwSPya+BEtwCgRKfL97gwXEZgQ67vupNUwQy8Qlbj2ZzwRxtIDE kj3noR4QlXj5+B8ryJ0SAkoS07amQZTrSdyYOoUNwtaWWLbwNTPEXkGJkzOfsExgFJuFZOos JC2zkLTMQtKygJFlFaNocWpxUm66kZFealFmcnFxfp5eXmrJJkZgPB3c8ttgB+PL546HGAU4 GJV4eB8c2xksxJpYVlyZe4hRmoNFSZx34bl5wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY F/KxCc5uWtl5L3N/7j2P6Xc3fWXpcrgXq5n1SPf3R517hZ4RZ8pWHGP79+E6vyHrpJ5L73RO fbT5/Z3hzb9v29x9D4QwVBop1PikfQ7nnMzfyvRTX3ja0/duO2OPmkzfsUegoDXq6gNhXX3L 0kn9+pkJq5gd0zZd8wiWN1as9BJ6+XJ/wnVeJZbijERDLeai4kQA1SORgogCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/iPzwhb4hYBW-QtZI23kD363C2ak Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about ICE-Lite server X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 09:03:25 -0000 Hi, >>> I'm hope not. Implementing ICE-Lite in a server is trivial. >>> Implementing full ICE is an overhead in a server. Please not. It is >>> Firefox which must adhere to the standard and use regular nomination >>> when the peer is ICE-Lite. >> >> >> Well, we're currently discussing what the standards should say. >> If we decide that counterparties to WebRTC do full ICE (just like >> we've required them to do a bunch of other stuff) then it will be >> the other side which needs to adjust. > > > Of course. I just hope such a decision is not taken given the amount > of server side implementations relying on ICE-Lite (and the fact that > it is not so hard for full ICE clients to behave correctly when > talking to a lite peer). +1. I also we more or less had agreed on this in the past, that ICE-Lite is ok = e.g. for gateways. Regards, Christer= From nobody Mon Jul 7 03:22:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044BD1B2807 for ; Mon, 7 Jul 2014 03:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.601 X-Spam-Level: X-Spam-Status: No, score=-6.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSzxB85wuQTv for ; Mon, 7 Jul 2014 03:22:26 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2E181B2805 for ; Mon, 7 Jul 2014 03:22:25 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s67AML8w022268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Jul 2014 10:22:21 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s67AMIwS010020 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jul 2014 12:22:19 +0200 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 7 Jul 2014 12:22:18 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.136]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0181.006; Mon, 7 Jul 2014 12:22:18 +0200 From: "Rauschenbach, Uwe (NSN - DE/Munich)" To: ext Christer Holmberg , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , Eric Rescorla Thread-Topic: [rtcweb] Question about ICE-Lite server Thread-Index: AQHPmNFaxlBjIjlaUkagsYjKd7XPXJuSWVoAgAA4q4CAAEDZgIAAB6IAgAAJTgCAAAMggIABSoAAgAA2lsA= Date: Mon, 7 Jul 2014 10:22:18 +0000 Message-ID: <56C2F665D49E0341B9DF5938005ACDF833E4DD@DEMUMBX005.nsn-intra.net> References: , <7594FB04B1934943A5C02806D1A2204B1D3B608F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D3B608F@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.115] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1493 X-purgate-ID: 151667::1404728541-000005B1-787B45DC/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IrrW-NRUEtEdBMcHAKP7UgyrLm0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about ICE-Lite server X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 10:22:27 -0000 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Christer > Holmberg > Sent: Monday, July 07, 2014 11:03 AM > To: I=F1aki Baz Castillo; Eric Rescorla > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Question about ICE-Lite server >=20 > Hi, >=20 > >>> I'm hope not. Implementing ICE-Lite in a server is trivial. > >>> Implementing full ICE is an overhead in a server. Please not. It is > >>> Firefox which must adhere to the standard and use regular nomination > >>> when the peer is ICE-Lite. > >> > >> > >> Well, we're currently discussing what the standards should say. > >> If we decide that counterparties to WebRTC do full ICE (just like > >> we've required them to do a bunch of other stuff) then it will be > >> the other side which needs to adjust. > > > > > > Of course. I just hope such a decision is not taken given the amount > > of server side implementations relying on ICE-Lite (and the fact that > > it is not so hard for full ICE clients to behave correctly when > > talking to a lite peer). >=20 > +1. >=20 > I also we more or less had agreed on this in the past, that ICE-Lite is > ok e.g. for gateways. Same here. Gateways connected to the public Internet need to (and often do)= implement ICE Lite only. So far, implementers have trusted that this is OK based on the ICE RFC.=20 We need good reasons when profiling other RFCs. Kind regards, Uwe >=20 > Regards, >=20 > Christer From nobody Mon Jul 7 03:25:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5EFA1B280E for ; Mon, 7 Jul 2014 03:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 dck_haGAjGgR for ; Mon, 7 Jul 2014 03:25:23 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C5A1B2805 for ; Mon, 7 Jul 2014 03:25:22 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id k15so3269428qaq.2 for ; Mon, 07 Jul 2014 03:25:21 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=4bu2ABWBoCYlIAXIFCIWyjqOxgvimN8+ud3Dquml7fs=; b=dPast3Y1+Uv9kmUOt9yb7W3QeFg8ug6KoLgRDBlwLBm4W6CsfjRdBPjOiRCIUQY2G4 y6cTM2/7p76bocAVJpWtxjMDumcoJ07DyshZO8Vk4D3WTYnEze5C4SfEOPRFar56EiNh 9fwYPMO6x7ohzekptpk6HILpuqhzgJkOpFwVcp6QrQp2htvqijf0oooIRCEqz6hPKwFd 9TfjWFxqp8MMAk22hIouwI3P1kEcD6ozbTNgFNEwxTc79rZSDdBfaSK2xyxhwOd/+OWP 13QNH3rXckub3Ben1iy4skdGi/tGzuDob4RPYhAtiLmog+n7LKX9tL5AC3a1wxv0Ip9C fCnQ== X-Gm-Message-State: ALoCoQmHqlKdz+o9Ej9JcgDXbkMf7xikmeL++k7bhtfu+Wck47aL/oextH+HDHxG5PchiEvFT9w9 X-Received: by 10.224.129.68 with SMTP id n4mr46141446qas.66.1404728721071; Mon, 07 Jul 2014 03:25:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.234.131 with HTTP; Mon, 7 Jul 2014 03:25:01 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D3B608F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D3B608F@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 7 Jul 2014 12:25:01 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wMK70C7bUwcvQgtpgEmIox-1uik Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about ICE-Lite server X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 10:25:26 -0000 2014-07-07 11:03 GMT+02:00 Christer Holmberg : > I also we more or less had agreed on this in the past, that ICE-Lite is o= k e.g. for gateways. Oh, and also for much more interesting servers than gateways! :) --=20 I=C3=B1aki Baz Castillo From nobody Mon Jul 7 03:34:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF22B1B280B for ; Mon, 7 Jul 2014 03:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.28 X-Spam-Level: X-Spam-Status: No, score=0.28 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 46nQAfLCq9M9 for ; Mon, 7 Jul 2014 03:34:29 -0700 (PDT) Received: from smtpdb9.aruba.it (smtpdg225.aruba.it [62.149.158.225]) by ietfa.amsl.com (Postfix) with ESMTP id A6C931B2807 for ; Mon, 7 Jul 2014 03:34:28 -0700 (PDT) Received: from lminiero ([143.225.229.180]) by smtpcmd03.ad.aruba.it with bizsmtp id PNaN1o01V3uAlfT01NaPWq; Mon, 07 Jul 2014 12:34:25 +0200 Date: Mon, 7 Jul 2014 12:34:22 +0200 From: Lorenzo Miniero To: =?UTF-8?B?ScOxYWtp?= Baz Castillo Message-ID: <20140707123422.4176cc3d@lminiero> In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D3B608F@ESESSMB209.ericsson.se> Organization: Meetecho X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vXE-khipM84bBbrQRZsM0OT7L6E Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about ICE-Lite server X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 10:34:33 -0000 On Mon, 7 Jul 2014 12:25:01 +0200 I=C3=B1aki Baz Castillo wrote: > 2014-07-07 11:03 GMT+02:00 Christer Holmberg > : > > I also we more or less had agreed on this in the past, that > > ICE-Lite is ok e.g. for gateways. >=20 > Oh, and also for much more interesting servers than gateways! :) >=20 >=20 I agree that ICE-Lite should be supported. We've used the backwards-compatibility card for so many things in RTCWEB so far that it seems silly to throw away what on the other end would be really useful. L. From nobody Mon Jul 7 03:41:12 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0241B280F for ; Mon, 7 Jul 2014 03:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 Uy6XGZec81z8 for ; Mon, 7 Jul 2014 03:41:10 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2289C1B280C for ; Mon, 7 Jul 2014 03:41:10 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id z60so3483290qgd.16 for ; Mon, 07 Jul 2014 03:41:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kgxO9+ZCiaV5rxRTCI5NHxkoI8D2jkltPR49fmA2rJs=; b=OPr95YGtVIR9elebkSW85tyX5TcdGFIyyE8nzb2KVs9yHgrSp/i60S5sUX54JB43Nt 5Hnu7NKtJ+VK4C1CTRzi47QfScJ/r2QTtssIJ3AtvPgBgAlGRMfXL7UdspWjVuqKiRPW htOfbut2O2zDk6hheNgGXyjkCDlTHwN2P9c74t5TN5FVu/NwuUwYyMmS/jxl3Xbx2gZP CWMCyGcv9/7aRwpoVYUtMvCkQy4wkUuSuZc76Mz66AnD2q/NdG5ZLUjqIQzfQSJTgQoP vtiQZeaT/dG2sVbotLpbX5OFThKP90I11WikeXdIQ+Tza1bCRBz9ZvjX7uFLzRntjr4W N/WQ== X-Gm-Message-State: ALoCoQneNtNDmcspk2WbKJSB+n4cIgbQ1gLY6u/FRH0Vnot0Y5NhIEzL8DLy6x6XGiqZbz9lLCz9 MIME-Version: 1.0 X-Received: by 10.224.162.212 with SMTP id w20mr46745575qax.50.1404729669389; Mon, 07 Jul 2014 03:41:09 -0700 (PDT) Received: by 10.96.234.131 with HTTP; Mon, 7 Jul 2014 03:41:09 -0700 (PDT) Received: by 10.96.234.131 with HTTP; Mon, 7 Jul 2014 03:41:09 -0700 (PDT) In-Reply-To: <20140707123422.4176cc3d@lminiero> References: <7594FB04B1934943A5C02806D1A2204B1D3B608F@ESESSMB209.ericsson.se> <20140707123422.4176cc3d@lminiero> Date: Mon, 7 Jul 2014 12:41:09 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Lorenzo Miniero Content-Type: multipart/alternative; boundary=089e013cb7cef3242a04fd981c08 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/w8z4wSygO8Uai_F2UM-ziFqgiF0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Question about ICE-Lite server X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 10:41:11 -0000 --089e013cb7cef3242a04fd981c08 Content-Type: text/plain; charset=UTF-8 > I agree that ICE-Lite should be supported. We've used the > backwards-compatibility card for so many things in RTCWEB so far that it > seems silly to throw away what on the other end would be really useful. BTW I do not consider ICE Lite something for "backwards-compatibility", but an easier way to implement real ICE in servers running in the public Internet in which all the complexity of full ICE is not required at all. --089e013cb7cef3242a04fd981c08 Content-Type: text/html; charset=UTF-8


> I agree that ICE-Lite should be supported. We've used the
> backwards-compatibility card for so many things in RTCWEB so far that it
> seems silly to throw away what on the other end would be really useful.

BTW I do not consider ICE Lite something for "backwards-compatibility", but an easier way to implement real ICE in servers running in the public Internet in which all the complexity of full ICE is not required at all.

--089e013cb7cef3242a04fd981c08-- From nobody Mon Jul 7 06:41:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AED1A005C for ; Mon, 7 Jul 2014 06:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcMB-o4CK5QE for ; Mon, 7 Jul 2014 06:41:54 -0700 (PDT) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B73EE1A002B for ; Mon, 7 Jul 2014 06:41:54 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id eb12so4656352oac.27 for ; Mon, 07 Jul 2014 06:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RYaPSuXk31kbMVCZ3HuKcSiH5+2jzcT3LfrbBLxxE8c=; b=DmTdKhHGtH1mXsFO4wk2YGVPuI57kRgcI8tPYtCfqz9m3NWRelEni9Xf6FM80kpGwp 7j4ZZmDbioGMGZy1gD1Ez98KF9L29Y4C2szBQn6I/vG4YKcc+tY6bujxBOu5WssJeeBy GQhrMELROLLx9QTWyBG0F6erwKzUtuwJavW4gslFgD8fGbzQTMS9vgAgt5XV+rkUpB1F Ve/gHmK/Yh1ednrpaXJ632hdzobN5fGziJ9SooJ6DlX4SjsL1vjzLKu+SivGyIxGEoOJ OAlueSPVqBZXVn/Q0rOXn1NBBoajhYGaSMMMDNTERAwhUXBpxhZgVV5RbW4woqRZaqwI 7i2Q== MIME-Version: 1.0 X-Received: by 10.60.84.233 with SMTP id c9mr31283049oez.0.1404740514155; Mon, 07 Jul 2014 06:41:54 -0700 (PDT) Received: by 10.202.208.72 with HTTP; Mon, 7 Jul 2014 06:41:54 -0700 (PDT) In-Reply-To: References: <20140704154209.13282.96755.idtracker@ietfa.amsl.com> Date: Mon, 7 Jul 2014 21:41:54 +0800 Message-ID: From: Alexandre GOUAILLARD To: "Ram Mohan R (rmohanr)" Content-Type: multipart/alternative; boundary=089e0118495659118f04fd9aa3c4 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4WeeSnorWnH3SAyInw9umPjdauI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 13:41:56 -0000 --089e0118495659118f04fd9aa3c4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable on page 3, there is a typo (repeated word): "prevent prevent". On Fri, Jul 4, 2014 at 11:44 PM, Ram Mohan R (rmohanr) wrote: > New revision changes includes: > > Added a line at the end of Introduction section for ICE lite > Re-worded the text that had the word =C2=B3inverted=C2=B2. > > Regards, > Ram > > > > -----Original Message----- > From: "internet-drafts@ietf.org" > Date: Friday, 4 July 2014 9:12 pm > To: "i-d-announce@ietf.org" > Cc: "rtcweb@ietf.org" > Subject: [rtcweb] I-D Action: > draft-ietf-rtcweb-stun-consent-freshness-05.txt > > > > >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-browser= s > >Working Group of the IETF. > > > > Title : STUN Usage for Consent Freshness > > Authors : Muthu Arul Mozhi Perumal > > Dan Wing > > Ram Mohan Ravindranath > > Tirumaleswar Reddy > > Martin Thomson > > Filename : draft-ietf-rtcweb-stun-consent-freshness-05.txt > > Pages : 9 > > Date : 2014-07-04 > > > >Abstract: > > To prevent sending excessive traffic to an endpoint, periodic consent > > needs to be obtained from that remote endpoint. > > > > This document describes a consent mechanism using a new STUN usage. > > This same mechanism can also determine connection loss ("liveness") > > with a remote peer. > > > > > >The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness= / > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-05 > > > >A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent-freshne= ss- > >05 > > > > > >Please note that it may take a couple of minutes from the time of > >submission > >until the htmlized version and diff are available at tools.ietf.org. > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >rtcweb mailing list > >rtcweb@ietf.org > >https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --=20 Alex. Gouaillard, PhD, PhD, MBA ---------------------------------------------------------------------------= --------- CTO - Temasys Communications, S'pore / Mountain View President - CoSMo Software, Cambridge, MA ---------------------------------------------------------------------------= --------- sg.linkedin.com/agouaillard - --089e0118495659118f04fd9aa3c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
on page 3, there is a typo (repeated word): "prevent prevent".



On Fri, Jul 4, 2014 at 11:44 PM, Ram Moh= an R (rmohanr) <rmohanr@cisco.com> wrote:
New revision changes includes:

Added a line at the end of Introduction section for ICE lite
Re-worded the text that had =C2=A0the word =C2=B3inverted=C2=B2.

Regards,
Ram



-----Original Message-----
From: "internet-drafts@iet= f.org" <internet-dr= afts@ietf.org>
Date: Friday, 4 July 2014 9:12 pm
To: "i-d-announce@ietf.org" <i-d-announce@ietf.org<= /a>>
Cc: "rtcweb@ietf.org" <= rtcweb@ietf.org>
Subject: [rtcweb] I-D Action:
draft-ietf-rtcweb-stun-consent-freshness-05.txt

>
>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-browse= rs
>Working Group of the IETF.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = STUN Usage for Consent Freshness
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Muthu= Arul Mozhi Perumal
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Dan Wing
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Ram Mohan Ravindranath
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Tirumaleswar Reddy
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Martin Thomson
> =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-ietf-= rtcweb-stun-consent-freshness-05.txt
> =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 9
> =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 2= 014-07-04
>
>Abstract:
> =C2=A0 To prevent sending excessive traffic to an endpoint, periodic c= onsent
> =C2=A0 needs to be obtained from that remote endpoint.
>
> =C2=A0 This document describes a consent mechanism using a new STUN us= age.
> =C2=A0 This same mechanism can also determine connection loss ("l= iveness")
> =C2=A0 with a remote peer.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ie= tf-rtcweb-stun-consent-freshness/
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-rtcweb-= stun-consent-freshness-05
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-rtcweb-stun-consent-freshness-
>05
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp:/= /ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb

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



--
=
Alex. Gouaillard, PhD, PhD, MBA
----------------------= --------------------------------------------------------------
CT= O - Temasys Communications, S'pore / Mountain View
President - CoSMo Software, Cambridge, MA
------------------= ------------------------------------------------------------------
sg.linke= din.com/agouaillard

--089e0118495659118f04fd9aa3c4-- From nobody Mon Jul 7 06:51:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509F21A00A7 for ; Mon, 7 Jul 2014 06:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9y6YSQzxcwa6 for ; Mon, 7 Jul 2014 06:51:30 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 630811A009E for ; Mon, 7 Jul 2014 06:51:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15474; q=dns/txt; s=iport; t=1404741090; x=1405950690; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KIUq3CajrXmxJ62NMxB+Segf6Ix0YBZ/JO7jmq7bhAY=; b=Le6GfA516d/4W4fvDWOU5vrJiKStPuFYflcG8O8eaSbTPnWL4rZIxNOM kU1qhVNEk9Xc9Uscxmpi0c+E8yj1qL6NdoNjcOhwuaJlDpK1+daYVTS8b doQ4jb5iWhf8dICNfDqlV9hHKsoVnnBYtaDvNiDvgFlMj4IqvdNQWA5aa M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmELAOKkulOtJA2E/2dsb2JhbABagkdHUlMHgm+6MIFWAYZxUwEZfBZ1hAMBAQEEAQEBawsMBAIBCBEDAQIoBQICHwYLFAkIAgQOBQmIJQMRCAWTZJwfBpMhDYYwF4x6ghcNBAcGA4JogVIFhWqTDIIAgUiMMIYUg0OCMA X-IronPort-AV: E=Sophos;i="5.01,618,1400025600"; d="scan'208,217";a="338001170" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-1.cisco.com with ESMTP; 07 Jul 2014 13:51:29 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s67DpTVn022460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jul 2014 13:51:29 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.10]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 08:51:29 -0500 From: "Ram Mohan R (rmohanr)" To: Alexandre GOUAILLARD Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-05.txt Thread-Index: AQHPmeqN7x2OL4OsgUyyjwXVXDwfyA== Date: Mon, 7 Jul 2014 13:51:28 +0000 Message-ID: References: <20140704154209.13282.96755.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.71.102] Content-Type: multipart/alternative; boundary="_000_CFE0A3DD940ACrmohanrciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/l4NYxQ1ANQF4wi7ECM7ZBaV0Wdo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 13:51:32 -0000 --_000_CFE0A3DD940ACrmohanrciscocom_ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciBjYXRjaGluZy4gV2lsbCBmaXggaW4gbmV4dCByZXZpc2lvbi4NCg0KUmFtDQoN CkZyb206IEFsZXhhbmRyZSBHT1VBSUxMQVJEIDxhZ291YWlsbGFyZEBnbWFpbC5jb208bWFpbHRv OmFnb3VhaWxsYXJkQGdtYWlsLmNvbT4+DQpEYXRlOiBNb25kYXksIDcgSnVseSAyMDE0IDc6MTEg cG0NClRvOiBSYW0gTW9oYW4gUmF2aW5kcmFuYXRoIDxybW9oYW5yQGNpc2NvLmNvbTxtYWlsdG86 cm1vaGFuckBjaXNjby5jb20+Pg0KQ2M6ICJydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBp ZXRmLm9yZz4iIDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpTdWJq ZWN0OiBSZTogW3J0Y3dlYl0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25z ZW50LWZyZXNobmVzcy0wNS50eHQNCg0Kb24gcGFnZSAzLCB0aGVyZSBpcyBhIHR5cG8gKHJlcGVh dGVkIHdvcmQpOiAicHJldmVudCBwcmV2ZW50Ii4NCg0KDQoNCk9uIEZyaSwgSnVsIDQsIDIwMTQg YXQgMTE6NDQgUE0sIFJhbSBNb2hhbiBSIChybW9oYW5yKSA8cm1vaGFuckBjaXNjby5jb208bWFp bHRvOnJtb2hhbnJAY2lzY28uY29tPj4gd3JvdGU6DQpOZXcgcmV2aXNpb24gY2hhbmdlcyBpbmNs dWRlczoNCg0KQWRkZWQgYSBsaW5lIGF0IHRoZSBlbmQgb2YgSW50cm9kdWN0aW9uIHNlY3Rpb24g Zm9yIElDRSBsaXRlDQpSZS13b3JkZWQgdGhlIHRleHQgdGhhdCBoYWQgIHRoZSB3b3JkIKn4aW52 ZXJ0ZWSp9y4NCg0KUmVnYXJkcywNClJhbQ0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206ICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZz4iIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZz4+DQpEYXRlOiBGcmlkYXksIDQgSnVseSAyMDE0IDk6MTIgcG0NClRvOiAi aS1kLWFubm91bmNlQGlldGYub3JnPG1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+IiA8aS1k LWFubm91bmNlQGlldGYub3JnPG1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+Pg0KQ2M6ICJy dGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4iIDxydGN3ZWJAaWV0Zi5vcmc8 bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbcnRjd2ViXSBJLUQgQWN0aW9uOg0K ZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0wNS50eHQNCg0KPg0KPkEg TmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0 LURyYWZ0cw0KPmRpcmVjdG9yaWVzLg0KPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRo ZSBSZWFsLVRpbWUgQ29tbXVuaWNhdGlvbiBpbiBXRUItYnJvd3NlcnMNCj5Xb3JraW5nIEdyb3Vw IG9mIHRoZSBJRVRGLg0KPg0KPiAgICAgICAgVGl0bGUgICAgICAgICAgIDogU1RVTiBVc2FnZSBm b3IgQ29uc2VudCBGcmVzaG5lc3MNCj4gICAgICAgIEF1dGhvcnMgICAgICAgICA6IE11dGh1IEFy dWwgTW96aGkgUGVydW1hbA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgRGFuIFdpbmcNCj4g ICAgICAgICAgICAgICAgICAgICAgICAgIFJhbSBNb2hhbiBSYXZpbmRyYW5hdGgNCj4gICAgICAg ICAgICAgICAgICAgICAgICAgIFRpcnVtYWxlc3dhciBSZWRkeQ0KPiAgICAgICAgICAgICAgICAg ICAgICAgICAgTWFydGluIFRob21zb24NCj4gICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQt aWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0wNS50eHQNCj4gICAgICAgUGFnZXMg ICAgICAgICAgIDogOQ0KPiAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDE0LTA3LTA0DQo+DQo+ QWJzdHJhY3Q6DQo+ICAgVG8gcHJldmVudCBzZW5kaW5nIGV4Y2Vzc2l2ZSB0cmFmZmljIHRvIGFu IGVuZHBvaW50LCBwZXJpb2RpYyBjb25zZW50DQo+ICAgbmVlZHMgdG8gYmUgb2J0YWluZWQgZnJv bSB0aGF0IHJlbW90ZSBlbmRwb2ludC4NCj4NCj4gICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBh IGNvbnNlbnQgbWVjaGFuaXNtIHVzaW5nIGEgbmV3IFNUVU4gdXNhZ2UuDQo+ICAgVGhpcyBzYW1l IG1lY2hhbmlzbSBjYW4gYWxzbyBkZXRlcm1pbmUgY29ubmVjdGlvbiBsb3NzICgibGl2ZW5lc3Mi KQ0KPiAgIHdpdGggYSByZW1vdGUgcGVlci4NCj4NCj4NCj5UaGUgSUVURiBkYXRhdHJhY2tlciBz dGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLw0KPg0KPlRo ZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3Mt MDUNCj4NCj5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6 DQo+aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1ydGN3ZWItc3R1 bi1jb25zZW50LWZyZXNobmVzcy0NCj4wNQ0KPg0KPg0KPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+c3VibWlzc2lvbg0K PnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9v bHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCj4NCj5JbnRlcm5ldC1EcmFmdHMg YXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy8NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj5ydGN3ZWJAaWV0Zi5vcmc8 bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3J0Y3dlYg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3 ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dl Yg0KDQoNCg0KLS0NCkFsZXguIEdvdWFpbGxhcmQsIFBoRCwgUGhELCBNQkENCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KQ1RPIC0gVGVtYXN5cyBDb21tdW5pY2F0aW9ucywgUydwb3JlIC8g TW91bnRhaW4gVmlldw0KUHJlc2lkZW50IC0gQ29TTW8gU29mdHdhcmUsIENhbWJyaWRnZSwgTUEN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0Kc2cubGlua2VkaW4uY29tL2Fnb3VhaWxsYXJk PGh0dHA6Ly9zZy5saW5rZWRpbi5jb20vYWdvdWFpbGxhcmQ+DQoNCiAgKg0KDQo= --_000_CFE0A3DD940ACrmohanrciscocom_ Content-Type: text/html; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog MTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+VGhhbmtzIGZv ciBjYXRjaGluZy4gV2lsbCBmaXggaW4gbmV4dCByZXZpc2lvbi48L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PlJhbTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtf U1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250 LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTog bWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBp bjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1 YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAz cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5BbGV4YW5k cmUgR09VQUlMTEFSRCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFnb3VhaWxsYXJkQGdtYWlsLmNvbSI+ YWdvdWFpbGxhcmRAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPk1vbmRheSwgNyBKdWx5IDIwMTQgNzoxMSBwbTxicj4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPlJhbSBNb2hhbiBSYXZpbmRy YW5hdGggJmx0OzxhIGhyZWY9Im1haWx0bzpybW9oYW5yQGNpc2NvLmNvbSI+cm1vaGFuckBjaXNj by5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9z cGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9y ZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBp ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1Ympl Y3Q6IDwvc3Bhbj5SZTogW3J0Y3dlYl0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1ydGN3ZWItc3R1 bi1jb25zZW50LWZyZXNobmVzcy0wNS50eHQ8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPm9uIHBhZ2UgMywgdGhlcmUgaXMgYSB0eXBv IChyZXBlYXRlZCB3b3JkKTogJnF1b3Q7PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7Zm9u dC1zaXplOjFlbSI+cHJldmVudCBwcmV2ZW50JnF1b3Q7Ljwvc3Bhbj4NCjxkaXY+PHNwYW4gc3R5 bGU9ImNvbG9yOnJnYigwLDAsMCk7Zm9udC1zaXplOjFlbSI+PGJyPg0KPC9zcGFuPjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGJyPg0KPGRpdiBjbGFzcz0i Z21haWxfcXVvdGUiPk9uIEZyaSwgSnVsIDQsIDIwMTQgYXQgMTE6NDQgUE0sIFJhbSBNb2hhbiBS IChybW9oYW5yKSA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOnJtb2hhbnJA Y2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+cm1vaGFuckBjaXNjby5jb208L2E+Jmd0Ozwvc3Bh bj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFy Z2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFl eCI+DQpOZXcgcmV2aXNpb24gY2hhbmdlcyBpbmNsdWRlczo8YnI+DQo8YnI+DQpBZGRlZCBhIGxp bmUgYXQgdGhlIGVuZCBvZiBJbnRyb2R1Y3Rpb24gc2VjdGlvbiBmb3IgSUNFIGxpdGU8YnI+DQpS ZS13b3JkZWQgdGhlIHRleHQgdGhhdCBoYWQgJm5ic3A7dGhlIHdvcmQgqfhpbnZlcnRlZKn3Ljxi cj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KUmFtPGJyPg0KPGRpdiBjbGFzcz0iSE9FblpiIj4NCjxk aXYgY2xhc3M9Img1Ij48YnI+DQo8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj4NCkZyb206ICZxdW90OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KRGF0ZTogRnJpZGF5LCA0IEp1bHkgMjAxNCA5OjEyIHBtPGJyPg0KVG86ICZxdW90 OzxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmciPmktZC1hbm5vdW5jZUBpZXRm Lm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmci PmktZC1hbm5vdW5jZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KQ2M6ICZxdW90OzxhIGhyZWY9Im1h aWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K U3ViamVjdDogW3J0Y3dlYl0gSS1EIEFjdGlvbjo8YnI+DQpkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVu LWNvbnNlbnQtZnJlc2huZXNzLTA1LnR4dDxicj4NCjxicj4NCiZndDs8YnI+DQomZ3Q7QSBOZXcg SW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJh ZnRzPGJyPg0KJmd0O2RpcmVjdG9yaWVzLjxicj4NCiZndDsgVGhpcyBkcmFmdCBpcyBhIHdvcmsg aXRlbSBvZiB0aGUgUmVhbC1UaW1lIENvbW11bmljYXRpb24gaW4gV0VCLWJyb3dzZXJzPGJyPg0K Jmd0O1dvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuPGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGl0bGUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyA6IFNUVU4gVXNhZ2UgZm9yIENvbnNlbnQgRnJlc2huZXNzPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtBdXRob3JzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6 IE11dGh1IEFydWwgTW96aGkgUGVydW1hbDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7RGFuIFdpbmc8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO1JhbSBNb2hhbiBSYXZpbmRyYW5hdGg8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO1RpcnVtYWxlc3dhciBSZWRkeTxicj4NCiZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7TWFydGluIFRob21zb248YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IEZpbGVuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogZHJhZnQtaWV0 Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0wNS50eHQ8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IFBhZ2VzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiA5 PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBEYXRlICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiAyMDE0LTA3LTA0PGJyPg0KJmd0Ozxicj4NCiZndDtBYnN0 cmFjdDo8YnI+DQomZ3Q7ICZuYnNwOyBUbyBwcmV2ZW50IHNlbmRpbmcgZXhjZXNzaXZlIHRyYWZm aWMgdG8gYW4gZW5kcG9pbnQsIHBlcmlvZGljIGNvbnNlbnQ8YnI+DQomZ3Q7ICZuYnNwOyBuZWVk cyB0byBiZSBvYnRhaW5lZCBmcm9tIHRoYXQgcmVtb3RlIGVuZHBvaW50Ljxicj4NCiZndDs8YnI+ DQomZ3Q7ICZuYnNwOyBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIGNvbnNlbnQgbWVjaGFuaXNt IHVzaW5nIGEgbmV3IFNUVU4gdXNhZ2UuPGJyPg0KJmd0OyAmbmJzcDsgVGhpcyBzYW1lIG1lY2hh bmlzbSBjYW4gYWxzbyBkZXRlcm1pbmUgY29ubmVjdGlvbiBsb3NzICgmcXVvdDtsaXZlbmVzcyZx dW90Oyk8YnI+DQomZ3Q7ICZuYnNwOyB3aXRoIGEgcmVtb3RlIHBlZXIuPGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMg ZHJhZnQgaXM6PGJyPg0KJmd0OzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MvIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGN3ZWIt c3R1bi1jb25zZW50LWZyZXNobmVzcy88L2E+PGJyPg0KJmd0Ozxicj4NCiZndDtUaGVyZSdzIGFs c28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDo8YnI+DQomZ3Q7PGEgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZy ZXNobmVzcy0wNSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtMDU8L2E+PGJyPg0KJmd0Ozxi cj4NCiZndDtBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6 PGJyPg0KJmd0OzxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25z ZW50LWZyZXNobmVzcy08L2E+PGJyPg0KJmd0OzA1PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQom Z3Q7UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Y8YnI+DQomZ3Q7c3VibWlzc2lvbjxicj4NCiZndDt1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCiZn dDs8YnI+DQomZ3Q7SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1v dXMgRlRQIGF0Ojxicj4NCiZndDs8YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzLyIgdGFyZ2V0PSJfYmxhbmsiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7cnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCiZndDs8 YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0K Jmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2Vi IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y dGN3ZWI8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv OnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PGJyPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPGJyIGNsZWFyPSJhbGwi Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCi0tIDxicj4NCjxkaXYgZGlyPSJsdHIiPkFsZXguIEdvdWFp bGxhcmQsIFBoRCwgUGhELCBNQkENCjxkaXY+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9k aXY+DQo8ZGl2PkNUTyAtIFRlbWFzeXMgQ29tbXVuaWNhdGlvbnMsIFMncG9yZSAvIE1vdW50YWlu IFZpZXc8L2Rpdj4NCjxkaXY+UHJlc2lkZW50IC0gQ29TTW8gU29mdHdhcmUsIENhbWJyaWRnZSwg TUE8L2Rpdj4NCjxkaXY+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9kaXY+DQo8ZGl2Pjxh IGhyZWY9Imh0dHA6Ly9zZy5saW5rZWRpbi5jb20vYWdvdWFpbGxhcmQiIHRhcmdldD0iX2JsYW5r Ij5zZy5saW5rZWRpbi5jb20vYWdvdWFpbGxhcmQ8L2E+PC9kaXY+DQo8ZGl2Pg0KPHVsIHN0eWxl PSJtYXJnaW46MHB4O3BhZGRpbmc6MHB4IDBweCA4cHg7Ym9yZGVyOjBweDtvdXRsaW5lOjBweDtm b250LXNpemU6MTJweDtmb250LWZhbWlseTpIZWx2ZXRpY2EsQXJpYWwsc2Fucy1zZXJpZjt2ZXJ0 aWNhbC1hbGlnbjpiYXNlbGluZTtsaXN0LXN0eWxlOm5vbmU7bGluZS1oZWlnaHQ6MTdweDtkaXNw bGF5OnRhYmxlLWNlbGw7d2lkdGg6NTA0cHg7Y29sb3I6cmdiKDUxLDUxLDUxKSI+DQo8bGkgc3R5 bGU9Im1hcmdpbjowcHg7cGFkZGluZzo4cHggMTJweCAycHggMHB4O2JvcmRlcjowcHg7b3V0bGlu ZTowcHg7Zm9udC1zdHlsZTppbmhlcml0O2ZvbnQtc2l6ZToxMXB4O2ZvbnQtZmFtaWx5OmluaGVy aXQ7dmVydGljYWwtYWxpZ246YmFzZWxpbmU7Zm9udC12YXJpYW50OmluaGVyaXQ7bGluZS1oZWln aHQ6MS4yZW0iPg0KPGRsIHN0eWxlPSJtYXJnaW46MHB4O3BhZGRpbmc6MHB4O2JvcmRlcjowcHg7 b3V0bGluZTowcHg7Zm9udC1zdHlsZTppbmhlcml0O2ZvbnQtZmFtaWx5OmluaGVyaXQ7dmVydGlj YWwtYWxpZ246YmFzZWxpbmU7Zm9udC12YXJpYW50OmluaGVyaXQ7bGluZS1oZWlnaHQ6aW5oZXJp dDt3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8YnI+DQo8L2RsPg0KPC9saT48L3VsPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_CFE0A3DD940ACrmohanrciscocom_-- From nobody Mon Jul 7 12:40:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00EAC1B28A3 for ; Mon, 7 Jul 2014 12:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 twYY6alvRWUm for ; Mon, 7 Jul 2014 12:39:57 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF4591A0AEE for ; Mon, 7 Jul 2014 12:39:56 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b13so4833184wgh.11 for ; Mon, 07 Jul 2014 12:39:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LJN2j9cgY75AbfVItuDlfbDAa2xWnj99MsyXiPZTego=; b=WMGhxMIQoFwr8pQ74XqpnSE47fkqVt2BIMLfaX27Lgu9z5dMa6rHlQu/MM6JRVPbem H9AISRZnq7LXovQJMgOnTsHA4wYcEq1OTxtwrb1h0wF6BEudHKWaayfMcN1OPIzmlxzQ IKUQWEX+9YT+XKfG377aoMIKluQUP2yrecyhpUri7HufZfpFIWxwvZYjBDpZ17JD/YXq R9iVNQ8KMonN9at7UoJfX5cs0MPBDQr/8yugjfMn0QtH/v2hfBaydCls/9jdgzEcLJ2b YsTYe1zFqOx1hRKtLrVv0B4W+U7hreRHxS/e/NhJzH2XdOP6krzp3i2IhG2EwFYDBnHu 427g== X-Gm-Message-State: ALoCoQlttZInxFdUK+Wtc37bSSL49KPl19f1Y97MtW8TS02qQpuvyteV99voLvnBUOiG5rIOXccZ X-Received: by 10.181.13.80 with SMTP id ew16mr38896220wid.51.1404761995197; Mon, 07 Jul 2014 12:39:55 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) by mx.google.com with ESMTPSA id n2sm89006730wjf.40.2014.07.07.12.39.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jul 2014 12:39:54 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id q58so4957264wes.2 for ; Mon, 07 Jul 2014 12:39:53 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.92.177 with SMTP id cn17mr35334313wjb.71.1404761993736; Mon, 07 Jul 2014 12:39:53 -0700 (PDT) Received: by 10.217.131.17 with HTTP; Mon, 7 Jul 2014 12:39:53 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D3B608F@ESESSMB209.ericsson.se> Date: Mon, 7 Jul 2014 15:39:53 -0400 Message-ID: From: Roman Shpount To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7beb91aaa179e704fd9fa383 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1xFjMMORp17i1Tx3J7Pb3f5IHUQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about ICE-Lite server X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 19:39:58 -0000 --047d7beb91aaa179e704fd9fa383 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 7, 2014 at 6:25 AM, I=C3=B1aki Baz Castillo wro= te: > 2014-07-07 11:03 GMT+02:00 Christer Holmberg < > christer.holmberg@ericsson.com>: > > I also we more or less had agreed on this in the past, that ICE-Lite is > ok e.g. for gateways. > > Oh, and also for much more interesting servers than gateways! :) > > > I also agree that ICE-Lite must be supported and regular nomination should be used with it to avoid timing issues. Also, I wanted to make sure it would be possible to use ICE-TCP with an ICE-Lite with WebRTC end-points. Using ICE-TCP with ICE-Lite would probably create a simplest possible way to implement services that only need to setup client to server communications since they would be able to operate without the need for separate STUN and TURN servers. I have a question regarding ICE-Lite support with IPv6: Does anybody currently actively uses ICE-Lite with hosts that include both IPv4 and IPv6 candidates? I always felt that exact operation of such servers was under-defined, so any real world experience would be extremely interesting. _____________ Roman Shpount --047d7beb91aaa179e704fd9fa383 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jul 7, 2014 at 6:25 AM, I=C3=B1aki Baz Castillo <<= a href=3D"mailto:ibc@aliax.net" target=3D"_blank">ibc@aliax.net> wrote:
2014-07-07 11:03 GMT+02:00 Christer Holmberg <christer.holmberg@ericsson.com>:
> I also we more or less had agreed on this in the past,= that ICE-Lite is ok e.g. for gateways.

Oh, and also for much more interesting servers than gateways! :)





I have a question regarding ICE-Lite support with IPv6:= Does anybody currently actively uses ICE-Lite with hosts that include both= IPv4 and IPv6 candidates? I always felt that exact operation of such serve= rs was under-defined, so any real world experience would be extremely inter= esting.

_____________
Roman Shpount
=C2= =A0
--047d7beb91aaa179e704fd9fa383-- From nobody Mon Jul 7 12:46:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5311B28B4 for ; Mon, 7 Jul 2014 12:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYiT3XMOuPBH for ; Mon, 7 Jul 2014 12:46:31 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC10B1B28AB for ; Mon, 7 Jul 2014 12:46:30 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so16587305wib.5 for ; Mon, 07 Jul 2014 12:46:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MBhe/AIvukS713oXUG01itBp3vkUD96SXBbmIvtV7mc=; b=e9CZ3KSiQwaKukKpiaX9qamDe4BhgAfiyNblrFIxtNCqNWD712QSbOKH+os9Bj11ej tp10uxPnThVBQ/vHIYkm+CHwwfbojwlodgCOViOZ2OTasp2rZ72SJId3RKXGJplUrzjK H1B40IeWHpv6QdpN25M7tZuAX0lFHhMkdEg5UYmO8AMWckOej1TOzVYdvQju5tzplTAT IWVBNvi/mVK0T9suzR35j3jfhvkS2sB9kQkHwtNZ/Vu3AB/U92dplYWEtOpnfgdZ3//U 02Qb7JY1gaZQ6Ej1aTMQTqQWXfHiLaJLcoe/D7uvCc2Sj884+9eKH+Cl0OW/zBzyFy50 8z+w== X-Gm-Message-State: ALoCoQlr2unTT+lj3zxdb12vA0cC2boNpdsJtShnfeUE599yvUGQ4eCMokRcb+FUyoyq6e8RGMRq X-Received: by 10.180.76.134 with SMTP id k6mr49373085wiw.49.1404762389484; Mon, 07 Jul 2014 12:46:29 -0700 (PDT) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by mx.google.com with ESMTPSA id bq7sm118556587wib.7.2014.07.07.12.46.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jul 2014 12:46:28 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id x48so4874187wes.37 for ; Mon, 07 Jul 2014 12:46:28 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.20.230 with SMTP id q6mr35153192wje.43.1404762388321; Mon, 07 Jul 2014 12:46:28 -0700 (PDT) Received: by 10.217.131.17 with HTTP; Mon, 7 Jul 2014 12:46:28 -0700 (PDT) In-Reply-To: <53B91327.50401@alvestrand.no> References: <53B91327.50401@alvestrand.no> Date: Mon, 7 Jul 2014 15:46:28 -0400 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=047d7b5d971b265de204fd9fbb89 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xieIEcTBIC6ke3LFHBRAQAVx6dY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about ICE-Lite server X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 19:46:32 -0000 --047d7b5d971b265de204fd9fbb89 Content-Type: text/plain; charset=UTF-8 > > To me this sounds like "can an endpoint participate in ICE without > participating in the exchange of candidates" - and my immediate reaction is > "if it could, it would be a security risk". > > I don't think it's possible. And I think that's a Good Thing. > > Since ICE-Lite server does not send any connectivity checks, it can operate with virtually no information about the remote side. It certainly does not need any information about the candidates. All it cares about that the other side supports ICE, if there was an ICE mismatch and if remote side is full or lite implementation. All checks from remote side are validated using the local password. If remote side is lite or does not support ICE media can be sent immediately, otherwise it will need to wait for a connectivity check with the use attribute. Very, very simple. _____________ Roman Shpount --047d7b5d971b265de204fd9fbb89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To me this sounds like "can an endpoint participate in= ICE without participating in the exchange of candidates" - and my imm= ediate reaction is "if it could, it would be a security risk".

I don't think it's possible. And I think that's a Good Thing.

Since ICE-Lite s= erver does not send any connectivity checks, it can operate with virtually = no information about the remote side. It certainly does not need any inform= ation about the candidates. All it cares about that the other side supports= ICE, if there was an ICE mismatch and if remote side is full or lite imple= mentation. All checks from remote side are validated using the local passwo= rd. If remote side is lite or does not support ICE media can be sent immedi= ately, otherwise it will need to wait for a connectivity check with the use= attribute. Very, very simple.
_____________
Roman Shpount
=C2=A0
--047d7b5d971b265de204fd9fbb89-- From nobody Mon Jul 7 12:48:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4525D1B28C9 for ; Mon, 7 Jul 2014 12:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbdlTGqODjHg for ; Mon, 7 Jul 2014 12:48:43 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA921B28B8 for ; Mon, 7 Jul 2014 12:48:43 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id b13so4850761wgh.26 for ; Mon, 07 Jul 2014 12:48:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=dz+n920rZZT3ndbjogoRE42vPmr3mabH7x6u8oXXZy4=; b=aDP0JbYaNITfGtKG/OGORJQc6EG4o5+zkWgTVDaC0eVU5pWuf1abU1JCD9xnsOrCQB 4OX1GBxtfdqWa7o8uWlGLVLWvDJs049cyv8gEieHmMxqnuug2wk6oCPlPOODVrwCT504 da3YREpfJDV2IfxTjoH12wBUTs2WrRUQcwJkx80nd0l6gTkLKcc/ue0HSnStvEIYxK4E bAFckCgSu3fIgT2V4V+iZ1hmDNIC2xr6uLwEOJTn42LfNdOzAVIvgwquQVIq9qM2x8uf t1lDtA0OWMyGOxqIwe1x3n8SOMBo5aiuv79WyoN0wZOhjBPBRG4PD+IsJylYGi49rEAy t3Ag== X-Gm-Message-State: ALoCoQnqyOpRryW3OEBKPEl41fQudFZSAtbtF8jQbdmyzbYwHDi5iwnJ8ZIu3XI7kmyMExqRxaEY X-Received: by 10.194.216.196 with SMTP id os4mr28165911wjc.70.1404762521844; Mon, 07 Jul 2014 12:48:41 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by mx.google.com with ESMTPSA id ft2sm109506562wib.1.2014.07.07.12.48.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jul 2014 12:48:40 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n3so16640186wiv.15 for ; Mon, 07 Jul 2014 12:48:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.74.9 with SMTP id p9mr39380398wiv.39.1404762520691; Mon, 07 Jul 2014 12:48:40 -0700 (PDT) Received: by 10.217.131.17 with HTTP; Mon, 7 Jul 2014 12:48:40 -0700 (PDT) Date: Mon, 7 Jul 2014 15:48:40 -0400 Message-ID: From: Roman Shpount To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c81aa0a2d2204fd9fc354 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Cy9m2FSPS9oW6YYm2HntPIaok-s Subject: [rtcweb] ICE-Mismatch and WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 19:48:44 -0000 --f46d043c81aa0a2d2204fd9fc354 Content-Type: text/plain; charset=UTF-8 Is it possible to run into ICE-Mismatch with WebRTC? Should we specify that default candidate (c= and m= line based candidate) should be ignored and thus mismatch check should not be performed? _____________ Roman Shpount --f46d043c81aa0a2d2204fd9fc354 Content-Type: text/html; charset=UTF-8
Is it possible to run into ICE-Mismatch with WebRTC? Should we specify that default candidate (c= and m= line based candidate) should be ignored and thus mismatch check should not be performed?
_____________
Roman Shpount
--f46d043c81aa0a2d2204fd9fc354-- From nobody Mon Jul 7 12:51:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477021B28AB for ; Mon, 7 Jul 2014 12:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6z5wxKtyoZER for ; Mon, 7 Jul 2014 12:51:36 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88B1E1B289C for ; Mon, 7 Jul 2014 12:51:35 -0700 (PDT) Received: from [192.168.1.200] (p54819C6D.dip0.t-ipconnect.de [84.129.156.109]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 08CCC1C104925; Mon, 7 Jul 2014 21:51:31 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <53B90103.7010907@nteczone.com> Date: Mon, 7 Jul 2014 21:51:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D35B976@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D35CD5E@ESESSMB209.ericsson.se> <53A7BF3E.8010505@nteczone.com> <53B90103.7010907@nteczone.com> To: Christian Groves X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DHZOtPHNq2DJ_WoKVyTowiTXlVY Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WGLC for data channel drafts - sub-protocol usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 19:51:37 -0000 On 06 Jul 2014, at 09:55, Christian Groves = wrote: > The definition of Token is ASCII not UTF-8. OK, I can change it to ASCII. Any objections? Best regards Michael >=20 > Christian >=20 > On 5/07/2014 3:23 AM, Michael Tuexen wrote: >> On 23 Jun 2014, at 07:46, Christian Groves = wrote: >>=20 >>> Do you need that statement? >> I guess formally you don't. But having it make it simpler for the = reader... >>=20 >> Best regards >> Michael >>> [RFC6455] section 11.5 says: >>>=20 >>> Subprotocol Identifier >>> The identifier of the subprotocol, as will be used in the >>> |Sec-WebSocket-Protocol| header field registered in Section = 11.3.4 >>> of this specification. The value must conform to the = requirements >>> given in item 10 of Section 4.1 of this specification -- = namely, >>> the value must be a token as defined by RFC 2616 [RFC2616]. >>>=20 >>> "Token" is RFC2616 is defined as: >>> CHAR =3D >>> token =3D 1* >>>=20 >>> Regards, Christian >>>=20 >>> On 12/06/2014 3:24 AM, Christer Holmberg wrote: >>>> Hi Michael, >>>>=20 >>>> I agree that we need to keep text about the encoding. >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>> ________________________________________ >>>> From: Michael Tuexen [Michael.Tuexen@lurchi.franken.de] >>>> Sent: Wednesday, 11 June 2014 5:28 PM >>>> To: Christer Holmberg >>>> Cc: Ted Hardie; rtcweb@ietf.org >>>> Subject: Re: [rtcweb] WGLC for data channel drafts - sub-protocol = usage >>>>=20 >>>> On 10 Jun 2014, at 21:22, Christer Holmberg = wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> A comment on draft-ietf-rtcweb-data-protocol-06: >>>>>=20 >>>>> Section 5.1 says: >>>>>=20 >>>>> "Protocol: Variable Length (sequence of characters) >>>>> The sub-protocol for the channel as a UTF-8 encoded string. = If >>>>> this is an empty string the protocol is unspecified. If it = is a >>>>> non-empty string, it specifies an protocol registered in the >>>>> 'WebSocket Subprotocol Name Registry' created in [RFC6455]." >>>>>=20 >>>>>=20 >>>>> I think "The sub-protocol for the channel as a UTF-8 encoded = string." part is a little confusing, because there is no such thing as = sub-protocol in DCEP itself (DCEP only uses the WebSocket sub-protocol = registry for registering DCEP *protocol* values). >>>>>=20 >>>>> Perhaps we could just remove the sentence, and keep: >>>>>=20 >>>>> "Protocol: Variable Length (sequence of characters) >>>>> If this is an empty string the protocol is unspecified. If = it is a >>>>> non-empty string, it specifies an protocol registered in the >>>>> 'WebSocket Subprotocol Name Registry' created in [RFC6455]." >>>>>=20 >>>>> Section 4 gives more information about the usage of the protocol. >>>> Do you intend to drop the statement about the UTF-8 encoding? >>>> I think we should keep a statement about the encoding. >>>>=20 >>>> Best regards >>>> Michael >>>>> (Alternatively, we could use sub-protocol terminology also in = DCEP) >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Ted Hardie = [ted.ietf@gmail.com] >>>>> Sent: Tuesday, 10 June, 2014 9:52 PM >>>>> To: rtcweb@ietf.org >>>>> Subject: [rtcweb] WGLC for data channel drafts >>>>>=20 >>>>> Dear WG, >>>>>=20 >>>>> This starts a working group last call for our core Data Channel = drafts: >>>>>=20 >>>>> draft-ietf-rtcweb-data-protocol-06.txt >>>>> draft-ietf-rtcweb-data-channel-10.txt >>>>>=20 >>>>> Please review them in detail, especially for areas which may be of = concern to the broader IETF community. This WGLC will end on June 27, = 2014. >>>>>=20 >>>>> Ted, Sean, Cullen >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>=20 >=20 >=20 From nobody Mon Jul 7 13:01:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90711A0515 for ; Mon, 7 Jul 2014 13:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zD-FCxg4aUFC for ; Mon, 7 Jul 2014 13:00:57 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA721B289C for ; Mon, 7 Jul 2014 13:00:51 -0700 (PDT) Received: from [192.168.1.200] (p54819C6D.dip0.t-ipconnect.de [84.129.156.109]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id DC3311C104925; Mon, 7 Jul 2014 22:00:48 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <53B797C1.3080609@omnitor.se> Date: Mon, 7 Jul 2014 22:00:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <596034E6-7D76-4F82-AFD3-521B8C0217B8@lurchi.franken.de> References: <53B71B6E.2010604@omnitor.se> <470AD025-E40B-43BD-B141-599489FB892C@lurchi.franken.de> <53B797C1.3080609@omnitor.se> To: Gunnar Hellstrom X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Va-prhPqooexwOcpqS43MPjPd54 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WGLC for data channel drafts - missing descriptions of error situations X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 20:01:02 -0000 On 05 Jul 2014, at 08:14, Gunnar Hellstrom = wrote: > On 2014-07-04 23:34, Michael Tuexen wrote: >> On 04 Jul 2014, at 23:23, Gunnar Hellstrom = wrote: >>=20 >>> I cannot find that what happens in transmission error situations is = described in any of these drafts. >>>=20 >>> Both reliable and partially reliable transmission can fail, and the = application designer need to know what happens. >> I don't understand the notion of "reliable and partially reliable = transmission can fail"... >> If a user message gets abandoned (so the stack gives up = transmitting/retransmitting it, but >> the association stays alive), I don't think it is signalled via the = JS API, but that might >> be an issue of W3C. If the association fails, all data channel fail. = This is signalled. >> However, this is something for the W3C document. > The W3C mechanism makes use of the rtcweb-data-channel. > The rtcweb-data-channel should tell what happens in error situations = and if that is possible to be signaled to higher layers. > The higher layers should have specified the requirements on the = data-channel. > If no requirements can be found, we should either propose behavior in = error situations or request to get requirements stated from upper = layers. SCTP tells the user if the association has failed. At that point all = data channels must be closed. But I think this is something which needs to be stated = in the W3C document... >>> We discussed it earlier, and came to the conclusion that >>> A failing reliable channel will tear down the connection and some = indication will be provided if possible to the application. >>> A failing partially reliable channel will enable transmission of = next data item. ( I do not remember if the application will get any = error indication or if it needs to have its own sequence checking if it = is interested in knowing if there are no gaps. ) >>>=20 >>> I suggest that a section on failure handling is added. I get the = impression that it is in the data-channel draft it would be best suited. >> But this is about the API. So it should go into the W3C document. > The API can only provide the functions provided by the mechanisms it = has underneath. >=20 > There was a mail discussion in webRTC about the error situations. > A conclusion was that if a reliable channel reaches its retry limit ( = that is usually only about 5 for WebRTC) or some other indication that = the channel failed to convey the data, then the channel shall be broken = (by the channel) and indications provided to both sides if possible. = (another reasons mentioned was missed heartbeats for the whole = association, setting a retry time limit of - what was it - - - 15 = seconds?) A reliable channel doesn't have a limit. The association has. If the = association breaks, all data channels are gone. >=20 > If the retries or retransmission time is exceeded for a partially = reliable channel, the conclusion was that communication can continue = with next data item. I am not sure if the applications were to=20 It will continue. It is not a stop and wait... > get any notification about that or if they need to introduce sequence = number checking themselves if they are interested to know. I don't think so. I don't see anything in the JS API. >=20 >=20 >=20 > I cannot see how we can avoid describing the mechanisms needed and = what happens to the channel. >=20 >=20 > I found a sentence about this in section 6.6 of the data-channel-11 = draft. >=20 > " >=20 > If a message with an unsupported PPID is received or some error is > detected by the receiver (for example, illegal ordering), the > receiver SHOULD close the corresponding data channel." >=20 >=20 > This paragraph could be extended to tell more about error situations = in open channels. > I suggest to move this sentence to a new section and add description = of other situations. The sentence only tells about errors detected at = the receiving end. But it can also be the transmitting end that detects = the problem. It should be stated what shall be done then.T >=20 > Something like this ( with my questions in paranthesis). > -------------------------------------------------------Proposed error = handling section in = rtcweb-data-channel-------------------------------------------------------= -------------------- > 6.7 Transmission failure and error handling > Failures can occur when a data channel is open. >=20 > If transmission in a reliable channel fails, the channel shall be = closed by the party detecting the failure and an error indication = provided. ( what does STCP do in this situation? ) This can't happen. Only the association can fail and in this case all = data channels are gone... >=20 > If a watchdog times out, the channel shall be closed with an error = indication. ( if this is part of the channel mechanisms, I have = not seen where it is defined.) If you think about SCTP HEARTBEATs, it is like the above. But it is more = likely that ICE will detect it first. >=20 > If retransmissions or transmission time is exceeded in a partially = reliable channel, the transmission SHALL be allowed to continue with = next data item. It is not stop and wait... next item might be transmitted before the = message is abandoned. >=20 > If reception out-of order is detected from an SCTP channel for which = ordered transmission is requested, the receiver SHALL close the data = channel. This is covered by the text cited above. >=20 > If a message with an unsupported PPID is received or some logical = error is detected by the receiver, the receiver SHALL close the = corresponding data channel. This is covered by the text cited above. So I think the only thing not covered is what to do if the SCTP = association fails, but it is obvious to me that all channels are gone. Do we need to state = that explicitly? What do others think? Best regards Michael > --------------------End of proposed section on failure = handling------------------------------------------------------------------= --------------------------------------------------------- >=20 >=20 >=20 > Regards >=20 > /Gunnar >=20 >>=20 >> Best regards >> Michael >>> Regards >>>=20 >>> Gunnar >>> Gunnar Hellstr=F6m >>> Omnitor >>> gunnar.hellstrom@omnitor.se >>> On 2014-06-10 20:52, Ted Hardie wrote: >>>> Dear WG, >>>>=20 >>>> This starts a working group last call for our core Data Channel = drafts: >>>>=20 >>>> draft-ietf-rtcweb-data-protocol-06.txt >>>> draft-ietf-rtcweb-data-channel-10.txt >>>>=20 >>>> Please review them in detail, especially for areas which may be of = concern to the broader IETF community. This WGLC will end on June 27, = 2014. >>>>=20 >>>> Ted, Sean, Cullen >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> rtcweb mailing list >>>>=20 >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 From nobody Mon Jul 7 13:29:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79C91B28D8 for ; Mon, 7 Jul 2014 13:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 afcXdH6bXQQt for ; Mon, 7 Jul 2014 13:29:30 -0700 (PDT) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 817341B28C6 for ; Mon, 7 Jul 2014 13:29:30 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id f51so4075714qge.22 for ; Mon, 07 Jul 2014 13:29:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=acfCgDmCxFAxKNOOVM6wkGRqMsHpBMowrcUrx2WHItg=; b=OFDCvdx/kn8RPieJC5DrcGAhGBGidgweqb6gVjV+Oj8pEiS+mSWjKDYJmeGN0agdf2 Xz96FRD9LXCU2PUZt6b3QzrAuTIhrhAuGJihCRCIf+QCuKtlr9RIr+uVxbdXHq2w7PNR x0muiCHPc/emGIG0WO/kBfN7JES/iTvZ9/lPM6UWngEOB4Vb04phg6ze0x4zYmdAnIAr 6QExm2c8APRgcXQaV+Z02EdDapN5VR33nFj/uuh4VdMvF0d+C/0SBjU5dn9hFR3s216v S9+7fgv6Yl66kDTLRLzXylqx8rr06YMOjYQ6t+f79T67cZboosguiZJoNkYp5o3uvy4b LYsw== X-Gm-Message-State: ALoCoQmpbV0FSzWvt2gCybWK7yFYv6COAyhqXBFFDXWNB5dZk5gj0xknYD9koRXuqvjFUh2BGISd MIME-Version: 1.0 X-Received: by 10.140.40.81 with SMTP id w75mr49774945qgw.112.1404764969713; Mon, 07 Jul 2014 13:29:29 -0700 (PDT) Received: by 10.96.234.131 with HTTP; Mon, 7 Jul 2014 13:29:29 -0700 (PDT) Received: by 10.96.234.131 with HTTP; Mon, 7 Jul 2014 13:29:29 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 Jul 2014 22:29:29 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Roman Shpount Content-Type: multipart/alternative; boundary=001a11c15154035bf404fda0555d Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/czeb_bGag9pILUCAsIsNz2upxW8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] ICE-Mismatch and WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 20:29:32 -0000 --001a11c15154035bf404fda0555d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes please. -- I=C3=B1aki Baz Castillo On Jul 7, 2014 9:50 PM, "Roman Shpount" wrote: > Is it possible to run into ICE-Mismatch with WebRTC? Should we specify > that default candidate (c=3D and m=3D line based candidate) should be ign= ored > and thus mismatch check should not be performed? > _____________ > Roman Shpount > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11c15154035bf404fda0555d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Yes please.

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

On Jul 7, 2014 9:50 PM, "Roman Shpount"= ; <roman@telurix.com> wrote:=
Is it possible to run into ICE-Mismatch with WebRTC? Shoul= d we specify that default candidate (c=3D and m=3D line based candidate) sh= ould be ignored and thus mismatch check should not be performed?
_____________
Roman Shpount

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

--001a11c15154035bf404fda0555d-- From nobody Mon Jul 7 14:27:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0C81B28E6 for ; Mon, 7 Jul 2014 14:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 xhEA4DwszqpK for ; Mon, 7 Jul 2014 14:27:49 -0700 (PDT) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 356B51B292B for ; Mon, 7 Jul 2014 14:27:49 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id r5so4443373qcx.11 for ; Mon, 07 Jul 2014 14:27:48 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=rezawAoylPL6nOzNQvdh88wX9k6BeUif3pI1bjUNCRQ=; b=Zg/imlhDGLxtrOX9ZwbYV8TdbYBRJM47I1T0yWb8n8hY1sXWl/GgxrXsITTAb+xV0x BoyBG0ZsndvwL3ld208QH0FSTEx2osGW/K7vkQ0EF63PrK9Cl3hC1EGUINoTMMbeZ3TX BPoBxa5wYRCmoJl+4Wg0VGsR/5KjLcKDqIBdjTgy/77ZZTfhG/OZgt5dagVngEqASB3e dgz1qWMfC7vhtHh+Kt3fk0wnxWTKWGNVsT6Ak2kSe7DnUOrVCPeg9EAujK4zq39qjBKH 1wxjEqUxY8Ojej+7w65rLqknloOrMMX1XbF6WrXtHSlVkGi0zoEdKP9UU4cUFBE1b3tU 1xxQ== X-Gm-Message-State: ALoCoQn+OZXV9s3OVvYmsSuenmtuoXFm075WEEFNw0nxkYqXAeck/fQQ/ilAzN2AXeuQ4Uzro0pH X-Received: by 10.224.87.130 with SMTP id w2mr52410591qal.5.1404768468438; Mon, 07 Jul 2014 14:27:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.234.131 with HTTP; Mon, 7 Jul 2014 14:27:28 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D3B608F@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 7 Jul 2014 23:27:28 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VuCvLwowgN_Zige3oOtzkDjYr7c Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about ICE-Lite server X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 21:27:50 -0000 2014-07-07 21:39 GMT+02:00 Roman Shpount : > I have a question regarding ICE-Lite support with IPv6: Does anybody > currently actively uses ICE-Lite with hosts that include both IPv4 and IP= v6 > candidates? I always felt that exact operation of such servers was > under-defined, so any real world experience would be extremely interestin= g. I'm doing that exactly now. I don't see major problems, this is, the server just listens into varios sockets (IPv4 and IPv6) for the same "component" and selects the first 5-tuple from which it receives a STUN request with USE-CANDIDATE. --=20 I=C3=B1aki Baz Castillo From nobody Mon Jul 7 14:30:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FD91B28B6 for ; Mon, 7 Jul 2014 14:30:21 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spPx0pjurCFd for ; Mon, 7 Jul 2014 14:30:10 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0190.outbound.protection.outlook.com [207.46.163.190]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D701D1B2933 for ; Mon, 7 Jul 2014 14:29:54 -0700 (PDT) Received: from BLUPR03MB405.namprd03.prod.outlook.com (10.141.78.15) by BLUPR03MB408.namprd03.prod.outlook.com (10.141.78.25) with Microsoft SMTP Server (TLS) id 15.0.974.11; Mon, 7 Jul 2014 21:29:52 +0000 Received: from BLUPR03MB405.namprd03.prod.outlook.com ([10.141.78.15]) by BLUPR03MB405.namprd03.prod.outlook.com ([10.141.78.15]) with mapi id 15.00.0974.002; Mon, 7 Jul 2014 21:29:53 +0000 From: Shijun Sun To: Michael Tuexen , Eric Rescorla Thread-Topic: [rtcweb] DTLS version Thread-Index: AQHPlpICeV5LRgJomEee9jrC1yXJQ5uN+SAAgAAOY4CAAJwqgIAA7SgAgAAmEYCAAJ3nAIAAFyaAgAACUACAAAJLAIAErRgw Date: Mon, 7 Jul 2014 21:29:51 +0000 Message-ID: References: <6355614E-44DA-4729-97C2-E903548EBA8B@gmail.com> <949EF20990823C4C85C18D59AA11AD8B1FC18D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <53B660BC.4090907@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8B1FD11D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <9D7AEC5F-2955-4044-B8DE-A80006994AEB@lurchi.franken.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.160.140] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-forefront-prvs: 02652BD10A x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(199002)(189002)(479174003)(377454003)(51704005)(24454002)(107046002)(46102001)(561944003)(19580405001)(93886003)(66066001)(74316001)(4396001)(77982001)(76576001)(85306003)(83322001)(105586002)(76482001)(79102001)(31966008)(20776003)(21056001)(106116001)(101416001)(99396002)(81542001)(76176999)(54356999)(81342001)(92566001)(74662001)(2656002)(95666004)(80022001)(85852003)(99286002)(106356001)(50986999)(83072002)(15975445006)(33646001)(86612001)(64706001)(87936001)(86362001)(74502001)(19580395003)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB408; H:BLUPR03MB405.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/n8c6G3VCX2y9fCzOFqk4JsmbeWw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS version X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 21:30:21 -0000 There seems a preference on supporting DTLS 1.0 due to the widespread adopt= ion. There is also a desire of supporting ECDHE when ECC is on a Standards= Track. Hope we could reach a consensus in Toronto. =20 To keep the discussions going, here is a proposal with a specific cipher su= ite based on DTLS 1.0. =20 All implementations MUST implement the cipher suite TLS_ECDHE_ECDSA_WIT= H_AES_128_CBC_SHA=20 based on DTLS 1.0 with P256 as the curve to be used with ECDHE and ECDS= A. The Implementations=20 MAY advertise additional cipher suites based on DTLS 1.0 and/or DTLS 1.= 2 definitions, for example,=20 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA with P256. We could keep DTLS 1.2 as an optional implementation decision for now and m= ake that (and some corresponding new cipher suites) as required in the futu= re. Thoughts? Best, Shijun=20 -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Michael Tuexen Sent: Friday, July 4, 2014 2:28 PM To: Eric Rescorla Cc: rtcweb@ietf.org Subject: Re: [rtcweb] DTLS version On 04 Jul 2014, at 23:19, Eric Rescorla wrote: >=20 >=20 >=20 > On Fri, Jul 4, 2014 at 2:11 PM, Michael Tuexen wrote: > On 04 Jul 2014, at 21:48, Eric Rescorla wrote: >=20 > > I made this change in the current draft at: > > > > https://github.com/rtcweb-wg/security-arch/commit/c2af2bf7fd032abd36 > > 7dff8d4d16f7ec435fa663 > If implementations MUST implement both DTLS 1.0 and 1.2, when will=20 > they use 1.0? Wouldn't they always use DTLS 1.2? >=20 > There are non-RTCWEB implementations of these protocols. OK. Any suggested test for the SCTP over DTLS spec? It currently says MUST = be based on DTLS 1.0 (as you suggested). Best regards Michael >=20 > -Ekr > =20 > Best regards > Michael > > > > Note that the TLS WG is currently discussing whether to bring ECC onto = Standards Track. > > If they do, we probably want ot require support of ECDHE. We should dis= cuss in YYZ. > > > > > > > > On Fri, Jul 4, 2014 at 3:23 AM, DRAGE, Keith (Keith) wrote: > > This is the direction I am tending in as well. > > > > Although what or if the second statement needs from RFC 2119 language w= ould need to be debated. > > > > Obviously, new versions are not being put out there just to make it loo= k like the WG is performing. In any referencing (not just this issue), I wo= uld need a good technical reason why the latest version cannot be made the = normative reference. I am not seeing that at the moment. > > > > There is always be non-conforming equipment on the market (as an exampl= e look at the number of SIP implementations that still use UDP for large me= ssages, or that can at least be configured that way). Just because we manda= te 1.2 does not mean that everyone will conform from day 1, but at least a = marker is established for what should be addressed if interoperability issu= es are identified. > > > > Keith > > > > > -----Original Message----- > > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald=20 > > > Alvestrand > > > Sent: 04 July 2014 09:07 > > > To: rtcweb@ietf.org > > > Subject: Re: [rtcweb] DTLS version > > > > > > On 07/03/2014 07:58 PM, Martin Thomson wrote: > > > > On 3 July 2014 01:39, DRAGE, Keith (Keith)=20 > > > > wrote: > > > >> Can someone elaborate what this massive apparent step > > > change is from 1.0 to 1.2? > > > > Actually, it's not a massive step. TLS 1.2 (DTLS 1.2 > > > depends on this, > > > > DTLS 1.0 depends on TLS 1.1) adds AEAD modes, but doesn't=20 > > > > require their use, so you can pretty much just bump the version=20 > > > > number and advertise 1.2. That's exactly what we did with NSS,=20 > > > > though NSS already supports TLS 1.2. > > > > > > > > That said, I agree with Jim about 1.0. There's enough 1.0 > > > out there > > > > now to make mandating 1.2 - as much as I might prefer that > > > - a little > > > > too aggressive. > > > > > > > >> Will those implementations that choose to stay with 1.0 > > > still interwork with 1.2? > > > > That depends. We could say "MUST NOT negotiate 1.0", which=20 > > > > would prevent that. I don't think that we're there. > > > > > > Sounds to me like MUST implement 1.2 (in order to move forward),=20 > > > MUST accept 1.0 (in order to not lose the long tail). > > > > > > > > > > > _______________________________________________ > > > > rtcweb mailing list > > > > rtcweb@ietf.org > > > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > _______________________________________________ > > > rtcweb mailing list > > > rtcweb@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Jul 7 15:39:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885A01B28A5 for ; Mon, 7 Jul 2014 15:39:29 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUAcSJfFMl6o for ; Mon, 7 Jul 2014 15:39:26 -0700 (PDT) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) (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 C8F551B281C for ; Mon, 7 Jul 2014 15:39:25 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTPS; Tue, 8 Jul 2014 00:39:36 +0200 (CEST) Received: from [192.168.2.41] (81-224-110-16-no227.business.telia.com [81.224.110.16]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-09-01.atm.binero.net (Postfix) with ESMTPA id AEE9B3A21A; Tue, 8 Jul 2014 00:39:14 +0200 (CEST) Message-ID: <53BB2194.2080601@omnitor.se> Date: Tue, 08 Jul 2014 00:39:16 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Michael Tuexen References: <53B71B6E.2010604@omnitor.se> <470AD025-E40B-43BD-B141-599489FB892C@lurchi.franken.de> <53B797C1.3080609@omnitor.se> <596034E6-7D76-4F82-AFD3-521B8C0217B8@lurchi.franken.de> In-Reply-To: <596034E6-7D76-4F82-AFD3-521B8C0217B8@lurchi.franken.de> Content-Type: multipart/alternative; boundary="------------070103060902050105030101" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QYWmzchOlJbVorLbTwJC7WDtylM Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WGLC for data channel drafts - missing descriptions of error situations X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 22:39:29 -0000 This is a multi-part message in MIME format. --------------070103060902050105030101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Thaks Michael, You provide important additional information added to the section 6.7 on transmission failure handling for the data-channel draft that I proposed below. I cannot find this information anywhere else, so I think it is important to provide it in the data-channel draft so that the W3C API authors can see what mechanisms are available and describe the API from that. You say that the association breaks if a number of retries fail. But cannot the association contain both reliable and partially reliable channels? How would the decision logic to break the association because a number of failures be formed when there are different kinds of channels in the association? Or do I remember wrongly? Is there only one type of channels in an association. You also say that both missed heartbeats and broken ICE connections may break the association. Where do you suggest that that combined behavior should be described? Also in the data-channel draft? Thaks, Gunnar ------------------------------------------------------------------------ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 On 2014-07-07 22:00, Michael Tuexen wrote: > On 05 Jul 2014, at 08:14, Gunnar Hellstrom wrote: > >> On 2014-07-04 23:34, Michael Tuexen wrote: >>> On 04 Jul 2014, at 23:23, Gunnar Hellstrom wrote: >>> >>>> I cannot find that what happens in transmission error situations is described in any of these drafts. >>>> >>>> Both reliable and partially reliable transmission can fail, and the application designer need to know what happens. >>> I don't understand the notion of "reliable and partially reliable transmission can fail"... >>> If a user message gets abandoned (so the stack gives up transmitting/retransmitting it, but >>> the association stays alive), I don't think it is signalled via the JS API, but that might >>> be an issue of W3C. If the association fails, all data channel fail. This is signalled. >>> However, this is something for the W3C document. >> The W3C mechanism makes use of the rtcweb-data-channel. >> The rtcweb-data-channel should tell what happens in error situations and if that is possible to be signaled to higher layers. >> The higher layers should have specified the requirements on the data-channel. >> If no requirements can be found, we should either propose behavior in error situations or request to get requirements stated from upper layers. > SCTP tells the user if the association has failed. At that point all data channels > must be closed. But I think this is something which needs to be stated in the > W3C document... >>>> We discussed it earlier, and came to the conclusion that >>>> A failing reliable channel will tear down the connection and some indication will be provided if possible to the application. >>>> A failing partially reliable channel will enable transmission of next data item. ( I do not remember if the application will get any error indication or if it needs to have its own sequence checking if it is interested in knowing if there are no gaps. ) >>>> >>>> I suggest that a section on failure handling is added. I get the impression that it is in the data-channel draft it would be best suited. >>> But this is about the API. So it should go into the W3C document. >> The API can only provide the functions provided by the mechanisms it has underneath. >> >> There was a mail discussion in webRTC about the error situations. >> A conclusion was that if a reliable channel reaches its retry limit ( that is usually only about 5 for WebRTC) or some other indication that the channel failed to convey the data, then the channel shall be broken (by the channel) and indications provided to both sides if possible. (another reasons mentioned was missed heartbeats for the whole association, setting a retry time limit of - what was it - - - 15 seconds?) > A reliable channel doesn't have a limit. The association has. If the association breaks, > all data channels are gone. >> If the retries or retransmission time is exceeded for a partially reliable channel, the conclusion was that communication can continue with next data item. I am not sure if the applications were to > It will continue. It is not a stop and wait... >> get any notification about that or if they need to introduce sequence number checking themselves if they are interested to know. > I don't think so. I don't see anything in the JS API. >> >> >> I cannot see how we can avoid describing the mechanisms needed and what happens to the channel. >> >> >> I found a sentence about this in section 6.6 of the data-channel-11 draft. >> >> " >> >> If a message with an unsupported PPID is received or some error is >> detected by the receiver (for example, illegal ordering), the >> receiver SHOULD close the corresponding data channel." >> >> >> This paragraph could be extended to tell more about error situations in open channels. >> I suggest to move this sentence to a new section and add description of other situations. The sentence only tells about errors detected at the receiving end. But it can also be the transmitting end that detects the problem. It should be stated what shall be done then.T >> >> Something like this ( with my questions in paranthesis). >> -------------------------------------------------------Proposed error handling section in rtcweb-data-channel--------------------------------------------------------------------------- >> 6.7 Transmission failure and error handling >> Failures can occur when a data channel is open. >> >> If transmission in a reliable channel fails, the channel shall be closed by the party detecting the failure and an error indication provided. ( what does STCP do in this situation? ) > This can't happen. Only the association can fail and in this case all data channels are gone... >> If a watchdog times out, the channel shall be closed with an error indication. ( if this is part of the channel mechanisms, I have not seen where it is defined.) > If you think about SCTP HEARTBEATs, it is like the above. But it is more likely > that ICE will detect it first. >> If retransmissions or transmission time is exceeded in a partially reliable channel, the transmission SHALL be allowed to continue with next data item. > It is not stop and wait... next item might be transmitted before the message is abandoned. >> If reception out-of order is detected from an SCTP channel for which ordered transmission is requested, the receiver SHALL close the data channel. > This is covered by the text cited above. >> If a message with an unsupported PPID is received or some logical error is detected by the receiver, the receiver SHALL close the corresponding data channel. > This is covered by the text cited above. > > So I think the only thing not covered is what to do if the SCTP association fails, > but it is obvious to me that all channels are gone. Do we need to state that > explicitly? What do others think? > > Best regards > Michael >> --------------------End of proposed section on failure handling--------------------------------------------------------------------------------------------------------------------------- >> >> >> >> Regards >> >> /Gunnar >> >>> Best regards >>> Michael >>>> Regards >>>> >>>> Gunnar >>>> Gunnar Hellström >>>> Omnitor >>>> gunnar.hellstrom@omnitor.se >>>> On 2014-06-10 20:52, Ted Hardie wrote: >>>>> Dear WG, >>>>> >>>>> This starts a working group last call for our core Data Channel drafts: >>>>> >>>>> draft-ietf-rtcweb-data-protocol-06.txt >>>>> draft-ietf-rtcweb-data-channel-10.txt >>>>> >>>>> Please review them in detail, especially for areas which may be of concern to the broader IETF community. This WGLC will end on June 27, 2014. >>>>> >>>>> Ted, Sean, Cullen >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> --------------070103060902050105030101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Thaks Michael,
You provide important additional information added to the section 6.7  on transmission failure handling for the data-channel draft that I proposed below. I cannot find this information anywhere else, so I think it is important to provide it in the data-channel draft so that the W3C API authors can see what mechanisms are available and describe the API from that.

You say that the association breaks if a number of retries fail. But cannot the association contain both reliable and partially reliable channels? How would the decision logic to break the association because a number of failures be formed when there are different kinds of channels in the association? Or do I remember wrongly? Is there only one type of channels in an association.

You also say that both missed heartbeats and broken ICE connections may break the association. Where do you suggest that that combined behavior should be described? Also in the data-channel draft?

Thaks,

Gunnar




Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2014-07-07 22:00, Michael Tuexen wrote:
On 05 Jul 2014, at 08:14, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote:


On 2014-07-04 23:34, Michael Tuexen wrote:

On 04 Jul 2014, at 23:23, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote:


I cannot find that what happens in transmission error situations is described in any of these drafts.

Both reliable and partially reliable transmission can fail, and the application designer need to know what happens.

I don't understand the notion of "reliable and partially reliable transmission can fail"...
If a user message gets abandoned (so the stack gives up transmitting/retransmitting it, but
the association stays alive), I don't think it is signalled via the JS API, but that might
be an issue of W3C. If the association fails, all data channel fail. This is signalled.
However, this is something for the W3C document.

The W3C mechanism makes use of the rtcweb-data-channel.
The rtcweb-data-channel should tell what happens in error situations and if that is possible to be signaled to higher layers.
The higher layers should have specified the requirements on the data-channel.
If no requirements can be found, we should either propose behavior in error situations or request to get requirements stated from upper layers.

SCTP tells the user if the association has failed. At that point all data channels
must be closed. But I think this is something which needs to be stated in the
W3C document...

We discussed it earlier, and came to the conclusion that
A failing reliable channel will tear down the connection and some indication will be provided if possible to the application.
A failing partially reliable channel will enable transmission of next data item. ( I do not remember if the application will get any error indication or if it needs to have its own sequence checking if it is interested in knowing if there are no gaps. )

I suggest that a section on failure handling is added. I get the impression that it is in the data-channel draft it would be best suited.

But this is about the API. So it should go into the W3C document.

The API can only provide the functions provided by the mechanisms it has underneath.

There was a mail discussion in webRTC about the error situations.
A conclusion was that if a reliable channel reaches its retry limit ( that is usually only about 5 for WebRTC) or some other indication that the channel failed to convey the data, then the channel shall be broken (by the channel) and indications provided to both sides if possible. (another reasons mentioned was missed heartbeats for the whole association, setting a retry time limit of - what was it - - - 15 seconds?)

A reliable channel doesn't have a limit. The association has. If the association breaks,
all data channels are gone.

If the retries or retransmission time is exceeded for a partially reliable channel, the conclusion was that communication can continue with next data item. I am not sure if the applications were to 

It will continue. It is not a stop and wait...

get any notification about that or if they need to introduce sequence number checking themselves if they are interested to know.

I don't think so. I don't see anything in the JS API.



I cannot see how we can avoid describing the mechanisms needed and what happens to the channel.


I found a sentence about this  in section 6.6 of the data-channel-11 draft.

"

If a message with an unsupported PPID is received or some error is
 detected by the receiver (for example, illegal ordering), the
 receiver SHOULD close the corresponding data channel."


This paragraph could be extended to tell more about error situations in open channels.
I suggest to move this sentence to a new section and add description of other situations. The sentence only tells about errors detected at the receiving end. But it can also be the transmitting end that detects the problem. It should be stated what shall be done then.T

Something like this ( with my questions in paranthesis).
-------------------------------------------------------Proposed error handling section in rtcweb-data-channel---------------------------------------------------------------------------
6.7 Transmission failure and error handling
Failures can occur when a data channel is open.

If transmission in a reliable channel fails, the channel shall be closed by the party detecting the failure and an error indication provided.      ( what does STCP do in this situation? )

This can't happen. Only the association can fail and in this case all data channels are gone...

If a watchdog times out, the channel shall be closed with an error indication.         ( if this is part of the channel mechanisms, I have not seen where it is defined.)

If you think about SCTP HEARTBEATs, it is like the above. But it is more likely
that ICE will detect it first.

If retransmissions or transmission time is exceeded in a partially reliable channel, the transmission SHALL be allowed to continue with next data item.

It is not stop and wait... next item might be transmitted before the message is abandoned.

If reception out-of order is detected from an SCTP channel for which ordered transmission is requested, the receiver SHALL close the data channel.

This is covered by the text cited above.

If a message with an unsupported PPID is received or some logical error is detected by the receiver, the receiver SHALL close the corresponding data channel.

This is covered by the text cited above.

So I think the only thing not covered is what to do if the SCTP association fails,
but it is obvious to me that all channels are gone. Do we need to state that
explicitly? What do others think?

Best regards
Michael

--------------------End of proposed section on failure handling---------------------------------------------------------------------------------------------------------------------------



Regards

/Gunnar


Best regards
Michael

Regards

Gunnar
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
On 2014-06-10 20:52, Ted Hardie wrote:

Dear WG,

This starts a working group last call for our core Data Channel drafts:

draft-ietf-rtcweb-data-protocol-06.txt
draft-ietf-rtcweb-data-channel-10.txt

Please review them in detail, especially for areas which may be of concern to the broader IETF community.  This WGLC will end on June 27, 2014.

Ted, Sean, Cullen


_______________________________________________
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




    

    

  


--------------070103060902050105030101--


From nobody Mon Jul  7 20:58:49 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51CCC1A0ACA for ; Mon,  7 Jul 2014 20:58:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4wkMvddCXPg for ; Mon,  7 Jul 2014 20:58:43 -0700 (PDT)
Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D52A41B2A19 for ; Mon,  7 Jul 2014 20:58:41 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id w61so5307892wes.1 for ; Mon, 07 Jul 2014 20:58:40 -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:content-type; bh=pu5khTOdKez0bUxdqQRA7uEByfLdBMlBqtVW/lllAAI=; b=Xi64sBKPiuuq7IrtP8pjcKXm+PwuDOBp38VjHvTnJQNp6iM1PCi2SSDNb4DawWurVy C/47XrqHwQG5TOHxlLu+UmdDcZq64B191BZ3wFNKWB0AzNBqlOwrke8tT/31cX+ZIjps KrTqZx6q5qZxjFQznIYT36qdRrSouzEP/yCLDR5FYjJLq0mViRuLUy2PfqkEM8zj6CF7 RGMSteP5qzxNxMm3T9GeeyUhIIH6AUT57GqPUSizbHO1d8o8KQYBzWfiV6XZgDtLGX9T N9kqV3fBQIYSBEBFpokTm5tmOGT8D8m7RkIUENmCygO2BwoTmfBNAmKy5RRWUuBa5F/b NDrQ==
X-Received: by 10.194.119.9 with SMTP id kq9mr37019848wjb.49.1404791920490; Mon, 07 Jul 2014 20:58:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.136.137 with HTTP; Mon, 7 Jul 2014 20:58:20 -0700 (PDT)
In-Reply-To: <12EED657-F653-4AEF-996D-5EFAE67D3E3E@lurchi.franken.de>
References:  <53AD6AE4.4050707@alvestrand.no> <12EED657-F653-4AEF-996D-5EFAE67D3E3E@lurchi.franken.de>
From: Barry Dingle 
Date: Tue, 8 Jul 2014 13:58:20 +1000
Message-ID: 
To: Michael Tuexen 
Content-Type: multipart/alternative; boundary=089e0118451e67810304fda69b15
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8WaKwyzoP24qan308osxLLxEmGY
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] WGLC review for data channel drafts
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Jul 2014 03:58:47 -0000

--089e0118451e67810304fda69b15
Content-Type: text/plain; charset=UTF-8

I agree with the change to the Abstract in
draft-ietf-rtcweb-data-channel-10 (see below) as Michael proposed.

> draft-ietf-rtcweb-data-channel-10
> ----------------------------------------------
> Abstract
>
> Ten years from now, the RFC will exist, but the RTCWEB WG will not. I
suggest replacing "The Real-Time Communication in Web browsers working
group is charged to" with "The WebRTC framework specifies".
OK so it reads:
*The WebRTC framework specifies protocol support for direct interactive*
* rich communication using audio, video, and data between two peers'
web-browsers.*

But there is great variety in the first introductory words in the abstracts
in the RTCWEB RFC's. Why not use the one agreed introduction in ALL RTCWEB
RFC's?

Michael's words seem to be appropriate for all.

Cheers,
/Barry Dingle



On Sat, Jul 5, 2014 at 3:23 AM, Michael Tuexen <
Michael.Tuexen@lurchi.franken.de> wrote:

> On 27 Jun 2014, at 15:00, Harald Alvestrand  wrote:
>
> > On 06/10/2014 08:52 PM, Ted Hardie wrote:
> >> Dear WG,
> >>
> >> This starts a working group last call for our core Data Channel drafts:
> >>
> >> draft-ietf-rtcweb-data-protocol-06.txt
> >> draft-ietf-rtcweb-data-channel-10.txt
> >>
> >> Please review them in detail, especially for areas which may be of
> concern to the broader IETF community.  This WGLC will end on June 27, 2014.
> >
> > This is my Last Call review of these two drafts.
> First of all, thank you very much for the comments.
> >
> > First of all: The drafts are ready for IETF Last Call.
> > Second: There are a number of details that should be fixed. Whether that
> happens before IETF Last Call or not is not of great concern to me.
> I'll submit an update. That gives all the same basis for further
> discussions.
> >
> > draft-ietf-rtcweb-data-channel-10
> > ----------------------------------------------
> > Abstract
> >
> > Ten years from now, the RFC will exist, but the RTCWEB WG will not. I
> suggest replacing "The Real-Time Communication in Web browsers working
> group is charged to" with "The WebRTC framework specifies".
> OK so it reads:
> The WebRTC framework specifies protocol support for direct interactive
> rich communication using audio, video, and data between two peers'
> web-browsers.
> >
> > 1. Introduction
> >
> > It's a little abrupt. Some more words of introduction may be needed
> here. Something like this:
> >
> > In the WebRTC framework, communication between the parties consists of
> media (for example audio and video) and non-media data. Media is sent using
> SRTP, and is not specified further here. Non-media data is handled by...."
> Done. Good suggestion.
> >
> > I suggest a global replace of "non-SRTP media data" with "non-media
> data" (3 occurences total). "non-SRTP media data" can be parsed as "media
> data that is not carried over SRTP", which is not the intended meaning.
> Done.
> >
> > 4. Requirements
> >
> > Suggest striking "and that the WebRTC PeerConnection as a whole is fair
> with competing traffic such as TCP". The RMCAT discussions have proved how
> difficult it is just to define that, far less achieve it.
> > If we want to say something in relation to TCP, I would suggest "and
> that the WebRTC PeerConnection does not cause excessive problems when run
> in parallel with TCP connections".
> Taken.
> >
> > 5. SCTP over DTLS over UDP Considerations
> >
> > In the paragraph on SCTP multihoming, I suggest using "the DTLS layer"
> instead of "the lower layer". There are multiple lower layers, identifying
> which one is mentioned here improves clarity.
> OK.
> >
> > The term "user-land" is used here, while Req. 10 uses "user application
> space". I suggest using "user application space" in both places.
> OK.
> >
> > The paragraph "When using DTLS as the lower layer..." repeats the info
> that SCTP multihoming is not used. It may be enough to say this once.
> Taken out.
> >
> > "The partial reliability extension MUST support policies..." - this
> paragraph would be more implementable if specific policies, specified in an
> I-D or RFC, were referenced.
> References added.
> >
> > The split between section 5 and section 6 seems odd. In particular, the
> section "This SCTP stack and its upper layer...." down to "exactly once and
> delivered in the order received." seems to belong to section 6 not section
> 5.
> Text reorganised and removed duplicate text.
> >
> > 6.1 SCTP Protocol Considerations
> >
> > I think the -ndata messsage interleaving MUST be implemented, according
> to previous consensus.
> > "SHOULD be used" seems both meaningless and unneccssary.
> I think the current text covers the case that it is not available in
> implementations yet.
> If you write MUST be implemented, a conformant implementation would reject
> interworking
> with currently existing implementations.
> >
> > 6.2 Association setup
> >
> > Nit: "that can negotiated" -> "that can be negotiated"
> Fixed.
> >
> > 6.4 Channel definition
> >
> > The title should probably be "WebRTC Data Channel Definition".
> OK.
> >
> > As part of getting the WGs out of the document, the first sentence
> should be "The  WebRTC DataChannels are bidirectional."
> OK.
> > "Among other things" is a bad term to have in a document at Last Call
> time. Can we remove it?
> Done.
> >
> > The SHOULD for -ndata- interleaving should be MUST implement and MUST
> offer. If it is not successfully negotiated at association setup time (is
> that how it works?), the "SHOULD limit" clause is appropriate.
> But if it is MUST implement and MUST offer, how could it be not
> negotiated? If it
> is offered by both sides, it is used. The SHOULD covers that it might not
> be supported.
> So I think the text is in tune with other parts of the data channel
> documents.
> >
> > 6.7 Closing a channel
> >
> > Nit: "available to reuse" -> "available for reuse"
> > Nit: "before resetting the stream" -> "before the stream is reset"
> Both fixed.
> >
> > 7 Security considerations
> >
> > Is there a security worry with an attacker sending over-long messages in
> an attempt to cause OOM situations?
> OK, I added:
> I should be noted that a receiver must be prepared that the sender tries
> to send arbitrary large messages.
> >
> > draft-ietf-rtcweb-data-protocol-06
> > ---------------------------------------------
> > Abstract: Same worry about WG reference.
> Same as above.
> >
> > 3. Terminology
> >
> > Stream is defined in terms of stream, which is unhealthy. A reference to
> a section of a relevant SCTP document would be better.
> >
> > The term "SCTP stream" occurs at least 18 times in the document (out of
> approx 41 occurences of "stream" overall). We should either use "SCTP
> stream" consistently" or stick to "Stream" consistently.
> Changed to Stream consistently.
> >
> > The term "SCTP stream identifier" (or "stream identifier") should be
> called out in the terminology.
> OK.
> >
> > The term "data channel" occurs 36 times. Consider standardizing on
> either Channel or Data Channel, and either capitalizing it or not.
> OK. Using Data Channel consistently.
> >
> > 6 Procedures
> > Nit: "the sender of it can start" -> "the sender of the
> DATA_CHANNEL_OPEN can start"
> Done.
> >
> > "If a DATA_CHANNEL_OPEN message is received .... the stream identifier
> corresponds to the role of the peer" - is there a reason to insist that the
> protocol machine enforce the odd/even rule?
> I would like to define what happens if the peer does not follow the
> rule... It has to
> be handled by any implementation, so why leave it up to the implementer?
> > `(actually the next paragraph does not cover the odd/even rule violation
> case, which is probably just an unintentional mistake - I prefer writing
> this kind of thing in "IF  ... ELSE ....
> Jepp, that was unintentional...
> >  - because if one writes it as "IF ; IF  condition>", the risk of losing some edge cases is high.
> >
> > An alternative formulation for the second paragraph is "If the
> DATA_CHANNEL_OPEN message doesn't satisfy the conditions above, for
> instance if..."
> Good point. I will use:
> If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions above,
> for instance if a DATA_CHANNEL_OPEN message is received on an already used
> Stream or there are any problems with parameters within the
> DATA_CHANNEL_OPEN
> message, the odd/even rule is violated or the DATA_CHANNEL_OPEN message
> itself
> is not well-formed, the receiver MUST close the corresponding channel
> using the
> procedure described in  and
> MUST NOT send a DATA_CHANNEL_ACK message in response to the received
> message.
> >
> > 7 Security Considerations
> >
> > The "When using..." paragraph sounds a bit off. What about saying
> >
> > This protocol does not provide privacy, integrity or authentication. It
> needs to be used as part of a protocol suite that contains all these
> things. Such a protocol suite is specified in [-dtls-encaps].
> Taken.
> >
> > Dependency worries
> > ---------------------------
> > -protocol- depends normatively on these non-WG documents:
> >
> > draft-ietf-tsvwg-sctp-ndata ("I-D exists")
> This is currently being worked on.
> > draft-ietf-tsvwg-sctp-dtls-encaps ("AD is watching")
> This is passed WG LC, just incorporating the comments. So there will be a
> new rev tomorrow.
> > draft-ietf-tsvwg-sctp-prpolicies ("I-D exists")
> The WG LC started yesterday. Reviews very welcome!
> > draft-ietf-mmusic-sctp-sdp ("I-D exists")
> I don't know about the status of this.
> >
> > None of these are in the IESG queue. Are we confident of their speed of
> progress?
> >
> >
> > This concludes my review. I think the protocol definition is ready, and
> needs no changes.
> >
> >
> >
> >
> > _______________________________________________
> > 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
>

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


I agree with the change to the Abstract in draft=
-ietf-rtcweb-data-channel-10 (see below) as Michael proposed. 

> draft-ietf-rtcweb-data-channel-10
=




> ----------------------------------------------

> Abstract

>

> Ten years from now,
 the RFC will exist, but the RTCWEB WG will not. I suggest replacing=20
"The Real-Time Communication in Web browsers working group is charged=
=20
to" with "The WebRTC framework specifies".


OK so it reads:

<t>The WebRTC framework specifies protocol support for direct inte=
ractive

rich communication using audio, video, and data between two peers' web-=
browsers.

But there is great variety in the first in=
troductory words in the abstracts in the RTCWEB RFC's. Why not use the =
one agreed introduction in ALL RTCWEB RFC's? 




Michael's words seem to be appropriate for all.

Cheers,=

/Barry Dingle




On Sat, Jul 5, 2014 at 3:23 AM, Michael =
Tuexen <Michael.Tuexen@lurchi.franken.de> wro=
te:



On 27 Jun 2014, at 15:00, Ha=
rald Alvestrand <harald@alvestra=
nd.no> wrote:





> On 06/10/2014 08:52 PM, Ted Hardie wrote:

>> Dear WG,

>>

>> This starts a working group last call for our core Data Channel dr=
afts:

>>

>> draft-ietf-rtcweb-data-protocol-06.txt

>> draft-ietf-rtcweb-data-channel-10.txt

>>

>> Please review them in detail, especially for areas which may be of=
 concern to the broader IETF community. =C2=A0This WGLC will end on June 27=
, 2014.

>

> This is my Last Call review of these two drafts.


First of all, thank you very much for the comments.


>

> First of all: The drafts are ready for IETF Last Call.

> Second: There are a number of details that should be fixed. Whether th=
at happens before IETF Last Call or not is not of great concern to me.


I'll submit an update. That gives all the same basis for further =
discussions.


>

> draft-ietf-rtcweb-data-channel-10

> ----------------------------------------------

> Abstract

>

> Ten years from now, the RFC will exist, but the RTCWEB WG will not. I =
suggest replacing "The Real-Time Communication in Web browsers working=
 group is charged to" with "The WebRTC framework specifies".=





OK so it reads:

<t>The WebRTC framework specifies protocol support for direct interac=
tive

rich communication using audio, video, and data between two peers' web-=
browsers.


>

> 1. Introduction

>

> It's a little abrupt. Some more words of introduction may be neede=
d here. Something like this:

>

> In the WebRTC framework, communication between the parties consists of=
 media (for example audio and video) and non-media data. Media is sent usin=
g SRTP, and is not specified further here. Non-media data is handled by....=
"




Done. Good suggestion.


>

> I suggest a global replace of "non-SRTP media data" with &qu=
ot;non-media data" (3 occurences total). "non-SRTP media data&quo=
t; can be parsed as "media data that is not carried over SRTP", w=
hich is not the intended meaning.




Done.


>

> 4. Requirements

>

> Suggest striking "and that the WebRTC PeerConnection as a whole i=
s fair with competing traffic such as TCP". The RMCAT discussions have=
 proved how difficult it is just to define that, far less achieve it.



> If we want to say something in relation to TCP, I would suggest "=
and that the WebRTC PeerConnection does not cause excessive problems when r=
un in parallel with TCP connections".


Taken.


>

> 5. SCTP over DTLS over UDP Considerations

>

> In the paragraph on SCTP multihoming, I suggest using "the DTLS l=
ayer" instead of "the lower layer". There are multiple lower=
 layers, identifying which one is mentioned here improves clarity.




OK.


>

> The term "user-land" is used here, while Req. 10 uses "=
user application space". I suggest using "user application space&=
quot; in both places.


OK.


>

> The paragraph "When using DTLS as the lower layer..." repeat=
s the info that SCTP multihoming is not used. It may be enough to say this =
once.


Taken out.


>

> "The partial reliability extension MUST support policies..."=
 - this paragraph would be more implementable if specific policies, specifi=
ed in an I-D or RFC, were referenced.


References added.


>

> The split between section 5 and section 6 seems odd. In particular, th=
e section "This SCTP stack and its upper layer...." down to "=
;exactly once and delivered in the order received." seems to belong to=
 section 6 not section 5.




Text reorganised and removed duplicate text.


>

> 6.1 SCTP Protocol Considerations

>

> I think the -ndata messsage interleaving MUST be implemented, accordin=
g to previous consensus.

> "SHOULD be used" seems both meaningless and unneccssary.


I think the current text covers the case that it is not available in =
implementations yet.

If you write MUST be implemented, a conformant implementation would reject =
interworking

with currently existing implementations.


>

> 6.2 Association setup

>

> Nit: "that can negotiated" -> "that can be negotiate=
d"


Fixed.


>

> 6.4 Channel definition

>

> The title should probably be "WebRTC Data Channel Definition"=
;.


OK.


>

> As part of getting the WGs out of the document, the first sentence sho=
uld be "The =C2=A0WebRTC DataChannels are bidirectional."


OK.


> "Among other things" is a bad term to have i=
n a document at Last Call time. Can we remove it?


Done.


>

> The SHOULD for -ndata- interleaving should be MUST implement and MUST =
offer. If it is not successfully negotiated at association setup time (is t=
hat how it works?), the "SHOULD limit" clause is appropriate.




But if it is MUST implement and MUST offer, how could it be not negot=
iated? If it

is offered by both sides, it is used. The SHOULD covers that it might not b=
e supported.

So I think the text is in tune with other parts of the data channel documen=
ts.


>

> 6.7 Closing a channel

>

> Nit: "available to reuse" -> "available for reuse&qu=
ot;

> Nit: "before resetting the stream" -> "before the st=
ream is reset"


Both fixed.


>

> 7 Security considerations

>

> Is there a security worry with an attacker sending over-long messages =
in an attempt to cause OOM situations?


OK, I added:

<t>I should be noted that a receiver must be prepared that the sender=
 tries

to send arbitrary large messages.</t>


>

> draft-ietf-rtcweb-data-protocol-06

> ---------------------------------------------

> Abstract: Same worry about WG reference.


Same as above.


>

> 3. Terminology

>

> Stream is defined in terms of stream, which is unhealthy. A reference =
to a section of a relevant SCTP document would be better.

>

> The term "SCTP stream" occurs at least 18 times in the docum=
ent (out of approx 41 occurences of "stream" overall). We should =
either use "SCTP stream" consistently" or stick to "Str=
eam" consistently.




Changed to Stream consistently.


>

> The term "SCTP stream identifier" (or "stream identifie=
r") should be called out in the terminology.


OK.


>

> The term "data channel" occurs 36 times. Consider standardiz=
ing on either Channel or Data Channel, and either capitalizing it or not.

OK. Using Data Channel consistently.


>

> 6 Procedures

> Nit: "the sender of it can start" -> "the sender of =
the DATA_CHANNEL_OPEN can start"


Done.


>

> "If a DATA_CHANNEL_OPEN message is received .... the stream ident=
ifier corresponds to the role of the peer" - is there a reason to insi=
st that the protocol machine enforce the odd/even rule?


I would like to define what happens if the peer does not follow the r=
ule... It has to

be handled by any implementation, so why leave it up to the implementer?

> `(actually the next paragraph does not cover the odd/e=
ven rule violation case, which is probably just an unintentional mistake - =
I prefer writing this kind of thing in "IF <condition> ... ELSE =
....




Jepp, that was unintentional...


> =C2=A0- because if one writes it as "IF <condi=
tion>; IF <opposite condition>", the risk of losing some edge=
 cases is high.

>

> An alternative formulation for the second paragraph is "If the DA=
TA_CHANNEL_OPEN message doesn't satisfy the conditions above, for insta=
nce if..."


Good point. I will use:

<t>If the DATA_CHANNEL_OPEN message doesn't satisfy the condition=
s above,

for instance if a DATA_CHANNEL_OPEN message is received on an already used<=
br>
Stream or there are any problems with parameters within the DATA_CHANNEL_OP=
EN

message, the odd/even rule is violated or the DATA_CHANNEL_OPEN message its=
elf

is not well-formed, the receiver MUST close the corresponding channel using=
 the

procedure described in <xref target=3D'I-D.ietf-rtcweb-data-channel&=
#39;/> and

MUST NOT send a DATA_CHANNEL_ACK message in response to the received messag=
e.


>

> 7 Security Considerations

>

> The "When using..." paragraph sounds a bit off. What about s=
aying

>

> This protocol does not provide privacy, integrity or authentication. I=
t needs to be used as part of a protocol suite that contains all these thin=
gs. Such a protocol suite is specified in [-dtls-encaps].


Taken.


>

> Dependency worries

> ---------------------------

> -protocol- depends normatively on these non-WG documents:

>

> draft-ietf-tsvwg-sctp-ndata ("I-D exists")


This is currently being worked on.


> draft-ietf-tsvwg-sctp-dtls-encaps ("AD is watchin=
g")


This is passed WG LC, just incorporating the comments. So there will =
be a new rev tomorrow.


> draft-ietf-tsvwg-sctp-prpolicies ("I-D exists&quo=
t;)


The WG LC started yesterday. Reviews very welcome!


> draft-ietf-mmusic-sctp-sdp ("I-D exists")

I don't know about the status of this.


>

> None of these are in the IESG queue. Are we confident of their speed o=
f progress?

>

>

> This concludes my review. I think the protocol definition is ready, an=
d needs no changes.

>

>

>

>


> _______________________________________________

> 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





--089e0118451e67810304fda69b15--


From nobody Tue Jul  8 00:45:31 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C441B2AA5 for ; Tue,  8 Jul 2014 00:45:26 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mg_eXbi83CnN for ; Tue,  8 Jul 2014 00:45:20 -0700 (PDT)
Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) (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 1EACE1B2A57 for ; Tue,  8 Jul 2014 00:45:19 -0700 (PDT)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTPS for ; Tue,  8 Jul 2014 09:45:04 +0200 (CEST)
Received: from [192.168.2.41] (81-224-110-16-no227.business.telia.com [81.224.110.16]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id EB7933A125 for ; Tue,  8 Jul 2014 09:45:04 +0200 (CEST)
Message-ID: <53BBA183.1040206@omnitor.se>
Date: Tue, 08 Jul 2014 09:45:07 +0200
From: Gunnar Hellstrom 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <53B71B6E.2010604@omnitor.se> <470AD025-E40B-43BD-B141-599489FB892C@lurchi.franken.de> <53B797C1.3080609@omnitor.se> <596034E6-7D76-4F82-AFD3-521B8C0217B8@lurchi.franken.de> <53BB2194.2080601@omnitor.se>
In-Reply-To: <53BB2194.2080601@omnitor.se>
Content-Type: multipart/alternative; boundary="------------080200020509080801020107"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rzU5ZQLCCHXUPJLsan7RChsU6uo
Subject: Re: [rtcweb] WGLC for data channel drafts - missing descriptions of error situations
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Jul 2014 07:45:27 -0000

This is a multi-part message in MIME format.
--------------080200020509080801020107
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

The w3c API specification is still very vague about error situations and 
how they are discovered and signaled. But there are some indications 
that it expects the rtcweb-data-protocol or rtcweb-data-channel 
specification to provide details.

In the API specification of the send() method at
http://dev.w3.org/2011/webrtc/editor/webrtc.html#dictionary-rtcdatachannelinit-members

Action point 5 under send() , it says:

"5. Attempt to senddataonchannel'sunderlying data transport 
; 
if the data cannot be sent, e.g. because it would need to be buffered 
but the buffer is full, the user agent/must/abruptly close 
channel'sunderlying 
data transport 
with 
an error 
."

The buffer-full reason for failure described is just an example. This 
opens for other reasons of failure. I think the rtcweb drafts should 
specify the reasons for failure that are under their control, (and the 
text in the API spec improved to give a better view of what reasons for 
failure there are. )

There is also an anomaly in the sentence. It says that " if the data 
cannot be sent, the user agent/must/abruptly close 
channel'sunderlying 
data transport. 

You say that if the channel is specified as partially reliable, failures 
to send will not be signaled and the channel will not be closed. These 
statements contradict each other. For this case, it might be the wording 
in the API specification that needs to be improved and specify that " if 
the channel was specified as reliable and the data cannot be sent.....".
But knowledge about what is expected from the channel and the 
association is needed to be able to specify this correctly.

I see a clear need for the rtcweb data channel specifications to specify 
the failure situations under their control or signaled by underlying 
transport.
Please use the new section 6.7 I provided as a proposal in this thread 
and refine it from your knowledge about the real behavior.

Regards

Gunnar




------------------------------------------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.seOn 2014-07-08 00:39, Gunnar Hellstrom wrote:
> Thaks Michael,
> You provide important additional information added to the section 6.7  
> on transmission failure handling for the data-channel draft that I 
> proposed below. I cannot find this information anywhere else, so I 
> think it is important to provide it in the data-channel draft so that 
> the W3C API authors can see what mechanisms are available and describe 
> the API from that.
>
> You say that the association breaks if a number of retries fail. But 
> cannot the association contain both reliable and partially reliable 
> channels? How would the decision logic to break the association 
> because a number of failures be formed when there are different kinds 
> of channels in the association? Or do I remember wrongly? Is there 
> only one type of channels in an association.
>
> You also say that both missed heartbeats and broken ICE connections 
> may break the association. Where do you suggest that that combined 
> behavior should be described? Also in the data-channel draft?
>
> Thaks,
>
> Gunnar
>
>
>
>
> ------------------------------------------------------------------------
> Gunnar Hellström
> Omnitor
> gunnar.hellstrom@omnitor.se
> +46708204288
> On 2014-07-07 22:00, Michael Tuexen wrote:
>> On 05 Jul 2014, at 08:14, Gunnar Hellstrom  wrote:
>>
>>> On 2014-07-04 23:34, Michael Tuexen wrote:
>>>> On 04 Jul 2014, at 23:23, Gunnar Hellstrom  wrote:
>>>>
>>>>> I cannot find that what happens in transmission error situations is described in any of these drafts.
>>>>>
>>>>> Both reliable and partially reliable transmission can fail, and the application designer need to know what happens.
>>>> I don't understand the notion of "reliable and partially reliable transmission can fail"...
>>>> If a user message gets abandoned (so the stack gives up transmitting/retransmitting it, but
>>>> the association stays alive), I don't think it is signalled via the JS API, but that might
>>>> be an issue of W3C. If the association fails, all data channel fail. This is signalled.
>>>> However, this is something for the W3C document.
>>> The W3C mechanism makes use of the rtcweb-data-channel.
>>> The rtcweb-data-channel should tell what happens in error situations and if that is possible to be signaled to higher layers.
>>> The higher layers should have specified the requirements on the data-channel.
>>> If no requirements can be found, we should either propose behavior in error situations or request to get requirements stated from upper layers.
>> SCTP tells the user if the association has failed. At that point all data channels
>> must be closed. But I think this is something which needs to be stated in the
>> W3C document...
>>>>> We discussed it earlier, and came to the conclusion that
>>>>> A failing reliable channel will tear down the connection and some indication will be provided if possible to the application.
>>>>> A failing partially reliable channel will enable transmission of next data item. ( I do not remember if the application will get any error indication or if it needs to have its own sequence checking if it is interested in knowing if there are no gaps. )
>>>>>
>>>>> I suggest that a section on failure handling is added. I get the impression that it is in the data-channel draft it would be best suited.
>>>> But this is about the API. So it should go into the W3C document.
>>> The API can only provide the functions provided by the mechanisms it has underneath.
>>>
>>> There was a mail discussion in webRTC about the error situations.
>>> A conclusion was that if a reliable channel reaches its retry limit ( that is usually only about 5 for WebRTC) or some other indication that the channel failed to convey the data, then the channel shall be broken (by the channel) and indications provided to both sides if possible. (another reasons mentioned was missed heartbeats for the whole association, setting a retry time limit of - what was it - - - 15 seconds?)
>> A reliable channel doesn't have a limit. The association has. If the association breaks,
>> all data channels are gone.
>>> If the retries or retransmission time is exceeded for a partially reliable channel, the conclusion was that communication can continue with next data item. I am not sure if the applications were to
>> It will continue. It is not a stop and wait...
>>> get any notification about that or if they need to introduce sequence number checking themselves if they are interested to know.
>> I don't think so. I don't see anything in the JS API.
>>>
>>> I cannot see how we can avoid describing the mechanisms needed and what happens to the channel.
>>>
>>>
>>> I found a sentence about this  in section 6.6 of the data-channel-11 draft.
>>>
>>> "
>>>
>>> If a message with an unsupported PPID is received or some error is
>>>   detected by the receiver (for example, illegal ordering), the
>>>   receiver SHOULD close the corresponding data channel."
>>>
>>>
>>> This paragraph could be extended to tell more about error situations in open channels.
>>> I suggest to move this sentence to a new section and add description of other situations. The sentence only tells about errors detected at the receiving end. But it can also be the transmitting end that detects the problem. It should be stated what shall be done then.T
>>>
>>> Something like this ( with my questions in paranthesis).
>>> -------------------------------------------------------Proposed error handling section in rtcweb-data-channel---------------------------------------------------------------------------
>>> 6.7 Transmission failure and error handling
>>> Failures can occur when a data channel is open.
>>>
>>> If transmission in a reliable channel fails, the channel shall be closed by the party detecting the failure and an error indication provided.      ( what does STCP do in this situation? )
>> This can't happen. Only the association can fail and in this case all data channels are gone...
>>> If a watchdog times out, the channel shall be closed with an error indication.         ( if this is part of the channel mechanisms, I have not seen where it is defined.)
>> If you think about SCTP HEARTBEATs, it is like the above. But it is more likely
>> that ICE will detect it first.
>>> If retransmissions or transmission time is exceeded in a partially reliable channel, the transmission SHALL be allowed to continue with next data item.
>> It is not stop and wait... next item might be transmitted before the message is abandoned.
>>> If reception out-of order is detected from an SCTP channel for which ordered transmission is requested, the receiver SHALL close the data channel.
>> This is covered by the text cited above.
>>> If a message with an unsupported PPID is received or some logical error is detected by the receiver, the receiver SHALL close the corresponding data channel.
>> This is covered by the text cited above.
>>
>> So I think the only thing not covered is what to do if the SCTP association fails,
>> but it is obvious to me that all channels are gone. Do we need to state that
>> explicitly? What do others think?
>>
>> Best regards
>> Michael
>>> --------------------End of proposed section on failure handling---------------------------------------------------------------------------------------------------------------------------
>>>
>>>
>>>
>>> Regards
>>>
>>> /Gunnar
>>>
>>>> Best regards
>>>> Michael
>>>>> Regards
>>>>>
>>>>> Gunnar
>>>>> Gunnar Hellström
>>>>> Omnitor
>>>>> gunnar.hellstrom@omnitor.se
>>>>> On 2014-06-10 20:52, Ted Hardie wrote:
>>>>>> Dear WG,
>>>>>>
>>>>>> This starts a working group last call for our core Data Channel drafts:
>>>>>>
>>>>>> draft-ietf-rtcweb-data-protocol-06.txt
>>>>>> draft-ietf-rtcweb-data-channel-10.txt
>>>>>>
>>>>>> Please review them in detail, especially for areas which may be of concern to the broader IETF community.  This WGLC will end on June 27, 2014.
>>>>>>
>>>>>> Ted, Sean, Cullen
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> rtcweb mailing list
>>>>>>
>>>>>> rtcweb@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>> _______________________________________________
>>>>> rtcweb mailing list
>>>>> rtcweb@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--------------080200020509080801020107
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
The w3c API specification is still very
      vague about error situations and how they are discovered and
      signaled. But there are some indications that it expects the
      rtcweb-data-protocol or rtcweb-data-channel specification to
      provide details.

      

      In the API specification of the send() method at

http://dev.w3.org/2011/webrtc/editor/webrtc.html#dictionary-rtcdatachannelinit-members

      

      Action point 5 under send() , it says:

      

      "5. Attempt to send data on channel’s underlying
        data transport; if the data cannot be sent, e.g. because it
      would need to be buffered but the buffer is full, the user agent must abruptly close channel’s underlying
        data transport with
        an error."

      

      The buffer-full reason for failure described is just an example.
      This opens for other reasons of failure. I think the rtcweb drafts
      should specify the reasons for failure that are under their
      control, (and the text in the API spec improved to give a better
      view of what reasons for failure there are. )

      

      There is also an anomaly in the sentence. It says that " if the
      data cannot be sent, the user agent must abruptly close channel’s underlying
        data transport.

      You say that if the channel is specified as partially reliable,
      failures to send will not be signaled and the channel will not be
      closed. These statements contradict each other. For this case, it
      might be the wording in the API specification that needs to be
      improved and specify that " if the channel was specified as
      reliable and the data cannot be sent.....". 

      But knowledge about what is expected from the channel and the
      association is needed to be able to specify this correctly. 

      

      I see a clear need for the rtcweb data channel specifications to
      specify the failure situations under their control or signaled by
      underlying transport. 

      Please use the new section 6.7 I provided as a proposal in this
      thread and refine it from your knowledge about the real behavior.

      

      Regards

      

      Gunnar

      

      

      

      

      

        

        Gunnar Hellström

        Omnitor

        gunnar.hellstrom@omnitor.seOn 2014-07-08 00:39, Gunnar Hellstrom
        wrote:

      

    

    

      
      
Thaks Michael,

        You provide important additional information added to the
        section 6.7  on transmission failure handling for the
        data-channel draft that I proposed below. I cannot find this
        information anywhere else, so I think it is important to provide
        it in the data-channel draft so that the W3C API authors can see
        what mechanisms are available and describe the API from that.

        

        You say that the association breaks if a number of retries fail.
        But cannot the association contain both reliable and partially
        reliable channels? How would the decision logic to break the
        association because a number of failures be formed when there
        are different kinds of channels in the association? Or do I
        remember wrongly? Is there only one type of channels in an
        association.

        

        You also say that both missed heartbeats and broken ICE
        connections may break the association. Where do you suggest that
        that combined behavior should be described? Also in the
        data-channel draft? 

        

        Thaks,

        

        Gunnar

        

        

        

        

        

          
 Gunnar Hellström

          Omnitor

          gunnar.hellstrom@omnitor.se

          +46708204288

        

        On 2014-07-07 22:00, Michael Tuexen wrote:

      

      

        
On 05 Jul 2014, at 08:14, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote:



        

          
On 2014-07-04 23:34, Michael Tuexen wrote:


          

            
On 04 Jul 2014, at 23:23, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote:



            

              
I cannot find that what happens in transmission error situations is described in any of these drafts.

Both reliable and partially reliable transmission can fail, and the application designer need to know what happens.


            

            
I don't understand the notion of "reliable and partially reliable transmission can fail"...
If a user message gets abandoned (so the stack gives up transmitting/retransmitting it, but
the association stays alive), I don't think it is signalled via the JS API, but that might
be an issue of W3C. If the association fails, all data channel fail. This is signalled.
However, this is something for the W3C document.


          

          
The W3C mechanism makes use of the rtcweb-data-channel.
The rtcweb-data-channel should tell what happens in error situations and if that is possible to be signaled to higher layers.
The higher layers should have specified the requirements on the data-channel.
If no requirements can be found, we should either propose behavior in error situations or request to get requirements stated from upper layers.


        

        
SCTP tells the user if the association has failed. At that point all data channels
must be closed. But I think this is something which needs to be stated in the
W3C document...


        

          

            

              
We discussed it earlier, and came to the conclusion that
A failing reliable channel will tear down the connection and some indication will be provided if possible to the application.
A failing partially reliable channel will enable transmission of next data item. ( I do not remember if the application will get any error indication or if it needs to have its own sequence checking if it is interested in knowing if there are no gaps. )

I suggest that a section on failure handling is added. I get the impression that it is in the data-channel draft it would be best suited.


            

            
But this is about the API. So it should go into the W3C document.


          

          
The API can only provide the functions provided by the mechanisms it has underneath.

There was a mail discussion in webRTC about the error situations.
A conclusion was that if a reliable channel reaches its retry limit ( that is usually only about 5 for WebRTC) or some other indication that the channel failed to convey the data, then the channel shall be broken (by the channel) and indications provided to both sides if possible. (another reasons mentioned was missed heartbeats for the whole association, setting a retry time limit of - what was it - - - 15 seconds?)


        

        
A reliable channel doesn't have a limit. The association has. If the association breaks,
all data channels are gone.


        

          
If the retries or retransmission time is exceeded for a partially reliable channel, the conclusion was that communication can continue with next data item. I am not sure if the applications were to 


        

        
It will continue. It is not a stop and wait...


        

          
get any notification about that or if they need to introduce sequence number checking themselves if they are interested to know.


        

        
I don't think so. I don't see anything in the JS API.


        

          

I cannot see how we can avoid describing the mechanisms needed and what happens to the channel.


I found a sentence about this  in section 6.6 of the data-channel-11 draft.

"

If a message with an unsupported PPID is received or some error is
 detected by the receiver (for example, illegal ordering), the
 receiver SHOULD close the corresponding data channel."


This paragraph could be extended to tell more about error situations in open channels.
I suggest to move this sentence to a new section and add description of other situations. The sentence only tells about errors detected at the receiving end. But it can also be the transmitting end that detects the problem. It should be stated what shall be done then.T

Something like this ( with my questions in paranthesis).
-------------------------------------------------------Proposed error handling section in rtcweb-data-channel---------------------------------------------------------------------------
6.7 Transmission failure and error handling
Failures can occur when a data channel is open.

If transmission in a reliable channel fails, the channel shall be closed by the party detecting the failure and an error indication provided.      ( what does STCP do in this situation? )


        

        
This can't happen. Only the association can fail and in this case all data channels are gone...


        

          
If a watchdog times out, the channel shall be closed with an error indication.         ( if this is part of the channel mechanisms, I have not seen where it is defined.)


        

        
If you think about SCTP HEARTBEATs, it is like the above. But it is more likely
that ICE will detect it first.


        

          
If retransmissions or transmission time is exceeded in a partially reliable channel, the transmission SHALL be allowed to continue with next data item.


        

        
It is not stop and wait... next item might be transmitted before the message is abandoned.


        

          
If reception out-of order is detected from an SCTP channel for which ordered transmission is requested, the receiver SHALL close the data channel.


        

        
This is covered by the text cited above.


        

          
If a message with an unsupported PPID is received or some logical error is detected by the receiver, the receiver SHALL close the corresponding data channel.


        

        
This is covered by the text cited above.

So I think the only thing not covered is what to do if the SCTP association fails,
but it is obvious to me that all channels are gone. Do we need to state that
explicitly? What do others think?

Best regards
Michael


        

          
--------------------End of proposed section on failure handling---------------------------------------------------------------------------------------------------------------------------



Regards

/Gunnar



          

            
Best regards
Michael


            

              
Regards

Gunnar
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
On 2014-06-10 20:52, Ted Hardie wrote:


              

                
Dear WG,

This starts a working group last call for our core Data Channel drafts:

draft-ietf-rtcweb-data-protocol-06.txt
draft-ietf-rtcweb-data-channel-10.txt

Please review them in detail, especially for areas which may be of concern to the broader IETF community.  This WGLC will end on June 27, 2014.

Ted, Sean, Cullen


_______________________________________________
rtcweb mailing list

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


              

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


            

          

          

        

      

      

      

      

      

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


    

    

  


--------------080200020509080801020107--


From nobody Tue Jul  8 05:32:20 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B0F1B2823 for ; Tue,  8 Jul 2014 05:32:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level: 
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddrDbRNzBlrb for ; Tue,  8 Jul 2014 05:32:13 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 030A71B27AE for ; Tue,  8 Jul 2014 05:32:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id E4CBC7C3BD4; Tue,  8 Jul 2014 14:32:11 +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 64--p69M2H3p; Tue,  8 Jul 2014 14:32:09 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:c8c6:c08e:2a89:fe09] (unknown [IPv6:2001:470:de0a:27:c8c6:c08e:2a89:fe09]) by mork.alvestrand.no (Postfix) with ESMTPSA id F21357C3BD2; Tue,  8 Jul 2014 14:32:08 +0200 (CEST)
Message-ID: <53BBE4C8.3060604@alvestrand.no>
Date: Tue, 08 Jul 2014 14:32:08 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Barry Dingle ,  Michael Tuexen 
References:  <53AD6AE4.4050707@alvestrand.no> <12EED657-F653-4AEF-996D-5EFAE67D3E3E@lurchi.franken.de> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020708040606090401090003"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/12pIFaaUj3J-wzWowXbDTdKj0z0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] WGLC review for data channel drafts
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Jul 2014 12:32:20 -0000

This is a multi-part message in MIME format.
--------------020708040606090401090003
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 07/08/2014 05:58 AM, Barry Dingle wrote:
> I agree with the change to the Abstract in 
> draft-ietf-rtcweb-data-channel-10 (see below) as Michael proposed.
>
> > draft-ietf-rtcweb-data-channel-10
> > ----------------------------------------------
> > Abstract
> >
> > Ten years from now, the RFC will exist, but the RTCWEB WG will not. 
> I suggest replacing "The Real-Time Communication in Web browsers 
> working group is charged to" with "The WebRTC framework specifies".
> OK so it reads:
> *The WebRTC framework specifies protocol support for direct 
> interactive*
> *rich communication using audio, video, and data between two peers' 
> web-browsers.*
>
> But there is great variety in the first introductory words in the 
> abstracts in the RTCWEB RFC's. Why not use the one agreed introduction 
> in ALL RTCWEB RFC's?
>
> Michael's words seem to be appropriate for all.

I wouldn't mind having standard words in the abstract. It saves arguing.

The call for consensus to do so has to come from our chairs, but I'm 
willing to be part of the consensus (if the proposed text isn't too 
egregrious).


>
> Cheers,
> /Barry Dingle
>
>
>
> On Sat, Jul 5, 2014 at 3:23 AM, Michael Tuexen 
>  > wrote:
>
>     On 27 Jun 2014, at 15:00, Harald Alvestrand      > wrote:
>
>     > On 06/10/2014 08:52 PM, Ted Hardie wrote:
>     >> Dear WG,
>     >>
>     >> This starts a working group last call for our core Data Channel
>     drafts:
>     >>
>     >> draft-ietf-rtcweb-data-protocol-06.txt
>     >> draft-ietf-rtcweb-data-channel-10.txt
>     >>
>     >> Please review them in detail, especially for areas which may be
>     of concern to the broader IETF community.  This WGLC will end on
>     June 27, 2014.
>     >
>     > This is my Last Call review of these two drafts.
>     First of all, thank you very much for the comments.
>     >
>     > First of all: The drafts are ready for IETF Last Call.
>     > Second: There are a number of details that should be fixed.
>     Whether that happens before IETF Last Call or not is not of great
>     concern to me.
>     I'll submit an update. That gives all the same basis for further
>     discussions.
>     >
>     > draft-ietf-rtcweb-data-channel-10
>     > ----------------------------------------------
>     > Abstract
>     >
>     > Ten years from now, the RFC will exist, but the RTCWEB WG will
>     not. I suggest replacing "The Real-Time Communication in Web
>     browsers working group is charged to" with "The WebRTC framework
>     specifies".
>     OK so it reads:
>     The WebRTC framework specifies protocol support for direct
>     interactive
>     rich communication using audio, video, and data between two peers'
>     web-browsers.
>     >
>     > 1. Introduction
>     >
>     > It's a little abrupt. Some more words of introduction may be
>     needed here. Something like this:
>     >
>     > In the WebRTC framework, communication between the parties
>     consists of media (for example audio and video) and non-media
>     data. Media is sent using SRTP, and is not specified further here.
>     Non-media data is handled by...."
>     Done. Good suggestion.
>     >
>     > I suggest a global replace of "non-SRTP media data" with
>     "non-media data" (3 occurences total). "non-SRTP media data" can
>     be parsed as "media data that is not carried over SRTP", which is
>     not the intended meaning.
>     Done.
>     >
>     > 4. Requirements
>     >
>     > Suggest striking "and that the WebRTC PeerConnection as a whole
>     is fair with competing traffic such as TCP". The RMCAT discussions
>     have proved how difficult it is just to define that, far less
>     achieve it.
>     > If we want to say something in relation to TCP, I would suggest
>     "and that the WebRTC PeerConnection does not cause excessive
>     problems when run in parallel with TCP connections".
>     Taken.
>     >
>     > 5. SCTP over DTLS over UDP Considerations
>     >
>     > In the paragraph on SCTP multihoming, I suggest using "the DTLS
>     layer" instead of "the lower layer". There are multiple lower
>     layers, identifying which one is mentioned here improves clarity.
>     OK.
>     >
>     > The term "user-land" is used here, while Req. 10 uses "user
>     application space". I suggest using "user application space" in
>     both places.
>     OK.
>     >
>     > The paragraph "When using DTLS as the lower layer..." repeats
>     the info that SCTP multihoming is not used. It may be enough to
>     say this once.
>     Taken out.
>     >
>     > "The partial reliability extension MUST support policies..." -
>     this paragraph would be more implementable if specific policies,
>     specified in an I-D or RFC, were referenced.
>     References added.
>     >
>     > The split between section 5 and section 6 seems odd. In
>     particular, the section "This SCTP stack and its upper layer...."
>     down to "exactly once and delivered in the order received." seems
>     to belong to section 6 not section 5.
>     Text reorganised and removed duplicate text.
>     >
>     > 6.1 SCTP Protocol Considerations
>     >
>     > I think the -ndata messsage interleaving MUST be implemented,
>     according to previous consensus.
>     > "SHOULD be used" seems both meaningless and unneccssary.
>     I think the current text covers the case that it is not available
>     in implementations yet.
>     If you write MUST be implemented, a conformant implementation
>     would reject interworking
>     with currently existing implementations.
>     >
>     > 6.2 Association setup
>     >
>     > Nit: "that can negotiated" -> "that can be negotiated"
>     Fixed.
>     >
>     > 6.4 Channel definition
>     >
>     > The title should probably be "WebRTC Data Channel Definition".
>     OK.
>     >
>     > As part of getting the WGs out of the document, the first
>     sentence should be "The  WebRTC DataChannels are bidirectional."
>     OK.
>     > "Among other things" is a bad term to have in a document at Last
>     Call time. Can we remove it?
>     Done.
>     >
>     > The SHOULD for -ndata- interleaving should be MUST implement and
>     MUST offer. If it is not successfully negotiated at association
>     setup time (is that how it works?), the "SHOULD limit" clause is
>     appropriate.
>     But if it is MUST implement and MUST offer, how could it be not
>     negotiated? If it
>     is offered by both sides, it is used. The SHOULD covers that it
>     might not be supported.
>     So I think the text is in tune with other parts of the data
>     channel documents.
>     >
>     > 6.7 Closing a channel
>     >
>     > Nit: "available to reuse" -> "available for reuse"
>     > Nit: "before resetting the stream" -> "before the stream is reset"
>     Both fixed.
>     >
>     > 7 Security considerations
>     >
>     > Is there a security worry with an attacker sending over-long
>     messages in an attempt to cause OOM situations?
>     OK, I added:
>     I should be noted that a receiver must be prepared that the
>     sender tries
>     to send arbitrary large messages.
>     >
>     > draft-ietf-rtcweb-data-protocol-06
>     > ---------------------------------------------
>     > Abstract: Same worry about WG reference.
>     Same as above.
>     >
>     > 3. Terminology
>     >
>     > Stream is defined in terms of stream, which is unhealthy. A
>     reference to a section of a relevant SCTP document would be better.
>     >
>     > The term "SCTP stream" occurs at least 18 times in the document
>     (out of approx 41 occurences of "stream" overall). We should
>     either use "SCTP stream" consistently" or stick to "Stream"
>     consistently.
>     Changed to Stream consistently.
>     >
>     > The term "SCTP stream identifier" (or "stream identifier")
>     should be called out in the terminology.
>     OK.
>     >
>     > The term "data channel" occurs 36 times. Consider standardizing
>     on either Channel or Data Channel, and either capitalizing it or not.
>     OK. Using Data Channel consistently.
>     >
>     > 6 Procedures
>     > Nit: "the sender of it can start" -> "the sender of the
>     DATA_CHANNEL_OPEN can start"
>     Done.
>     >
>     > "If a DATA_CHANNEL_OPEN message is received .... the stream
>     identifier corresponds to the role of the peer" - is there a
>     reason to insist that the protocol machine enforce the odd/even rule?
>     I would like to define what happens if the peer does not follow
>     the rule... It has to
>     be handled by any implementation, so why leave it up to the
>     implementer?
>     > `(actually the next paragraph does not cover the odd/even rule
>     violation case, which is probably just an unintentional mistake -
>     I prefer writing this kind of thing in "IF  ... ELSE ....
>     Jepp, that was unintentional...
>     >  - because if one writes it as "IF ; IF      condition>", the risk of losing some edge cases is high.
>     >
>     > An alternative formulation for the second paragraph is "If the
>     DATA_CHANNEL_OPEN message doesn't satisfy the conditions above,
>     for instance if..."
>     Good point. I will use:
>     If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions
>     above,
>     for instance if a DATA_CHANNEL_OPEN message is received on an
>     already used
>     Stream or there are any problems with parameters within the
>     DATA_CHANNEL_OPEN
>     message, the odd/even rule is violated or the DATA_CHANNEL_OPEN
>     message itself
>     is not well-formed, the receiver MUST close the corresponding
>     channel using the
>     procedure described in      target='I-D.ietf-rtcweb-data-channel'/> and
>     MUST NOT send a DATA_CHANNEL_ACK message in response to the
>     received message.
>     >
>     > 7 Security Considerations
>     >
>     > The "When using..." paragraph sounds a bit off. What about saying
>     >
>     > This protocol does not provide privacy, integrity or
>     authentication. It needs to be used as part of a protocol suite
>     that contains all these things. Such a protocol suite is specified
>     in [-dtls-encaps].
>     Taken.
>     >
>     > Dependency worries
>     > ---------------------------
>     > -protocol- depends normatively on these non-WG documents:
>     >
>     > draft-ietf-tsvwg-sctp-ndata ("I-D exists")
>     This is currently being worked on.
>     > draft-ietf-tsvwg-sctp-dtls-encaps ("AD is watching")
>     This is passed WG LC, just incorporating the comments. So there
>     will be a new rev tomorrow.
>     > draft-ietf-tsvwg-sctp-prpolicies ("I-D exists")
>     The WG LC started yesterday. Reviews very welcome!
>     > draft-ietf-mmusic-sctp-sdp ("I-D exists")
>     I don't know about the status of this.
>     >
>     > None of these are in the IESG queue. Are we confident of their
>     speed of progress?
>     >
>     >
>     > This concludes my review. I think the protocol definition is
>     ready, and needs no changes.
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > 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
>
>


--------------020708040606090401090003
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 07/08/2014 05:58 AM, Barry Dingle
      wrote:

    

    

      

        

          
I agree with the change to the Abstract in
            draft-ietf-rtcweb-data-channel-10 (see below) as Michael
            proposed. 

            

            
>
              draft-ietf-rtcweb-data-channel-10

            

            

              > ----------------------------------------------

              > Abstract

              >

              > Ten years
                  from now, the RFC will exist, but the
              RTCWEB WG will not. I suggest replacing "The Real-Time
              Communication in Web browsers working group is charged to"
              with "The WebRTC framework specifies".

            

            
OK so it reads:

              <t>The WebRTC framework specifies protocol
                support for direct interactive

              
                rich communication using audio, video, and data between
                two peers' web-browsers.

            

            

          

          But there is great variety in the first introductory words in
          the abstracts in the RTCWEB RFC's. Why not use the one agreed
          introduction in ALL RTCWEB RFC's? 

        

        


        

        Michael's words seem to be appropriate for all.

      

    

    

    I wouldn't mind having standard words in the abstract. It saves
    arguing.

    

    The call for consensus to do so has to come from our chairs, but I'm
    willing to be part of the consensus (if the proposed text isn't too
    egregrious).

    

    

    

      

        


          

            
Cheers,

              /Barry Dingle

              

            

          

          

          

          
On Sat, Jul 5, 2014 at 3:23 AM,
            Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
            wrote:

            

              
On 27 Jun 2014, at 15:00, Harald Alvestrand
                <harald@alvestrand.no>
                wrote:

                

                > On 06/10/2014 08:52 PM, Ted Hardie wrote:

                >> Dear WG,

                >>

                >> This starts a working group last call for our
                core Data Channel drafts:

                >>

                >> draft-ietf-rtcweb-data-protocol-06.txt

                >> draft-ietf-rtcweb-data-channel-10.txt

                >>

                >> Please review them in detail, especially for
                areas which may be of concern to the broader IETF
                community.  This WGLC will end on June 27, 2014.

                >

                > This is my Last Call review of these two drafts.

              

              First of all, thank you very much for the comments.

              
>

                > First of all: The drafts are ready for IETF Last
                Call.

                > Second: There are a number of details that should
                be fixed. Whether that happens before IETF Last Call or
                not is not of great concern to me.

              

              I'll submit an update. That gives all the same basis for
              further discussions.

              
>

                > draft-ietf-rtcweb-data-channel-10

                > ----------------------------------------------

                > Abstract

                >

                > Ten years from now, the RFC will exist, but the
                RTCWEB WG will not. I suggest replacing "The Real-Time
                Communication in Web browsers working group is charged
                to" with "The WebRTC framework specifies".

              

              OK so it reads:

              <t>The WebRTC framework specifies protocol support
              for direct interactive

              rich communication using audio, video, and data between
              two peers' web-browsers.

              
>

                > 1. Introduction

                >

                > It's a little abrupt. Some more words of
                introduction may be needed here. Something like this:

                >

                > In the WebRTC framework, communication between the
                parties consists of media (for example audio and video)
                and non-media data. Media is sent using SRTP, and is not
                specified further here. Non-media data is handled
                by...."

              

              Done. Good suggestion.

              
>

                > I suggest a global replace of "non-SRTP media data"
                with "non-media data" (3 occurences total). "non-SRTP
                media data" can be parsed as "media data that is not
                carried over SRTP", which is not the intended meaning.

              

              Done.

              
>

                > 4. Requirements

                >

                > Suggest striking "and that the WebRTC
                PeerConnection as a whole is fair with competing traffic
                such as TCP". The RMCAT discussions have proved how
                difficult it is just to define that, far less achieve
                it.

                > If we want to say something in relation to TCP, I
                would suggest "and that the WebRTC PeerConnection does
                not cause excessive problems when run in parallel with
                TCP connections".

              

              Taken.

              
>

                > 5. SCTP over DTLS over UDP Considerations

                >

                > In the paragraph on SCTP multihoming, I suggest
                using "the DTLS layer" instead of "the lower layer".
                There are multiple lower layers, identifying which one
                is mentioned here improves clarity.

              

              OK.

              
>

                > The term "user-land" is used here, while Req. 10
                uses "user application space". I suggest using "user
                application space" in both places.

              

              OK.

              
>

                > The paragraph "When using DTLS as the lower
                layer..." repeats the info that SCTP multihoming is not
                used. It may be enough to say this once.

              

              Taken out.

              
>

                > "The partial reliability extension MUST support
                policies..." - this paragraph would be more
                implementable if specific policies, specified in an I-D
                or RFC, were referenced.

              

              References added.

              
>

                > The split between section 5 and section 6 seems
                odd. In particular, the section "This SCTP stack and its
                upper layer...." down to "exactly once and delivered in
                the order received." seems to belong to section 6 not
                section 5.

              

              Text reorganised and removed duplicate text.

              
>

                > 6.1 SCTP Protocol Considerations

                >

                > I think the -ndata messsage interleaving MUST be
                implemented, according to previous consensus.

                > "SHOULD be used" seems both meaningless and
                unneccssary.

              

              I think the current text covers the case that it is not
              available in implementations yet.

              If you write MUST be implemented, a conformant
              implementation would reject interworking

              with currently existing implementations.

              
>

                > 6.2 Association setup

                >

                > Nit: "that can negotiated" -> "that can be
                negotiated"

              

              Fixed.

              
>

                > 6.4 Channel definition

                >

                > The title should probably be "WebRTC Data Channel
                Definition".

              

              OK.

              
>

                > As part of getting the WGs out of the document, the
                first sentence should be "The  WebRTC DataChannels are
                bidirectional."

              

              OK.

              
> "Among other things" is a bad term to
                have in a document at Last Call time. Can we remove it?

              

              Done.

              
>

                > The SHOULD for -ndata- interleaving should be MUST
                implement and MUST offer. If it is not successfully
                negotiated at association setup time (is that how it
                works?), the "SHOULD limit" clause is appropriate.

              

              But if it is MUST implement and MUST offer, how could it
              be not negotiated? If it

              is offered by both sides, it is used. The SHOULD covers
              that it might not be supported.

              So I think the text is in tune with other parts of the
              data channel documents.

              
>

                > 6.7 Closing a channel

                >

                > Nit: "available to reuse" -> "available for
                reuse"

                > Nit: "before resetting the stream" -> "before
                the stream is reset"

              

              Both fixed.

              
>

                > 7 Security considerations

                >

                > Is there a security worry with an attacker sending
                over-long messages in an attempt to cause OOM
                situations?

              

              OK, I added:

              <t>I should be noted that a receiver must be
              prepared that the sender tries

              to send arbitrary large messages.</t>

              
>

                > draft-ietf-rtcweb-data-protocol-06

                > ---------------------------------------------

                > Abstract: Same worry about WG reference.

              

              Same as above.

              
>

                > 3. Terminology

                >

                > Stream is defined in terms of stream, which is
                unhealthy. A reference to a section of a relevant SCTP
                document would be better.

                >

                > The term "SCTP stream" occurs at least 18 times in
                the document (out of approx 41 occurences of "stream"
                overall). We should either use "SCTP stream"
                consistently" or stick to "Stream" consistently.

              

              Changed to Stream consistently.

              
>

                > The term "SCTP stream identifier" (or "stream
                identifier") should be called out in the terminology.

              

              OK.

              
>

                > The term "data channel" occurs 36 times. Consider
                standardizing on either Channel or Data Channel, and
                either capitalizing it or not.

              

              OK. Using Data Channel consistently.

              
>

                > 6 Procedures

                > Nit: "the sender of it can start" -> "the sender
                of the DATA_CHANNEL_OPEN can start"

              

              Done.

              
>

                > "If a DATA_CHANNEL_OPEN message is received ....
                the stream identifier corresponds to the role of the
                peer" - is there a reason to insist that the protocol
                machine enforce the odd/even rule?

              

              I would like to define what happens if the peer does not
              follow the rule... It has to

              be handled by any implementation, so why leave it up to
              the implementer?

              
> `(actually the next paragraph does not
                cover the odd/even rule violation case, which is
                probably just an unintentional mistake - I prefer
                writing this kind of thing in "IF <condition> ...
                ELSE ....

              

              Jepp, that was unintentional...

              
>  - because if one writes it as "IF
                <condition>; IF <opposite condition>", the
                risk of losing some edge cases is high.

                >

                > An alternative formulation for the second paragraph
                is "If the DATA_CHANNEL_OPEN message doesn't satisfy the
                conditions above, for instance if..."

              

              Good point. I will use:

              <t>If the DATA_CHANNEL_OPEN message doesn't satisfy
              the conditions above,

              for instance if a DATA_CHANNEL_OPEN message is received on
              an already used

              Stream or there are any problems with parameters within
              the DATA_CHANNEL_OPEN

              message, the odd/even rule is violated or the
              DATA_CHANNEL_OPEN message itself

              is not well-formed, the receiver MUST close the
              corresponding channel using the

              procedure described in <xref
              target='I-D.ietf-rtcweb-data-channel'/> and

              MUST NOT send a DATA_CHANNEL_ACK message in response to
              the received message.

              
>

                > 7 Security Considerations

                >

                > The "When using..." paragraph sounds a bit off.
                What about saying

                >

                > This protocol does not provide privacy, integrity
                or authentication. It needs to be used as part of a
                protocol suite that contains all these things. Such a
                protocol suite is specified in [-dtls-encaps].

              

              Taken.

              
>

                > Dependency worries

                > ---------------------------

                > -protocol- depends normatively on these non-WG
                documents:

                >

                > draft-ietf-tsvwg-sctp-ndata ("I-D exists")

              

              This is currently being worked on.

              
> draft-ietf-tsvwg-sctp-dtls-encaps ("AD
                is watching")

              

              This is passed WG LC, just incorporating the comments. So
              there will be a new rev tomorrow.

              
> draft-ietf-tsvwg-sctp-prpolicies ("I-D
                exists")

              

              The WG LC started yesterday. Reviews very welcome!

              
> draft-ietf-mmusic-sctp-sdp ("I-D
                exists")

              

              I don't know about the status of this.

              
>

                > None of these are in the IESG queue. Are we
                confident of their speed of progress?

                >

                >

                > This concludes my review. I think the protocol
                definition is ready, and needs no changes.

                >

                >

                >

                >

              

              > _______________________________________________

              > 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

            

          

          

        

      

    

    

  


--------------020708040606090401090003--


From nobody Tue Jul  8 08:01:52 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E0C1A026C for ; Tue,  8 Jul 2014 08:01:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riVRmJckX-xQ for ; Tue,  8 Jul 2014 08:01:44 -0700 (PDT)
Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id CE4C61B2AF3 for ; Tue,  8 Jul 2014 08:01:43 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 9BDD71EB8502 for ; Tue,  8 Jul 2014 17:01:42 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.120]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Tue, 8 Jul 2014 17:01:42 +0200
From: "Hutton, Andrew" 
To: "rtcweb@ietf.org" 
Thread-Topic: Interim meeting - Transports Conclusions
Thread-Index: AQHPmr2GsihPMz0Ymk6O7Hm2IGXq4A==
Date: Tue, 8 Jul 2014 15:01:41 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17E1E652@MCHP04MSX.global-ad.net>
References:  <9F33F40F6F2CD847824537F3C4E37DDF17DF1291@MCHP04MSX.global-ad.net>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17DF1291@MCHP04MSX.global-ad.net>
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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/V1KVAKif5cjD8VYlc0pgC6Kp8hA
Subject: [rtcweb] Interim meeting - Transports Conclusions
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Jul 2014 15:01:50 -0000

VGhlcmUgaGFzIGJlZW4gbm8gZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCByZWdhcmRpbmcgd2hhdCB3
YXMgZGlzY3Vzc2VkIGF0IHRoZSBNYXkgaW50ZXJpbSByZWdhcmRpbmcgd2hhdCB0byBzYXkgaW4g
aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNwb3J0cy0w
NSNzZWN0aW9uLTMuNCByZWdhcmRpbmcgSFRUUCBQcm94aWVzLiAgVW5mb3J0dW5hdGVseSB0aGUg
ZGlzY3Vzc2lvbiBpcyBtaXNzaW5nIGZyb20gdGhlIGRyYWZ0IG1pbnV0ZXMgaG93ZXZlciB0aGUg
ZGlzY3Vzc2lvbiBpcyByZWNvcmRlZCBhbmQgY2FuIGJlIGZvdW5kIDA6NDU6NDUgaW4gdG8gaHR0
cHM6Ly93d3cueW91dHViZS5jb20vd2F0Y2g/dj1zVHVKZnVJM3pIayZsaXN0PVVVOGR0SzluakJM
ZEZuQmFoSEZwMGVaUS4gIA0KDQpJbiBzdW1tYXJ5IHdoYXQgd2FzIGRpc2N1c3NlZCB3YXMgdGhl
IGlzc3VlIG9mIFJUQ1dFQiBicm93c2VycyB1c2luZyBIVFRQIENvbm5lY3QgZm9yIFRVUk4gYW5k
IElDRS1UQ1AgdHJhZmZpYyBpbiB0aGUgcHJlc2VuY2Ugb2YgcHJveGllcy4gTXkgaW50ZXJwcmV0
YXRpb24gb2YgdGhlIGNvbmNsdXNpb24gd2FzIHRoYXQgdGhlcmUgd2FzIGEgbmVlZCB0byB3cml0
ZSBhIGRyYWZ0IHRvIHByb3ZpZGUgYW4gaW5kaWNhdGlvbiBpbiB0aGUgSFRUUCBDb25uZWN0IHJl
cXVlc3QgdG8gaW5kaWNhdGUgdGhhdCB0aGlzIGlzIHRoZSBwdXJwb3NlIGZvciBnZW5lcmF0aW5n
IHRoZSByZXF1ZXN0Lg0KDQpKdXN0aW4sIE1hcnRpbiwgYW5kIEkgdGhlcmVmb3JlIGNyZWF0ZWQg
aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHV0dG9uLWh0dHBiaXMtY29ubmVjdC1w
cm90b2NvbC0wMCB0aGlua2luZyB0aGF0IHRoaXMgd291bGQgaG9wZWZ1bGx5IHJlcGxhY2UgdGhl
IGN1cnJlbnQgcmVmZXJlbmNlIGFuZCB0ZXh0IHJlbGF0aW5nIHRvIGRyYWZ0LWh1dHRvbi1ydGN3
ZWItbmF0LWZpcmV3YWxsLWNvbnNpZGVyYXRpb25zIGluIHRoZSB0cmFuc3BvcnRzIGRyYWZ0IGFu
ZCBob3BlZnVsbHkgdGhlcmVmb3JlIGJlIGEgc3RlcCBjbG9zZXIgdG8gZ2V0dGluZyB0aGUgdHJh
bnNwb3J0cyBkcmFmdCBmaW5pc2hlZC4NCg0KSSB3aWxsIHByZXNlbnQgdGhlIG5ldyBkcmFmdCBp
biB0aGUgSFRUUEJpcyBzZXNzaW9uIGF0IElFVEY5MCBidXQgb2YgY291cnNlIGluIHJ0Y3dlYiB3
ZSBuZWVkIGNvbnNlbnN1cyBvbiB3aGF0IHRvIHB1dCBpbiB0byB0aGUgdHJhbnNwb3J0cyBkcmFm
dC4NCg0KSSBhbSByZWFsbHkgaG9waW5nIHRoaXMgaXMgbm90IHRvbyBjb250cm92ZXJzaWFsIGFu
ZCBJIHJlYWxpemUgdGhhdCBkaXNjdXNzaW9uIG9uIC1maXJld2FsbHMtIHNob3VsZCBiZSBvbiB0
aGUgUE5UQVcgbGlzdCBidXQgdGhpcyBtYWlsIHJlYWxseSByZWxhdGVzIHRvIHdoYXQgdG8gc2F5
IGluIC10cmFuc3BvcnRzLSBzbyBJIHRoaW5rIG5lZWRzIHRvIGJlIG9uIHRoZSBydGN3ZWIgbGlz
dC4gIEN1cnJlbnRseSBJIGFtIHRoaW5raW5nIHRoYXQgSSB3aWxsIGxldCBkcmFmdC1odXR0b24t
cnRjd2ViLW5hdC1maXJld2FsbC1jb25zaWRlcmF0aW9ucyBleHBpcmUuDQoNClJlZ2FyZHMNCkFu
ZHkNCg0KDQoNCg0KDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYu
b3JnXSBPbiBCZWhhbGYgT2YgSHV0dG9uLCBBbmRyZXcNClNlbnQ6IDE3IEp1bmUgMjAxNCAxNjo1
NA0KVG86IFRlZCBIYXJkaWU7IEN1bGxlbiBKZW5uaW5nczsgU2VhbiBUdXJuZXINCkNjOiBydGN3
ZWJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBNaW51dGVzIGFuZCB2aWRlb3MgZnJv
bSB0aGUgSW50ZXJpbSBtZWV0aW5nDQoNCkkgY291bGQgbm90IGZpbmQgYW55dGhpbmcgaW4gdGhl
IG1pbnV0ZXMgcmVnYXJkaW5nIG91ciBkaXNjdXNzaW9uIG9uIHRoZSB0cmFuc3BvcnRzIGRyYWZ0
IChodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzL2ludGVyaW0vMjAxNC8wNS8xOS9ydGN3
ZWIvc2xpZGVzL3NsaWRlcy1pbnRlcmltLTIwMTQtcnRjd2ViLTEtMi5wZGYpLg0KDQpOb3QgaGFk
IHRpbWUgdG8gZG93bmxvYWQgdGhlIHZpZGVvIHlldCBidXQgSSB0aGluayB3ZSBkaXNjdXNzZWQg
dGhpcyBvbiB0aGUgTW9uZGF5IG1vcm5pbmcuDQoNClJlZ2FyZHMNCkFuZHkNCg0KDQoNCg0KRnJv
bTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBU
ZWQgSGFyZGllDQpTZW50OiAxMiBKdW5lIDIwMTQgMTY6NTYNClRvOiBydGN3ZWJAaWV0Zi5vcmc7
IEN1bGxlbiBKZW5uaW5nczsgU2VhbiBUdXJuZXINClN1YmplY3Q6IFtydGN3ZWJdIE1pbnV0ZXMg
YW5kIHZpZGVvcyBmcm9tIHRoZSBJbnRlcmltIG1lZXRpbmcNCg0KRGVhciBXb3JraW5nIEdyb3Vw
LA0KDQpBdHRhY2hlZCBpcyBhIGRyYWZ0IHNldCBvZiBtaW51dGVzIGZyb20gdGhlIG1lZXRpbmcu
wqAgVGhlIHNlY3JldGFyaWF0IGlzIGN1cnJlbnRseSB3b3JraW5nIG9uIG1vdmluZyB0aGUgdmlk
ZW9zIG9mIHRoZSBtZWV0aW5nIHRvIHRoZSBJRVRGIGNoYW5uZWwgYXQgWW91dHViZTsgdGhlIHNv
dXJjZXMgdmlkZW9zIGFyZSBhdmFpbGFibGUgYXQgaHR0cHM6Ly9kcml2ZS5nb29nbGUuY29tLyNm
b2xkZXJzLzBCLTFza2pVd0QtOEVha2htWTJwRmRWODVkSE0gaWYgeW91IHdvdWxkIGxpa2UgdG8g
ZG93bmxvYWQgdGhlbSwgYnV0IHBsZWFzZSBiZSBhd2FyZSB0aGF0IHRoZXkgYXJlIHZlcnkgbGFy
Z2UuDQpDb21tZW50cyBhbmQgY29ycmVjdGlvbnMgb24gdGhlIG1pbnV0ZXMgdG8gdGhlIGxpc3Qg
cGxlYXNlLA0KDQpUZWQsIEN1bGxlbiwgU2Vhbg0K


From nobody Tue Jul  8 09:33:39 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2671B2BB8 for ; Tue,  8 Jul 2014 09:33:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeJ5rLJbbhtb for ; Tue,  8 Jul 2014 09:33:35 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5282D1B2BC2 for ; Tue,  8 Jul 2014 09:33:29 -0700 (PDT)
Received: by mail-wi0-f172.google.com with SMTP id hi2so1333107wib.11 for ; Tue, 08 Jul 2014 09:33:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZacTESRjRwEp7890QfHveuRegHxST7HSGLmmup6TXhg=; b=ll+x1YfQXYLoTD0hcoOwIbxLEehhuL0NIjPP1X/yMZ33ch9RpFdketZmpHtfelLPqr lFzQxza27v18mdnktd/6Vuiwoc37Eall+dU6WFvLUk3TNHDLQUFK6mvM+PH09Gyrpkp1 eUsg65s701DC8VJ2zJRtvUe7YXyxKhsaSfRjIKAm5wurFYlG7h25aZR8+qhV21d2axpg C2mzH4bB/Bk3EbBdfeWa9YGdGAkxJLnH/g5XIlWCJv//9h64o9p/idmbIFiI8YbruI1J 6DAGEGniExHHSU2lJlBvsucDragNLlXVE06ijf3brhEdaCNJWQPeELGB+ZE2o/xcwZWL wA+Q==
X-Gm-Message-State: ALoCoQmr4aiERZ3MM2tq2rCSOn5W16YuhI6YiH3EYfSFzN1fiyOg0Kal0VRnRHt5j1MNV5+lqnkE
X-Received: by 10.194.109.71 with SMTP id hq7mr5553127wjb.114.1404837207065; Tue, 08 Jul 2014 09:33:27 -0700 (PDT)
Received: from [192.168.1.23] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id ev9sm8755015wic.24.2014.07.08.09.33.25 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Jul 2014 09:33:26 -0700 (PDT)
Message-ID: <53BC1D53.4080904@jitsi.org>
Date: Tue, 08 Jul 2014 18:33:23 +0200
From: Emil Ivov 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Roman Shpount ,  "rtcweb@ietf.org" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Eo3AOpQmkdXPofMyNoggBjAvSaU
Subject: Re: [rtcweb] ICE-Mismatch and WebRTC
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Jul 2014 16:33:37 -0000

On 07.07.14, 21:48, Roman Shpount wrote:
> Is it possible to run into ICE-Mismatch with WebRTC? Should we specify
> that default candidate (c= and m= line based candidate) should be
> ignored and thus mismatch check should not be performed?

I guess running into an ICE mismatch with WebRTC is just as possible as 
with any other ICE implementation. I suppose the only difference would 
be that rather than falling back to 3264 semantics, WebRTC 
implementations will rather drop the session because without ICE, they 
wouldn't be able to do consent checks for it.

Emil

-- 
https://jitsi.org


From nobody Tue Jul  8 09:46:39 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875651B2BE1 for ; Tue,  8 Jul 2014 09:46:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNA9_3-M2a7G for ; Tue,  8 Jul 2014 09:46:29 -0700 (PDT)
Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF7A1B2BB7 for ; Tue,  8 Jul 2014 09:46:29 -0700 (PDT)
Received: by mail-ig0-f181.google.com with SMTP id h15so887993igd.2 for ; Tue, 08 Jul 2014 09:46:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=GKCDmr9pZC5vkyQdtxYo4RIrGlUFgcJ5DO1oksL4gf4=; b=bwEA1zq1I/4q9doqGnvCsPoIeCM0CKHZ1NFbXLyX+AaZqOyJyfpDbDX1gxyb9o+uFs YZuGA38SfSmd1Z3IlrOz9oMrM37yuvNzfnShzCptWsVtMuQOLm9FdAeDlpbRa0bWdTtN UsvZjMpCEb1zOxLge9ETq25KUZ49ZXa+q1jVylGL0OchvB3dMKaS0c22OxBsqQjw1aQh 2GYej6U7EcefGCOaAS9PYq1K311aY7nG9gUHqHWiSxlQc+/5FO4NCv1OOwC6qFqqh0fl UNOQWu08iUz+DdbRTwb+johFQwEm7akESr02e6F4Tyhqjr5zyvPJrFn1o7MS4Fugi+wi LeYg==
MIME-Version: 1.0
X-Received: by 10.50.18.76 with SMTP id u12mr5395631igd.13.1404837989092; Tue, 08 Jul 2014 09:46:29 -0700 (PDT)
Received: by 10.42.99.6 with HTTP; Tue, 8 Jul 2014 09:46:29 -0700 (PDT)
Date: Tue, 8 Jul 2014 09:46:29 -0700
Message-ID: 
From: Ted Hardie 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=089e012942d24e946d04fdb1554e
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dN4ZxWVgS-i5oIHjSwawuOJ_Q2o
Subject: [rtcweb] Agenda for IETF 90
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Jul 2014 16:46:33 -0000

--089e012942d24e946d04fdb1554e
Content-Type: text/plain; charset=UTF-8

Howdy,

As you saw, we're starting to finalize the agenda for IETF 90.   Two quick
heads-up related to a conflict with TCPINC on Thursday:  we will try to
front load all the JSEP and security-related discussions onto our Wednesday
session so that Eric and Martin (both of whom have drafts in TCPINC) can
attend there.  We have also asked that we be considered for a time swap, so
our second session might move from Thursday afternoon.  (It's not likely
that we'll get that swap arranged this late, short of some other group
cancelling, but be warned that it could still happen).

regards,

Ted

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


Howdy,

As you saw, we're starting to fin=
alize the agenda for IETF 90.=C2=A0=C2=A0 Two
 quick heads-up related to a conflict with TCPINC on Thursday:=C2=A0 we wil=
l=20
try to front load all the JSEP and security-related discussions onto our=20
Wednesday session so that Eric and Martin (both of whom have drafts in=20
TCPINC) can attend there.=C2=A0 We have also asked that we be considered fo=
r a
 time swap, so our second session might move from Thursday afternoon.=C2=A0=
=20
(It's not likely that we'll get that swap arranged this late, short=
 of=20
some other group cancelling, but be warned that it could still happen).
=

regards,


Ted


--089e012942d24e946d04fdb1554e--


From nobody Tue Jul  8 10:25:26 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD731A038F for ; Tue,  8 Jul 2014 10:25:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F64MTugzYnid for ; Tue,  8 Jul 2014 10:25:20 -0700 (PDT)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BA3E1A0340 for ; Tue,  8 Jul 2014 10:25:20 -0700 (PDT)
Received: by mail-wi0-f172.google.com with SMTP id hi2so1413397wib.11 for ; Tue, 08 Jul 2014 10:25:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2XarHwe6Ql588Lfi48Ln+anPrw81cTSPljczC5VjjpE=; b=TBtLaGB575sOkGsk+men4uygmADInr+UsAZzF5iI3jpQmYeooQ7N3vEDRMbluNPGOq 26LlQwf4lecO31hyxeBZaVg+cmsaCazGyGqYA9uMIJfqiPmtTMa+Lygw30pISkoOEqaW b5h0OFQtW5EDkvpKLBNJbyTVeX4TnVHlQeGxpzZiFUmv1FDIgdUMT1gfofsV93mwZQxv eE8nd2DJ60MuqfglpmKIcnHfXOpZbRch4qpqBQ6Mfmpzoe2vK3cpkmwQkukViVFzx0Z4 TLfXyyMF3b57cMC+R4JLlHjedx8FqADpgE9qYnkjVovD6r0ecTsJn6+3udsFi9x2aoZ9 6A3g==
MIME-Version: 1.0
X-Received: by 10.181.8.233 with SMTP id dn9mr2042015wid.0.1404840319190; Tue, 08 Jul 2014 10:25:19 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Tue, 8 Jul 2014 10:25:19 -0700 (PDT)
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17E1E652@MCHP04MSX.global-ad.net>
References:  <9F33F40F6F2CD847824537F3C4E37DDF17DF1291@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF17E1E652@MCHP04MSX.global-ad.net>
Date: Tue, 8 Jul 2014 10:25:19 -0700
Message-ID: 
From: Martin Thomson 
To: "Hutton, Andrew" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/eAt79UL-MijBQQ-x4GtsauxVUbA
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Interim meeting - Transports Conclusions
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Jul 2014 17:25:22 -0000

On 8 July 2014 08:01, Hutton, Andrew  wrote:
> in rtcweb we need consensus on what to put in to the transports draft.

That's right.  My hope is that we can decide to adopt
draft-thomson-rtcweb-alpn and use the labels that we defined there.


From nobody Tue Jul  8 10:55:09 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DEC1A0418 for ; Tue,  8 Jul 2014 10:55:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OLvQ5EFkekc for ; Tue,  8 Jul 2014 10:55:05 -0700 (PDT)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C411F1A0332 for ; Tue,  8 Jul 2014 10:55:02 -0700 (PDT)
Received: by mail-wi0-f173.google.com with SMTP id cc10so1451005wib.12 for ; Tue, 08 Jul 2014 10:55:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to:content-type; bh=IIUF58mzeuxh3Oi4rYpEwBBq0rLbRTWiO2u8g2RTkks=; b=zJBPLrf4p4W4iEQSyt4KoByOpzAmJCZJo90ADvwdztGswFXYNA0oQ9j8SIcYy/vzGO AIYM3zmljygS1y5tk4mqOQAlZpwLCI/Q/wdLFqGEZh8PlcHdIyYCIhJOk614WC6Tfg/D xC4PHqkTj6++hbxI5JuVDeDX/RamOagN4cpt7JhPejns83Ti/F/43HvRJzZnLO/VVkKc CcmSz0uD0m1so8fl1DQdHVv9+GlRsXmH2rN48Je2uSqv/Rj9PSwQy78MN2khP4SWKXtl AsBqPV7I6C6ZkH65W4rkY+vGbsCv9GeGFJEao8k0CDKqUqtA78ETqdGLnr03a1nc9aoR XlSQ==
X-Received: by 10.180.37.42 with SMTP id v10mr5504091wij.43.1404842101339; Tue, 08 Jul 2014 10:55:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.80.10 with HTTP; Tue, 8 Jul 2014 10:54:41 -0700 (PDT)
From: Bernard Aboba 
Date: Tue, 8 Jul 2014 10:54:41 -0700
Message-ID: 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=e89a8f6473c76a7e0304fdb24a7d
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NWiIru4QIteOdO2LikeBCbErZTs
Subject: [rtcweb] Security Architecture: IdP for RTP and RTCP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Jul 2014 17:55:07 -0000

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

In the situation where RTP and RTCP are not multiplexed, distinct DTLS
transports and DTLS/SRTP key exchanges would occur for RTP and RTCP.

In looking for guidance within the security architecture document, some
questions came to mind:

a. Are the certificates used for RTP and RTCP DTLS Transports necessarily
the same on both the local and remote side? If they are supposed to be the
same, what happens if they aren't?

b. Can different identities be asserted for the RTP and RTCP DTLS
Transports? Does this make sense in some circumstances? If so, when?

Within a browser, it seems logical that the certificates used for RTP and
RTCP DTLS Transports and the asserted identities should be the same
(assuming that RTP and RTCP aren't multiplexed).

The WebRTC 1.0 API Section 8.3 seems to indicate that this should always be
the case:

"It is possible that different values for the "a=identity" attribute is
provided at a media level in SDP. A browser may either choose to treat this
as an error or ignore the attribute. If multiple different assertions are
validated, then they must produce identical identity values."

However, I am wondering whether there can be legitimate cases where a
browser communicating with a gateway or SFU might encounter distinct
identities or certificates for RTP and RTCP.  For example, could an SFU
potentially terminate RTCP but not RTP, in which case the certificates and
asserted identities might be different between RTP and RTCP?

The WebRTC 1.0 spec seems to indicate that this should be treated as a
fatal error, but I'm wondering whether the browser shouldn't be "strict in
what it sends but liberal in handling what it receives" by just using the
identity and certificates for RTP, and ignoring the RTCP identities.
 Trying to inform the user about different asserted identities for RTP and
RTCP seems way too complicated to even be worth considering.

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


In the situation where RTP and RTCP are not multiplex=
ed, distinct DTLS transports and DTLS/SRTP key exchanges would occur for RT=
P and RTCP. =C2=A0

In looking for guidance within =
the security architecture document, some questions came to mind:=C2=A0



a. Are the certificates used for RTP and RTCP DTLS Tran=
sports necessarily the same on both the local and remote side? If they are =
supposed to be the same, what happens if they aren't?




b. Can different identities be asserted for the RTP and RTCP DTL=
S Transports? Does this make sense in some circumstances? If so, when?

Within a browser, it seems logical that the certificat=
es used for RTP and RTCP DTLS Transports and the asserted identities should=
 be the same (assuming that RTP and RTCP aren't multiplexed). =C2=A0



The WebRTC 1.0 API Section 8.3 seems to indicate that t=
his should always be the case:=C2=A0

"It is p=
ossible that different values for the "a=3Didentity" attribute is=
 provided at a media level in SDP. A browser=C2=A0may=C2=A0eithe=
r choose to treat this as an error or ignore the attribute. If multiple dif=
ferent assertions are validated, then they=C2=A0must=C2=A0produ=
ce identical identity values."=C2=A0




However, I am wondering whether there can be legitimate=
 cases where a browser communicating with a gateway or SFU might encounter =
distinct identities or certificates for RTP and RTCP. =C2=A0For example, co=
uld an SFU potentially terminate RTCP but not RTP, in which case the certif=
icates and asserted identities might be different between RTP and RTCP?



The WebRTC 1.0 spec seems to indicate that this should =
be treated as a fatal error, but I'm wondering whether the browser shou=
ldn't be "strict in what it sends but liberal in handling what it =
receives" by just using the identity and certificates for RTP, and ign=
oring the RTCP identities. =C2=A0Trying to inform the user about different =
asserted identities for RTP and RTCP seems way too complicated to even be w=
orth considering.=C2=A0





--e89a8f6473c76a7e0304fdb24a7d--


From nobody Tue Jul  8 11:09:56 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893321A040A for ; Tue,  8 Jul 2014 11:09:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_111=0.6, SPF_PASS=-0.001] autolearn=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 fUY1GE02Ue3N for ; Tue,  8 Jul 2014 11:09:34 -0700 (PDT)
Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789791A0165 for ; Tue,  8 Jul 2014 11:09:34 -0700 (PDT)
Received: by mail-we0-f180.google.com with SMTP id x48so6324205wes.39 for ; Tue, 08 Jul 2014 11:09: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:content-type; bh=wne8OabfCwlBACunwWcm7LKgsgKKhG2ULPyP+1XLj9A=; b=xZ2Krgch2ZBp+XvZUw3fD9x0ToL+4LKj7ReFjuQAZU7Zim6Uww4/Xdx29j7ozq0bJ+ uhCjVks7kzFd/kT7wKJKn4Sl1iy8K5RUxnEdETJQ7I2Wy+OqJBMjkT9M5Tx88I351aXv +ApBRVuViF73RX3J7C8/ugz1r36KQPmREXWVKyJrJWuuqFkHmKrL0tMsKgjFqMyai1r+ Erl4hJG1coB56ltz5ZQXrvtUb70RyskwhU9YpXTo4MQ7fwhHshx/UwaKO4DIvLc8nEc7 VMjlI348D7I+FIAMPa03ba3JosYO5eUBRgr8m0poeqwYh6OAlkwX4IABZ031oUsgmOx+ KVcQ==
MIME-Version: 1.0
X-Received: by 10.194.91.228 with SMTP id ch4mr42176711wjb.59.1404842973063; Tue, 08 Jul 2014 11:09:33 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Tue, 8 Jul 2014 11:09:33 -0700 (PDT)
In-Reply-To: 
References: 
Date: Tue, 8 Jul 2014 11:09:33 -0700
Message-ID: 
From: Martin Thomson 
To: Bernard Aboba 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Dsjb7JYP5w1tq1amuIjqUQlEIHE
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Security Architecture: IdP for RTP and RTCP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Jul 2014 18:09:35 -0000

On 8 July 2014 10:54, Bernard Aboba  wrote:
> In the situation where RTP and RTCP are not multiplexed, distinct DTLS
> transports and DTLS/SRTP key exchanges would occur for RTP and RTCP.
>
> In looking for guidance within the security architecture document, some
> questions came to mind:
>
> a. Are the certificates used for RTP and RTCP DTLS Transports necessarily
> the same on both the local and remote side? If they are supposed to be the
> same, what happens if they aren't?

The certificates can be different.  As you might recall, one of the
issues that we discussed was the possibility of having different
a=fingerprint attributes on different m-lines, as well as having
alternative a=fingerprint lines on the same m-lines.

The current draft handles this by covering multiple fingerprints by
the identity assertion.

> b. Can different identities be asserted for the RTP and RTCP DTLS
> Transports? Does this make sense in some circumstances? If so, when?

a=identity is a session-level attribute and they should (MUST?) only
be one.  So no.  And I can think of any case where this makes sense in
much the same way that having unmultiplexed RTP/RTCP doesn't make
sense any more (if it ever did).

> The WebRTC 1.0 API Section 8.3 seems to indicate that this should always be
> the case:
>
> "It is possible that different values for the "a=identity" attribute is
> provided at a media level in SDP. A browser may either choose to treat this
> as an error or ignore the attribute. If multiple different assertions are
> validated, then they must produce identical identity values."

This is out of date.  I've sent the editors a pull request to have that fixed.

> However, I am wondering whether there can be legitimate cases where a
> browser communicating with a gateway or SFU might encounter distinct
> identities or certificates for RTP and RTCP.  For example, could an SFU
> potentially terminate RTCP but not RTP, in which case the certificates and
> asserted identities might be different between RTP and RTCP?

I think that the way that we manage identity in a multi-party
situation probably needs something different to that.  I don't see any
particular value in terminating RTCP when you aren't also terminating
RTP, the two are far too tightly coupled.  They shouldn't really have
been given different names in the first place.

> The WebRTC 1.0 spec seems to indicate that this should be treated as a fatal
> error, but I'm wondering whether the browser shouldn't be "strict in what it
> sends but liberal in handling what it receives" by just using the identity
> and certificates for RTP, and ignoring the RTCP identities.  Trying to
> inform the user about different asserted identities for RTP and RTCP seems
> way too complicated to even be worth considering.

BTW, I wish that "liberal in what you permit" meme would go away.  I
haven't found it to be particularly useful, except as a fatalistic
acknowledgement of the messy end state that is the Internet.


From nobody Tue Jul  8 11:56:39 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B481A04F1 for ; Tue,  8 Jul 2014 11:56:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.799
X-Spam-Level: 
X-Spam-Status: No, score=-0.799 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, J_CHICKENPOX_111=0.6, J_CHICKENPOX_18=0.6, SPF_PASS=-0.001] autolearn=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 PdlaNoVsmOay for ; Tue,  8 Jul 2014 11:56:36 -0700 (PDT)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EAE91A02EF for ; Tue,  8 Jul 2014 11:56:36 -0700 (PDT)
Received: by mail-we0-f174.google.com with SMTP id u57so6386372wes.5 for ; Tue, 08 Jul 2014 11:56:34 -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:content-type; bh=5ep//+dVvLkF2LtfvRgYU8uEDgQKXeSVnfwshhS4V7E=; b=ns6hoaVbgJ9E/pBLe1e3he8DcC5vT0z0T0QmWPLJ5Fsh2l/pGnQiY9jpo0ytOs4PsU sOGlb/DpZdfopa+W4Dfu4DawteFzt3KHF6sw+s+32ZtpWPvpwK/tSsaVNTnDctOzG7nY 3Xwg/TxYUXsMvetIyPviSzAHwleHGKoiYsQYKTDKRXLMespo2KtF2I1tD6IGHAzZZnjR tNw69l09KQaVF2FdniHpR2uGeT9tXueoItTQrXdGreDCmqGRzZiqcOytX4aTVdJ/DPzB avrTZwyPPnmJY3AIHzl+/kAd55+akz3qLv1fL0uWQ7UQ1Z6KOHZPh0NY9TzKsaphptnr v75Q==
X-Received: by 10.194.110.10 with SMTP id hw10mr42684726wjb.81.1404845794774;  Tue, 08 Jul 2014 11:56:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.80.10 with HTTP; Tue, 8 Jul 2014 11:56:14 -0700 (PDT)
In-Reply-To: 
References:  
From: Bernard Aboba 
Date: Tue, 8 Jul 2014 11:56:14 -0700
Message-ID: 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=089e010d870c8fd47e04fdb32617
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hl2a7rEG_cpq1Rb8u-epb4UeVmg
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Security Architecture: IdP for RTP and RTCP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Jul 2014 18:56:38 -0000

--089e010d870c8fd47e04fdb32617
Content-Type: text/plain; charset=UTF-8

Martin said:

"I think that the way that we manage identity in a multi-party
situation probably needs something different to that.  I don't see any
particular value in terminating RTCP when you aren't also terminating
RTP, the two are far too tightly coupled.  They shouldn't really have
been given different names in the first place."

[BA] You might want to take a look at the following drafts which will be
discussed in AVTCORE:
http://tools.ietf.org/html/draft-mattsson-avtvore-cloud-conferencing-use-case
http://tools.ietf.org/html/draft-cheng-srtp-cloud




On Tue, Jul 8, 2014 at 11:09 AM, Martin Thomson 
wrote:

> On 8 July 2014 10:54, Bernard Aboba  wrote:
> > In the situation where RTP and RTCP are not multiplexed, distinct DTLS
> > transports and DTLS/SRTP key exchanges would occur for RTP and RTCP.
> >
> > In looking for guidance within the security architecture document, some
> > questions came to mind:
> >
> > a. Are the certificates used for RTP and RTCP DTLS Transports necessarily
> > the same on both the local and remote side? If they are supposed to be
> the
> > same, what happens if they aren't?
>
> The certificates can be different.  As you might recall, one of the
> issues that we discussed was the possibility of having different
> a=fingerprint attributes on different m-lines, as well as having
> alternative a=fingerprint lines on the same m-lines.
>
> The current draft handles this by covering multiple fingerprints by
> the identity assertion.
>
> > b. Can different identities be asserted for the RTP and RTCP DTLS
> > Transports? Does this make sense in some circumstances? If so, when?
>
> a=identity is a session-level attribute and they should (MUST?) only
> be one.  So no.  And I can think of any case where this makes sense in
> much the same way that having unmultiplexed RTP/RTCP doesn't make
> sense any more (if it ever did).
>
> > The WebRTC 1.0 API Section 8.3 seems to indicate that this should always
> be
> > the case:
> >
> > "It is possible that different values for the "a=identity" attribute is
> > provided at a media level in SDP. A browser may either choose to treat
> this
> > as an error or ignore the attribute. If multiple different assertions are
> > validated, then they must produce identical identity values."
>
> This is out of date.  I've sent the editors a pull request to have that
> fixed.
>
> > However, I am wondering whether there can be legitimate cases where a
> > browser communicating with a gateway or SFU might encounter distinct
> > identities or certificates for RTP and RTCP.  For example, could an SFU
> > potentially terminate RTCP but not RTP, in which case the certificates
> and
> > asserted identities might be different between RTP and RTCP?
>
> I think that the way that we manage identity in a multi-party
> situation probably needs something different to that.  I don't see any
> particular value in terminating RTCP when you aren't also terminating
> RTP, the two are far too tightly coupled.  They shouldn't really have
> been given different names in the first place.
>
> > The WebRTC 1.0 spec seems to indicate that this should be treated as a
> fatal
> > error, but I'm wondering whether the browser shouldn't be "strict in
> what it
> > sends but liberal in handling what it receives" by just using the
> identity
> > and certificates for RTP, and ignoring the RTCP identities.  Trying to
> > inform the user about different asserted identities for RTP and RTCP
> seems
> > way too complicated to even be worth considering.
>
> BTW, I wish that "liberal in what you permit" meme would go away.  I
> haven't found it to be particularly useful, except as a fatalistic
> acknowledgement of the messy end state that is the Internet.
>

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


Martin said:=C2=A0

"I think that the way that we =
manage identity in a multi-party
situation probably needs something different =
to that. =C2=A0I don't see any


particular valu=
e in terminating RTCP when you aren't also terminating
RTP, the two are far too tightly coupled.=
 =C2=A0They shouldn't really have



been given=
 different names in the first place."

=
[BA] You might want to take a look at the following drafts which will be di=
scussed in AVTCORE:=C2=A0






On Tue, Jul 8, 2014 at 11:09 AM, Martin Thomso=
n <martin.thomson@gmail.com> wrote:



On 8 July 2014 10:54, Bernar=
d Aboba <bernard.aboba@gmail.=
com> wrote:



> In the situation where RTP and RTCP are not multiplexed, distinct DTLS=


> transports and DTLS/SRTP key exchanges would occur for RTP and RTCP.
>

> In looking for guidance within the security architecture document, som=
e

> questions came to mind:

>

> a. Are the certificates used for RTP and RTCP DTLS Transports necessar=
ily

> the same on both the local and remote side? If they are supposed to be=
 the

> same, what happens if they aren't?




The certificates can be different. =C2=A0As you might recall, one of =
the

issues that we discussed was the possibility of having different

a=3Dfingerprint attributes on different m-lines, as well as having

alternative a=3Dfingerprint lines on the same m-lines.



The current draft handles this by covering multiple fingerprints by

the identity assertion.




> b. Can different identities be asserted for the RTP and RTCP DTLS

> Transports? Does this make sense in some circumstances? If so, when?



a=3Didentity is a session-level attribute and they should (MUST?) onl=
y

be one. =C2=A0So no. =C2=A0And I can think of any case where this makes sen=
se in

much the same way that having unmultiplexed RTP/RTCP doesn't make

sense any more (if it ever did).




> The WebRTC 1.0 API Section 8.3 seems to indicate that this should alwa=
ys be

> the case:

>

> "It is possible that different values for the "a=3Didentity&=
quot; attribute is

> provided at a media level in SDP. A browser may either choose to treat=
 this

> as an error or ignore the attribute. If multiple different assertions =
are

> validated, then they must produce identical identity values."




This is out of date. =C2=A0I've sent the editors a pull request t=
o have that fixed.




> However, I am wondering whether there can be legitimate cases where a<=
br>
> browser communicating with a gateway or SFU might encounter distinct
> identities or certificates for RTP and RTCP. =C2=A0For example, could =
an SFU

> potentially terminate RTCP but not RTP, in which case the certificates=
 and

> asserted identities might be different between RTP and RTCP?




I think that the way that we manage identity in a multi-party

situation probably needs something different to that. =C2=A0I don't see=
 any

particular value in terminating RTCP when you aren't also terminating
RTP, the two are far too tightly coupled. =C2=A0They shouldn't really h=
ave

been given different names in the first place.




> The WebRTC 1.0 spec seems to indicate that this should be treated as a=
 fatal

> error, but I'm wondering whether the browser shouldn't be &quo=
t;strict in what it

> sends but liberal in handling what it receives" by just using the=
 identity

> and certificates for RTP, and ignoring the RTCP identities. =C2=A0Tryi=
ng to

> inform the user about different asserted identities for RTP and RTCP s=
eems

> way too complicated to even be worth considering.




BTW, I wish that "liberal in what you permit" meme would go=
 away. =C2=A0I

haven't found it to be particularly useful, except as a fatalistic

acknowledgement of the messy end state that is the Internet.





--089e010d870c8fd47e04fdb32617--


From nobody Tue Jul  8 12:04:29 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2654F1A03BE for ; Tue,  8 Jul 2014 12:04:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMmSH8WXuPC0 for ; Tue,  8 Jul 2014 12:04:26 -0700 (PDT)
Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24B661A0425 for ; Tue,  8 Jul 2014 12:04:23 -0700 (PDT)
Received: by mail-we0-f178.google.com with SMTP id x48so6375664wes.23 for ; Tue, 08 Jul 2014 12:04:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Vliuium/fbXhOV3jblRKcuxkkeqhJclaI7mVXvw+eoY=; b=A8vpDgKdux5LbIUqm1zLMkdrflM7WQfqZukOlOw/A+sB2c9rBVlZXfUMkKObqPkBTI zDo0+5tu5A2hvhOZFPa9YtnFHF966xNuwomBCaEwCeQl5gtmSAvjI3MNUT+y/fUUka6h YdyOpoQfX40zR2vst+L7tyA49/r67Ivfq/aNxWZ2AtDRZqs0/oMDuqj9qF6s0bXhRz8i TrHw2DtqH2WxvS7P3MQsGq9SousNKyaQQNP8AjqoZUpUHoKMt3/UKovyW7yfnnOOoSDq LktHlfyzHWe50AUBit2f9jiWM371ZzDXmikzOMHhXmfRU0kCe/PWpRUqfg38sZ9w9G3M Qb8g==
X-Gm-Message-State: ALoCoQl8rl3+BQEwYlTp4LAdICKLDCaPkplWjKjsIZOCGwp5JaC73GKCidjX4Pp89HAdykkHMYTv
X-Received: by 10.194.71.161 with SMTP id w1mr14080213wju.51.1404846262699; Tue, 08 Jul 2014 12:04:22 -0700 (PDT)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by mx.google.com with ESMTPSA id s14sm3634874wij.1.2014.07.08.12.04.21 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Jul 2014 12:04:21 -0700 (PDT)
Received: by mail-wi0-f174.google.com with SMTP id bs8so1546629wib.7 for ; Tue, 08 Jul 2014 12:04:21 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.222.197 with SMTP id qo5mr43830494wjc.78.1404846261177;  Tue, 08 Jul 2014 12:04:21 -0700 (PDT)
Received: by 10.217.131.17 with HTTP; Tue, 8 Jul 2014 12:04:21 -0700 (PDT)
In-Reply-To: <53BC1D53.4080904@jitsi.org>
References:  <53BC1D53.4080904@jitsi.org>
Date: Tue, 8 Jul 2014 15:04:21 -0400
Message-ID: 
From: Roman Shpount 
To: Emil Ivov 
Content-Type: multipart/alternative; boundary=001a11c3a99a5c96ac04fdb342c3
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EAJ2XT9y39QvkLhxJrJBnhh86Ms
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ICE-Mismatch and WebRTC
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Jul 2014 19:04:28 -0000

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

On Tue, Jul 8, 2014 at 12:33 PM, Emil Ivov  wrote:

> On 07.07.14, 21:48, Roman Shpount wrote:
>
>> Is it possible to run into ICE-Mismatch with WebRTC? Should we specify
>> that default candidate (c= and m= line based candidate) should be
>> ignored and thus mismatch check should not be performed?
>>
>
> I guess running into an ICE mismatch with WebRTC is just as possible as
> with any other ICE implementation. I suppose the only difference would be
> that rather than falling back to 3264 semantics, WebRTC implementations
> will rather drop the session because without ICE, they wouldn't be able to
> do consent checks for it.
>
>
My point was that WebRTC would never use 3264 semantics and use address
from c= and m= lines for any purpose, so why does it need to check that
this address is correct? Would it be more sensible just ignore whatever
value happen to be there? Or, better yet end point can generate an error
instead of generating a response with ice-mismatch.

It would also be nice to define what WebRTC end point is supposed to do if
it gets ice-mismatch attribute in the SDP response. I would assume dropping
the connection is one sensible option. Generating an error would be another
one.

_____________
Roman Shpount

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


On T=
ue, Jul 8, 2014 at 12:33 PM, Emil Ivov <emcho@jitsi.org> wrote=
:


On 07.07.14, 21:48, Roman Shpount wrote:



Is it possible to run into ICE-Mismatch with WebRTC? Should we specify

that default candidate (c=3D and m=3D line based candidate) should be

ignored and thus mismatch check should not be performed?





I guess running into an ICE mismatch with WebRTC is just as possible as wit=
h any other ICE implementation. I suppose the only difference would be that=
 rather than falling back to 3264 semantics, WebRTC implementations will ra=
ther drop the session because without ICE, they wouldn't be able to do =
consent checks for it.



=C2=A0
My point was that WebR=
TC would never use 3264 semantics and use address from c=3D and m=3D lines =
for any purpose, so why does it need to check that this address is correct?=
 Would it be more sensible just ignore whatever value happen to be there? O=
r, better yet end point can generate an error instead of generating a respo=
nse with ice-mismatch.



It would also be nice to define what WebRTC end point i=
s supposed to do if it gets=C2=A0ice-mismatch attribute in the SDP response. I would assume dropping th=
e connection is one sensible option. Generating an error would be another o=
ne.



_____________
Roman Shpount
=C2=A0


--001a11c3a99a5c96ac04fdb342c3--


From nobody Tue Jul  8 12:12:32 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB4F1A0545 for ; Tue,  8 Jul 2014 12:12:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 Tknv4d5MFG8y for ; Tue,  8 Jul 2014 12:12:31 -0700 (PDT)
Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE7F21A0255 for ; Tue,  8 Jul 2014 12:12:30 -0700 (PDT)
Received: by mail-qc0-f181.google.com with SMTP id x13so5772750qcv.12 for ; Tue, 08 Jul 2014 12:12:30 -0700 (PDT)
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:content-type:content-transfer-encoding; bh=vhDuOVNbsoNfXsczqwZsdATzQPdXgREKh3SY2FiA6RQ=; b=Je2qCGoqnOT/uwg3gOrIc50joiLPFZfc1XpIq0ocDkM52zogMC5wuE9o1grcMcIWaa MCnn7c4EaMIyZfV+/me1AslqQEoUmDFK3ANMLLWCy7iz9KKzV/AznVRnSjvPuNnvRB4c q/pZ5AY3L+0tFYYJ+0gUNbvWnHUS94ZaUze7/kk7PjasBJEqLJhVjPi8dpsx4gbbaCCj SfAcotKkcKSADN6QUj+QTjC7/tztecOBEYYxOHZ0rbZBOyUQPB7NEc87ZSC7XvIKgZ5C qlaB8V3Lk0JOJleeDQlWJ5w18sspIjTvf+P8RpnnvADHL2Ic+kKXef4cSg0ZxKDBPm+o CEmg==
X-Gm-Message-State: ALoCoQlmknglMmbijvYAuTWRanEHhmURsxVWdPMEK8JyCYJPZgumSoWUJetLTd5F4GuJWPT6emcD
X-Received: by 10.140.88.230 with SMTP id t93mr49112405qgd.47.1404846746041; Tue, 08 Jul 2014 12:12:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Tue, 8 Jul 2014 12:12:05 -0700 (PDT)
In-Reply-To: 
References:  
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Tue, 8 Jul 2014 21:12:05 +0200
Message-ID: 
To: Martin Thomson 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xYGM1lZpWMlyW9RK3IUOr8XBlSo
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Security Architecture: IdP for RTP and RTCP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Jul 2014 19:12:32 -0000

2014-07-08 20:09 GMT+02:00 Martin Thomson :
> I think that the way that we manage identity in a multi-party
> situation probably needs something different to that.  I don't see any
> particular value in terminating RTCP when you aren't also terminating
> RTP, the two are far too tightly coupled.  They shouldn't really have
> been given different names in the first place.

I agree. The fact that RTP and RTCP seem two different protocols and,
even more, the fact that they can be carried over different
transports, does not mean that we should imagine exotic scenarios in
which a media endpoint generates just RTP or just RTCP.

OK, a media endpoint could be internally divided into different
components, one of then handling RTP and the other RTCP, but form the
point of view of media transmission it should behave as a single
endpoint.


--=20
I=C3=B1aki Baz Castillo



From nobody Tue Jul  8 12:16:44 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC34A1A055D for ; Tue,  8 Jul 2014 12:16:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 USc6wtAReNRR for ; Tue,  8 Jul 2014 12:16:35 -0700 (PDT)
Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 187EF1A04F8 for ; Tue,  8 Jul 2014 12:16:35 -0700 (PDT)
Received: by mail-qa0-f54.google.com with SMTP id s7so1244433qap.41 for ; Tue, 08 Jul 2014 12:16:34 -0700 (PDT)
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:content-type:content-transfer-encoding; bh=cmWdSsxhDTEwgjO62Z3bPGT5wTti+1sQmHUfNGlnDK0=; b=Myhzesy7UZLTzK20mx+IbS86TJ83mZQplAMN6B7nA6k9vrXO7HkMtKaCwmNRpwgAJw mMJK5snkrB5VnRUNXa6Y51taRXuEsYuYNbETDwdovpYMWLxMKrhe4JDETcIHKbW+jBTo bJzmnoCIqN1LKQnet+iBvfz6wPslOLjDiqhoz0S6vnsc4989oPE0lh5LMA+Jf7/5sAIA XYXQmEPWJfv2h5FueCITI4MpzbpYH9T4JWZUSvRki33I9Orkh/oEQeJmWxA/Pn3rxs9M 6XC5QD76ax6hAsYCdbnEYrhK5Wzn3saMXH7e3IHrHZVNfb5gvUS186GFAita1AF+rjQr bACg==
X-Gm-Message-State: ALoCoQn1IzodoAagn2kPjRyJtwy6q7zyPSkPCQhBgm3YjWUIgXQrheCHoZyGvWTaqOeKh6Zegpmi
X-Received: by 10.224.87.130 with SMTP id w2mr62288714qal.5.1404846994268; Tue, 08 Jul 2014 12:16:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Tue, 8 Jul 2014 12:16:14 -0700 (PDT)
In-Reply-To: 
References:  <53BC1D53.4080904@jitsi.org> 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Tue, 8 Jul 2014 21:16:14 +0200
Message-ID: 
To: Roman Shpount 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/swoEPDKwxsHqLlsuYhJZDndpYvA
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ICE-Mismatch and WebRTC
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Jul 2014 19:16:36 -0000

2014-07-08 21:04 GMT+02:00 Roman Shpount :
> My point was that WebRTC would never use 3264 semantics and use address f=
rom
> c=3D and m=3D lines for any purpose, so why does it need to check that th=
is
> address is correct? Would it be more sensible just ignore whatever value
> happen to be there?

I assume that is exactly what current WebRTC browsers do.

Yes, we could drop the entire m line and instead use a "media
identifier" (mid), and we could drop the half of the classic content
of a SDP. But that would break interop with future legacy gateways.



--=20
I=C3=B1aki Baz Castillo



From nobody Tue Jul  8 13:04:36 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C610E1A0019 for ; Tue,  8 Jul 2014 13:04:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxYJU5ciMQf1 for ; Tue,  8 Jul 2014 13:04:33 -0700 (PDT)
Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EC7C1A000F for ; Tue,  8 Jul 2014 13:04:33 -0700 (PDT)
Received: by mail-vc0-f170.google.com with SMTP id hy10so5960870vcb.15 for ; Tue, 08 Jul 2014 13:04:32 -0700 (PDT)
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:content-type; bh=8BAJleMfMmrxSKEWUZMnNnrauy19HKKA/Nk687IyCqE=; b=FibBGL7vmutKdqNLSaxapTEubhAlSLd2IxVQtN6qxPtAD1kO34EoCVVrNptHuOXMCW M5+TLqJTi40gSX+BQ5S38RttdGgUXzJ09ny67OXsQoCo9GJQmhiPDtDVxWh4m+Kktgiu GbPj4pSiNyLIJzhKk8hbcEzgf//SS8AvGeVkcVqS96PrIxY1YoiDgKTtI+v3zZRS9DQa MgKWir1UDDqd0GjsBSeivGz3+IHNwfS5lHf1Rs9mUeh6wYFzejnOACTGzxUV2Xcu0pvA 38DMrQqTlbyztMh24TDdiSKKPQix+jVeUTGTvtUSnL3sGtU43ht9x/zWp4UheiJRcjD2 iWxw==
X-Gm-Message-State: ALoCoQlzSpT0dfZw3BocacwFGW61DaxW01XlrFff7qQxqf83otTrzhRcw4C4Tfu7Q3UBZS6BvKb9
X-Received: by 10.52.113.37 with SMTP id iv5mr1610871vdb.51.1404849872252; Tue, 08 Jul 2014 13:04:32 -0700 (PDT)
Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by mx.google.com with ESMTPSA id d2sm27402645vec.16.2014.07.08.13.04.31 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Jul 2014 13:04:31 -0700 (PDT)
Received: by mail-vc0-f179.google.com with SMTP id id10so6044600vcb.10 for ; Tue, 08 Jul 2014 13:04:31 -0700 (PDT)
X-Received: by 10.58.46.34 with SMTP id s2mr2032058vem.49.1404849871722; Tue, 08 Jul 2014 13:04:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.238.75 with HTTP; Tue, 8 Jul 2014 13:04:10 -0700 (PDT)
In-Reply-To: 
References:  <53BC1D53.4080904@jitsi.org> 
From: Emil Ivov 
Date: Tue, 8 Jul 2014 22:04:10 +0200
Message-ID: 
To: Roman Shpount 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uKEYvNurKwkzHhbDeAZq7G8qtSg
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ICE-Mismatch and WebRTC
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Jul 2014 20:04:34 -0000

On Tue, Jul 8, 2014 at 9:04 PM, Roman Shpount  wrote:
> On Tue, Jul 8, 2014 at 12:33 PM, Emil Ivov  wrote:
>>
>> On 07.07.14, 21:48, Roman Shpount wrote:
>>>
>>> Is it possible to run into ICE-Mismatch with WebRTC? Should we specify
>>> that default candidate (c= and m= line based candidate) should be
>>> ignored and thus mismatch check should not be performed?
>>
>>
>> I guess running into an ICE mismatch with WebRTC is just as possible as
>> with any other ICE implementation. I suppose the only difference would be
>> that rather than falling back to 3264 semantics, WebRTC implementations will
>> rather drop the session because without ICE, they wouldn't be able to do
>> consent checks for it.
>>
>
> My point was that WebRTC would never use 3264 semantics

Indeed. This was also my point.

> and use address from
> c= and m= lines for any purpose, so why does it need to check that this
> address is correct? Would it be more sensible just ignore whatever value
> happen to be there?

With the exception of trickle ICE's use of :: (or 0.0.0.0) an ICE
mismatch indicates that there is an entity on the signalling path that
is overwriting c= line addresses and m= line ports. The idea of
dropping ICE here is that the infrastructure is likely performing
Hosted NAT Traversal and latching so insisting on ICE is likely to
lead to unexpected situations.

> Or, better yet end point can generate an error instead
> of generating a response with ice-mismatch.

Agreed. Sending an answer with ice-mismatch means downgrading to basic
3264 and that doesn't make sense for WebRTC.

Agreed.

Emil

-- 
https://jitsi.org


From nobody Tue Jul  8 14:34:24 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C2C1A0141 for ; Tue,  8 Jul 2014 14:34:23 -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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 lrQjLH_ww_ca for ; Tue,  8 Jul 2014 14:34:21 -0700 (PDT)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 714B21A0127 for ; Tue,  8 Jul 2014 14:34:21 -0700 (PDT)
Received: by mail-wi0-f170.google.com with SMTP id cc10so1824196wib.3 for ; Tue, 08 Jul 2014 14:34:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hGlULPOGenmt8TunoqVSBuraGTx1o8Ia0ZlhbFmzCSE=; b=oc0NeRuyqM2vZSGZZMbrgSzuaCKMN3CObmBHr9kxXWNoxMIw2B1yrgYSm2a8H33k8p cgtXkk6zr4dJiA4x5i29LqjPSdPo38ejN3w6X6y7lejDBRNFwpvZTU+Br61GCVPNYXDJ 5PkT3XYAFYxqhzd3GDOTRZuV+ks3zXjvj01BbE/DURUEFTKQlfgQBK6n8JY7gpwWnaFp 5jINSUeDlgfUexRGkxkaipSJaJTgrsKc5GJkA8uWrOSO+X7nZcjkXOkPQH0vRtrxPz58 3ogswz66Iyx4wYxAKxC14OLcoBrt6etFRJuJbkNEXWNquWFVwBkgL8jvNeU3eW53e0i0 cdig==
X-Received: by 10.180.75.75 with SMTP id a11mr6691343wiw.3.1404855259941; Tue, 08 Jul 2014 14:34:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.80.10 with HTTP; Tue, 8 Jul 2014 14:33:59 -0700 (PDT)
In-Reply-To: 
References:   
From: Bernard Aboba 
Date: Tue, 8 Jul 2014 14:33:59 -0700
Message-ID: 
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Content-Type: multipart/alternative; boundary=f46d04388e95bad15d04fdb55ae2
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wIyLcR5LLPolrfZmbX5UkH1SdeA
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Security Architecture: IdP for RTP and RTCP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Jul 2014 21:34:23 -0000

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

Inaki said: "OK, a media endpoint could be internally divided into differen=
t
components, one of then handling RTP and the other RTCP, but form the
point of view of media transmission it should behave as a single
endpoint."

[BA] It seems logical for the browser to utilize the same identity for both
RTP and RTCP, regardless of whether they are multiplexed or not.

However, if both the RTP and RTCP peer assertions are validated, shouldn't
it be up to the application decide whether to care?

A given application could compare the RTP and RTCP identities and consider
it a fatal error if the identities are not the same, OR it could decide to
ignore the RTCP identity.

BTW, the "compare" operation is potentially non-trivial in the case of
internationalized identities.  None of the specifications currently
describe how the identities are to be normalized in preparation for the
comparison, so I can imagine that some "fun" could be had there.




On Tue, Jul 8, 2014 at 12:12 PM, I=C3=B1aki Baz Castillo  wr=
ote:

> 2014-07-08 20:09 GMT+02:00 Martin Thomson :
> > I think that the way that we manage identity in a multi-party
> > situation probably needs something different to that.  I don't see any
> > particular value in terminating RTCP when you aren't also terminating
> > RTP, the two are far too tightly coupled.  They shouldn't really have
> > been given different names in the first place.
>
> I agree. The fact that RTP and RTCP seem two different protocols and,
> even more, the fact that they can be carried over different
> transports, does not mean that we should imagine exotic scenarios in
> which a media endpoint generates just RTP or just RTCP.
>
> OK, a media endpoint could be internally divided into different
> components, one of then handling RTP and the other RTCP, but form the
> point of view of media transmission it should behave as a single
> endpoint.
>
>
> --
> I=C3=B1aki Baz Castillo
> 
>

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


Inaki said: "OK, a media endpoint could be internally divided into d=
ifferent
components, one o=
f then handling RTP and the other RTCP, but form the


point of view o=
f media transmission it should behave as a single
endpoint."



[BA] It seems logical for the browser to utilize the same id=
entity for both RTP and RTCP, regardless of whether they are multiplexed or=
 not.=C2=A0

However, if both the RTP and RTCP peer=
 assertions are validated, shouldn't it be up to the application decide=
 whether to care?=C2=A0




A given application could compare the RTP and RTCP iden=
tities and consider it a fatal error if the identities are not the same, OR=
 it could decide to ignore the RTCP identity.=C2=A0



BTW, the "compare" operation is potentially non-trivial in the ca=
se of internationalized identities. =C2=A0None of the specifications curren=
tly describe how the identities are to be normalized in preparation for the=
 comparison, so I can imagine that some "fun" could be had there.=
 =C2=A0







On Tue, Jul 8, 2014 at 12:12 PM, I=C3=B1aki Baz Cast=
illo <ibc@aliax.net> wrote:



2014-07-08 20:09 GMT+02:00 Martin Thomson &l=
t;martin.thomson@gmail.com&=
gt;:




> I think that the way that we manage identity in a mult=
i-party

> situation probably needs something different to that. =C2=A0I don'=
t see any

> particular value in terminating RTCP when you aren't also terminat=
ing

> RTP, the two are far too tightly coupled. =C2=A0They shouldn't rea=
lly have

> been given different names in the first place.




I agree. The fact that RTP and RTCP seem two different protocols and,=


even more, the fact that they can be carried over different

transports, does not mean that we should imagine exotic scenarios in

which a media endpoint generates just RTP or just RTCP.



OK, a media endpoint could be internally divided into different

components, one of then handling RTP and the other RTCP, but form the

point of view of media transmission it should behave as a single

endpoint.





--

I=C3=B1aki Baz Castillo

<ibc@aliax.net>





--f46d04388e95bad15d04fdb55ae2--


From nobody Tue Jul  8 14:39:21 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEAC1A013B for ; Tue,  8 Jul 2014 14:39:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XajL-Bu4vjN7 for ; Tue,  8 Jul 2014 14:39:17 -0700 (PDT)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A3391A0117 for ; Tue,  8 Jul 2014 14:39:16 -0700 (PDT)
Received: by mail-wi0-f172.google.com with SMTP id hi2so1731197wib.17 for ; Tue, 08 Jul 2014 14:39:15 -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:content-type; bh=Te06FArxoRUs/0a6JxOq1kgczrraMEXC4gETgfudqw0=; b=hVvfwbOeFa1gKFXXTPZezE+IfZ5fBOe3ulO1PM7M5GWRiAVqY6burqzAFrZCXKcLy+ KCD9JKdvg9Ec09DyF9mTYV+SysaMpqe33v96pceEiH4kqC0KQsDpY9IELaPf6FhBiixv fcOZrYs0nsGX93iQtNKQxrqEjNwW/F1OEol5p+iXwLR16fM1FQoqZNHTKsjyIaWmg4kV BujOuvZ84mGIM3DTgT9qXP4kq1RslgCEEZJmNHdxwSkHjr8g/AgHSnqUHq2SANVyW+aH n82qH5e/50y1wyH7ltaPkVpyot0510BfNiFRuDE6nY4RLuDm4wgKv48epFURGtvBtoYU C9dQ==
X-Received: by 10.180.83.200 with SMTP id s8mr6809610wiy.2.1404855555667; Tue, 08 Jul 2014 14:39:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.80.10 with HTTP; Tue, 8 Jul 2014 14:38:55 -0700 (PDT)
In-Reply-To: 
References:  <9F33F40F6F2CD847824537F3C4E37DDF17DF1291@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF17E1E652@MCHP04MSX.global-ad.net> 
From: Bernard Aboba 
Date: Tue, 8 Jul 2014 14:38:55 -0700
Message-ID: 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=14dae9cc92d45b3e7504fdb56c5a
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QCZcgsqwGuu1cTzUdEa9FH0xFbg
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Interim meeting - Transports Conclusions
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Jul 2014 21:39:18 -0000

--14dae9cc92d45b3e7504fdb56c5a
Content-Type: text/plain; charset=UTF-8

Martin said:

"That's right.  My hope is that we can decide to adopt
draft-thomson-rtcweb-alpn and use the labels that we defined there."

[BA] Maybe my memory is faulty... but didn't we discuss adoption
previously???


On Tue, Jul 8, 2014 at 10:25 AM, Martin Thomson 
wrote:

> On 8 July 2014 08:01, Hutton, Andrew  wrote:
> > in rtcweb we need consensus on what to put in to the transports draft.
>
> That's right.  My hope is that we can decide to adopt
> draft-thomson-rtcweb-alpn and use the labels that we defined there.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

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


Martin said:=C2=A0

"That's right. =C2=A0My ho=
pe is that we can decide to adopt
draft-thomson-rtcweb-alpn and use the l=
abels that we defined there."




[BA] Maybe my memory is faulty... but didn't we dis=
cuss adoption previously???


<=
div class=3D"gmail_quote">On Tue, Jul 8, 2014 at 10:25 AM, Martin Thomson <=
span dir=3D"ltr"><martin.thomson@gmail.com> wrote:



On 8 July 2014 08:01, Hutton=
, Andrew <andrew.hutton@unify=
.com> wrote:



> in rtcweb we need consensus on what to put in to the transports draft.=





That's right. =C2=A0My hope is that we can decide to adopt

draft-thomson-rtcweb-alpn and use the labels that we defined there.




_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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





--14dae9cc92d45b3e7504fdb56c5a--


From nobody Tue Jul  8 14:47:05 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8B11A0149 for ; Tue,  8 Jul 2014 14:47:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4_6yVKoC6YO for ; Tue,  8 Jul 2014 14:47:03 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E5051A0146 for ; Tue,  8 Jul 2014 14:47:03 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id hi2so1738558wib.1 for ; Tue, 08 Jul 2014 14:47:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ppdlgDQA6Rl7NuPmGrhijBiKZP1Thn/W2CB4zK3sGhc=; b=IqSlESxKzQaA5WA72V0ntTJ0QskeQxDjp6wAmGRvRzJ0nIYK0EDY+sSBJcoftOspql 4Jy2TAt2XHu3mQEJ4kjgkh7LXvA71SdlLYDzXAHKkZt2mVucQt3nT8/e43md/H3zFgl1 x2xzD1oWQVQ8Q9pbNwrep5uvK3j/aSK1Kq+NAN2Ry1S4j1j5ZVFiCyzADSCx/cA7F2eA Qd9N+IhJRaygXa1PaheQx9DAcC/gddk9foDcrBQfHx6wRpnj/ZFrTLKVuyEMPQCrqsrO HZi76pZUNXj3lbz5YBxmB/XR1eKfv7ZN0Jxzbe2jmC6ThthaJN/lsxUygYPybxMAMoHM Acmw==
MIME-Version: 1.0
X-Received: by 10.180.81.37 with SMTP id w5mr6733784wix.65.1404856022019; Tue, 08 Jul 2014 14:47:02 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Tue, 8 Jul 2014 14:47:01 -0700 (PDT)
In-Reply-To: 
References:    
Date: Tue, 8 Jul 2014 14:47:01 -0700
Message-ID: 
From: Martin Thomson 
To: Bernard Aboba 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/47swn4OSxzsv2QI13gg6rdK-ogU
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Security Architecture: IdP for RTP and RTCP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Jul 2014 21:47:04 -0000

On 8 July 2014 14:33, Bernard Aboba  wrote:
> BTW, the "compare" operation is potentially non-trivial in the case of
> internationalized identities.  None of the specifications currently describe
> how the identities are to be normalized in preparation for the comparison,
> so I can imagine that some "fun" could be had there.

FWIW, the right hand side of identity is well defined:
http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10#section-5.6.5.4.1

The LHS is completely open to confusable glyphs and all sorts of
horrors.  I really want to avoid stringprep or whatever it's current
incarnation looks like, that's probably unavoidable long term.  For
now though, can we not pretend that the IdP knows what they are doing?


From nobody Tue Jul  8 15:22:50 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05AD1A0164 for ; Tue,  8 Jul 2014 15:22:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGvtkEF42a_k for ; Tue,  8 Jul 2014 15:22:46 -0700 (PDT)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A901A0162 for ; Tue,  8 Jul 2014 15:22:46 -0700 (PDT)
Received: by mail-ie0-f182.google.com with SMTP id at20so1458737iec.27 for ; Tue, 08 Jul 2014 15:22:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=AD5dAXB8Ln4fPYdmDCulvd5gPSpHZ+YGRlbV2SG+by0=; b=Z+JZ6xkMG5aDtK8LG7hju5zqh9SZkS4GXXJ53l2A4lqYugTy5GJOfNgo88oYtxpEZy yNsy/G4kD66+XHKE9uhTmBgBQ1P0pwkWCRJ8yZRgOPDm2AkOMg6QtteXydJ+yrtw91xK uMQYCGsSMNBNvhGNgt0d8L+6RgWx3HuRvCjwEaiOI/9FYI5Qlv+d+7UmdJ8VXqe8YbbT Tfe74RMn+1qW7L+PFCAj1g3W4faSAEjlvCvinmNKoWj+WgTi4H5048YMpACEVnEOB3N7 Lo+0FkxZ6SntWrgbICS3/iSGU/uBG+7v5XV9etUkR42VNCrd1QJvIzH+pX0mqzH40+JF pzBQ==
MIME-Version: 1.0
X-Received: by 10.50.141.170 with SMTP id rp10mr7440682igb.6.1404858165768; Tue, 08 Jul 2014 15:22:45 -0700 (PDT)
Received: by 10.42.99.6 with HTTP; Tue, 8 Jul 2014 15:22:45 -0700 (PDT)
Date: Tue, 8 Jul 2014 15:22:45 -0700
Message-ID: 
From: Ted Hardie 
To: "rtcweb@ietf.org" , Richard Barnes 
Content-Type: multipart/alternative; boundary=089e0122ada2ee37db04fdb6074c
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_8JqdXt9XETGafncPYCZrFnHA6Q
Subject: [rtcweb] Requesting adoption of draft-thomson-rtcweb-alpn
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Jul 2014 22:22:48 -0000

--089e0122ada2ee37db04fdb6074c
Content-Type: text/plain; charset=UTF-8

As Bernard pointed out, we agreed in the interim to request working group
adoption of this draft, but did not formally ask the WG to do so.

This is the formal request for adoption of draft-thomson-rtcweb-alpn.  If
you have objections to the WG adopting this item, please raise them as soon
as possible; if none by July 15th, we will discuss with the ADs getting the
draft added and a work item assigned.

regards,

Ted Hardie

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


As Bernard pointed out, we agreed in the interim to=
 request working group adoption of this draft, but did not formally ask the=
 WG to do so.


This is the formal request for adoption of draft-thomson-rtcweb-alpn.=C2=A0 If you have objections to the WG adopting t=
his item, please raise them as soon as possible; if none by July 15th, we w=
ill discuss with the ADs getting the draft added and a work item assigned. =



regards,

Ted Hardie


--089e0122ada2ee37db04fdb6074c--


From nobody Tue Jul  8 16:31:16 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8437F1A017D for ; Tue,  8 Jul 2014 16:31:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.951
X-Spam-Level: 
X-Spam-Status: No, score=-13.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5EZDeHZ5K9G for ; Tue,  8 Jul 2014 16:31:13 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 849341A0083 for ; Tue,  8 Jul 2014 16:31:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11031; q=dns/txt; s=iport; t=1404862275; x=1406071875; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=Oc3wyelddI4GI9C5F5JrRA2P57Uu7hf0qt4fPaPlISw=; b=aVuuoQBcXDdobkRA48Ktpvpduv6BFDlvWce6t9eOruZ8cdqppNWGUQ34 /K2/RHjKz6yKZQADNNtkpN1tA7XER5huaiBnnNzBaSG1Giv0jtz/X0jMv hbUcxW5mdo1y1kHbK0aEaKv2YYGmjMeFpApLT/Kvs1Hl+hc2LgBsHYzIl k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8xANt9vFOtJV2Q/2dsb2JhbABRCYJHR1KEZRW5MIFWAQmGHk5TAYETFnWEAwEBAQMBAQEBawsFCwsSBi4hBiIOBhOILgMJCA3BAw2HDReNGIFPWweDLYEWBYpRjiWCAIFIhUeGaYYUg2MdgTMk
X-IronPort-AV: E=Sophos;i="5.01,628,1400025600";  d="scan'208,217";a="338638526"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-8.cisco.com with ESMTP; 08 Jul 2014 23:31:14 +0000
Received: from [10.21.71.254] ([10.21.71.254]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s68NVA75010144 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Jul 2014 23:31:11 GMT
Content-Type: multipart/alternative; boundary="Apple-Mail=_2D748F31-8A4D-45FA-9BD9-6F8DD3CDC3B0"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Dan Wing 
In-Reply-To: 
Date: Tue, 8 Jul 2014 16:31:13 -0700
Message-Id: 
References:   
To: Bernard Aboba 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_LYNYdKfVCB4DmMj7vCyZXlCAaM
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Security Architecture: IdP for RTP and RTCP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Jul 2014 23:31:15 -0000

--Apple-Mail=_2D748F31-8A4D-45FA-9BD9-6F8DD3CDC3B0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Jul 8, 2014, at 11:56 AM, Bernard Aboba  =
wrote:

> Martin said:=20
>=20
> "I think that the way that we manage identity in a multi-party
> situation probably needs something different to that.  I don't see any
> particular value in terminating RTCP when you aren't also terminating
> RTP, the two are far too tightly coupled.  They shouldn't really have
> been given different names in the first place."
>=20
> [BA] You might want to take a look at the following drafts which will =
be discussed in AVTCORE:=20
> =
http://tools.ietf.org/html/draft-mattsson-avtvore-cloud-conferencing-use-c=
ase
> http://tools.ietf.org/html/draft-cheng-srtp-cloud

Related, "Requirements for Secure RTP Media Switching", =
http://tools.ietf.org/html/draft-ismail-avtcore-media-req

-d


>=20
>=20
>=20
>=20
> On Tue, Jul 8, 2014 at 11:09 AM, Martin Thomson =
 wrote:
> On 8 July 2014 10:54, Bernard Aboba  wrote:
> > In the situation where RTP and RTCP are not multiplexed, distinct =
DTLS
> > transports and DTLS/SRTP key exchanges would occur for RTP and RTCP.
> >
> > In looking for guidance within the security architecture document, =
some
> > questions came to mind:
> >
> > a. Are the certificates used for RTP and RTCP DTLS Transports =
necessarily
> > the same on both the local and remote side? If they are supposed to =
be the
> > same, what happens if they aren't?
>=20
> The certificates can be different.  As you might recall, one of the
> issues that we discussed was the possibility of having different
> a=3Dfingerprint attributes on different m-lines, as well as having
> alternative a=3Dfingerprint lines on the same m-lines.
>=20
> The current draft handles this by covering multiple fingerprints by
> the identity assertion.
>=20
> > b. Can different identities be asserted for the RTP and RTCP DTLS
> > Transports? Does this make sense in some circumstances? If so, when?
>=20
> a=3Didentity is a session-level attribute and they should (MUST?) only
> be one.  So no.  And I can think of any case where this makes sense in
> much the same way that having unmultiplexed RTP/RTCP doesn't make
> sense any more (if it ever did).
>=20
> > The WebRTC 1.0 API Section 8.3 seems to indicate that this should =
always be
> > the case:
> >
> > "It is possible that different values for the "a=3Didentity" =
attribute is
> > provided at a media level in SDP. A browser may either choose to =
treat this
> > as an error or ignore the attribute. If multiple different =
assertions are
> > validated, then they must produce identical identity values."
>=20
> This is out of date.  I've sent the editors a pull request to have =
that fixed.
>=20
> > However, I am wondering whether there can be legitimate cases where =
a
> > browser communicating with a gateway or SFU might encounter distinct
> > identities or certificates for RTP and RTCP.  For example, could an =
SFU
> > potentially terminate RTCP but not RTP, in which case the =
certificates and
> > asserted identities might be different between RTP and RTCP?
>=20
> I think that the way that we manage identity in a multi-party
> situation probably needs something different to that.  I don't see any
> particular value in terminating RTCP when you aren't also terminating
> RTP, the two are far too tightly coupled.  They shouldn't really have
> been given different names in the first place.
>=20
> > The WebRTC 1.0 spec seems to indicate that this should be treated as =
a fatal
> > error, but I'm wondering whether the browser shouldn't be "strict in =
what it
> > sends but liberal in handling what it receives" by just using the =
identity
> > and certificates for RTP, and ignoring the RTCP identities.  Trying =
to
> > inform the user about different asserted identities for RTP and RTCP =
seems
> > way too complicated to even be worth considering.
>=20
> BTW, I wish that "liberal in what you permit" meme would go away.  I
> haven't found it to be particularly useful, except as a fatalistic
> acknowledgement of the messy end state that is the Internet.
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--Apple-Mail=_2D748F31-8A4D-45FA-9BD9-6F8DD3CDC3B0
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

On Jul 8, 2014, at 11:56 AM, Bernard Aboba <bernard.aboba@gmail.com> wrote:

Martin said: 

"I think that the way that we manage identity in a multi-party
situation probably needs something different to that.  I don't see any


particular value in terminating RTCP when you aren't also terminating
RTP, the two are far too tightly coupled.  They shouldn't really have



been given different names in the first place."

[BA] You might want to take a look at the following drafts which will be discussed in AVTCORE: 




Related, "Requirements for Secure RTP Media Switching", http://tools.ietf.org/html/draft-ismail-avtcore-media-req

-d









On Tue, Jul 8, 2014 at 11:09 AM, Martin Thomson <martin.thomson@gmail.com> wrote:



On 8 July 2014 10:54, Bernard Aboba <bernard.aboba@gmail.com> wrote:



> In the situation where RTP and RTCP are not multiplexed, distinct DTLS

> transports and DTLS/SRTP key exchanges would occur for RTP and RTCP.

>

> In looking for guidance within the security architecture document, some

> questions came to mind:

>

> a. Are the certificates used for RTP and RTCP DTLS Transports necessarily

> the same on both the local and remote side? If they are supposed to be the

> same, what happens if they aren't?




The certificates can be different.  As you might recall, one of the

issues that we discussed was the possibility of having different

a=fingerprint attributes on different m-lines, as well as having

alternative a=fingerprint lines on the same m-lines.



The current draft handles this by covering multiple fingerprints by

the identity assertion.




> b. Can different identities be asserted for the RTP and RTCP DTLS

> Transports? Does this make sense in some circumstances? If so, when?




a=identity is a session-level attribute and they should (MUST?) only

be one.  So no.  And I can think of any case where this makes sense in

much the same way that having unmultiplexed RTP/RTCP doesn't make

sense any more (if it ever did).




> The WebRTC 1.0 API Section 8.3 seems to indicate that this should always be

> the case:

>

> "It is possible that different values for the "a=identity" attribute is

> provided at a media level in SDP. A browser may either choose to treat this

> as an error or ignore the attribute. If multiple different assertions are

> validated, then they must produce identical identity values."




This is out of date.  I've sent the editors a pull request to have that fixed.




> However, I am wondering whether there can be legitimate cases where a

> browser communicating with a gateway or SFU might encounter distinct

> identities or certificates for RTP and RTCP.  For example, could an SFU

> potentially terminate RTCP but not RTP, in which case the certificates and

> asserted identities might be different between RTP and RTCP?




I think that the way that we manage identity in a multi-party

situation probably needs something different to that.  I don't see any

particular value in terminating RTCP when you aren't also terminating

RTP, the two are far too tightly coupled.  They shouldn't really have

been given different names in the first place.




> The WebRTC 1.0 spec seems to indicate that this should be treated as a fatal

> error, but I'm wondering whether the browser shouldn't be "strict in what it

> sends but liberal in handling what it receives" by just using the identity

> and certificates for RTP, and ignoring the RTCP identities.  Trying to

> inform the user about different asserted identities for RTP and RTCP seems

> way too complicated to even be worth considering.




BTW, I wish that "liberal in what you permit" meme would go away.  I

haven't found it to be particularly useful, except as a fatalistic

acknowledgement of the messy end state that is the Internet.




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


--Apple-Mail=_2D748F31-8A4D-45FA-9BD9-6F8DD3CDC3B0--


From nobody Wed Jul  9 04:02:56 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B151A03F2 for ; Wed,  9 Jul 2014 04:02:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40Up9DpSj1gs for ; Wed,  9 Jul 2014 04:02:52 -0700 (PDT)
Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F044C1A03F1 for ; Wed,  9 Jul 2014 04:02:51 -0700 (PDT)
Received: by mail-ve0-f172.google.com with SMTP id db12so2332437veb.31 for ; Wed, 09 Jul 2014 04:02:51 -0700 (PDT)
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:content-type; bh=eT01ZPAJwyK0Y2h9g/dAX2hfsujrcQRPXKp6kBLMOMQ=; b=ZvOFKTxTpS1SlxtwTdw9m7p3GpiGqHvQl93kNegcrfw0b5slNgzch1Z87ZY+5JMWI8 C/qsttICBu6VhVcZEol5sImo7dGyQ5lG/nbdBHgu9gViN75tLWnWwgGAVXZWXx+bD3l0 QeiVLJuLeiYaGfAVHCnnPjM/qSRxgOKjnzECP/1zGTYAePaxtyioTBLX5P4kRFxRunDd Fz+vO/xXlvlc9YN7o87DYdeNw0UvddUHefIjoESzC6Z28ZdynhLMS41RPGX2o7lvzqAK PXVbr6U20lN0ZKQyzQue0X//ZIOjpIHNO5y00HO97elibefnNs65MvxmVgAX0yMFYeVl WYUw==
X-Gm-Message-State: ALoCoQm1RusimYdYfz9UhrzPr//9cngkv9rmuZxUxarjBFOcqsJMxZt5y8qRerA6Maufuj/Tz5XS
X-Received: by 10.220.166.9 with SMTP id k9mr38767802vcy.20.1404903771035; Wed, 09 Jul 2014 04:02:51 -0700 (PDT)
Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by mx.google.com with ESMTPSA id m10sm41237963vdj.28.2014.07.09.04.02.50 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Jul 2014 04:02:50 -0700 (PDT)
Received: by mail-ve0-f180.google.com with SMTP id jw12so6923001veb.39 for ; Wed, 09 Jul 2014 04:02:50 -0700 (PDT)
X-Received: by 10.221.40.193 with SMTP id tr1mr1587970vcb.31.1404903770525; Wed, 09 Jul 2014 04:02:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.238.75 with HTTP; Wed, 9 Jul 2014 04:02:29 -0700 (PDT)
In-Reply-To: 
References:  
From: Emil Ivov 
Date: Wed, 9 Jul 2014 13:02:29 +0200
Message-ID: 
To: Martin Thomson 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/AUWO-OrsAU_kZCG1PSFcYtgbnu0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Security Architecture: IdP for RTP and RTCP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Jul 2014 11:02:54 -0000

On Tue, Jul 8, 2014 at 8:09 PM, Martin Thomson  wrote:
> I think that the way that we manage identity in a multi-party
> situation probably needs something different to that.  I don't see any
> particular value in terminating RTCP when you aren't also terminating
> RTP, the two are far too tightly coupled.  They shouldn't really have
> been given different names in the first place.

Adding to what others have said: this is only true today because of
the current state of things. In the SFU we are working on, we would
*love* not to terminate RTP encryption (it would mean slashing CPU
requirements by an order of magnitude at least) but we'd still need to
terminate RTCP. Not possible today but that's fixable as long as we
make sure we don't dig ourselves deeper into that hole.

Emil
-- 
https://jitsi.org


From nobody Thu Jul 10 21:33:35 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCBC1A02EE for ; Thu, 10 Jul 2014 21:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.133
X-Spam-Level: *
X-Spam-Status: No, score=1.133 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 MAh3HTl5P_ZE for ; Thu, 10 Jul 2014 21:33:33 -0700 (PDT)
Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.93.164.18]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 321491A02E6 for ; Thu, 10 Jul 2014 21:33:33 -0700 (PDT)
Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id 7779D976819D8; Thu, 10 Jul 2014 23:33:32 -0500 (CDT)
Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 577EC97681974 for ; Thu, 10 Jul 2014 23:33:32 -0500 (CDT)
Received: from [96.231.227.95] (port=58969 helo=[192.168.1.6]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X5SWZ-0007DT-MH for rtcweb@ietf.org; Thu, 10 Jul 2014 23:33:31 -0500
From: Sean Turner 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <2F10B543-E1E7-4E24-A16D-88236B17FA9E@ieca.com>
Date: Fri, 11 Jul 2014 00:33:28 -0400
To: rtcweb@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator3286.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source-IP: 96.231.227.95
X-Exim-ID: 1X5SWZ-0007DT-MH
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: ([192.168.1.6]) [96.231.227.95]:58969
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 2
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kdT_Q7j0VYhpTI2SW9UXrGc-EJ4
Subject: [rtcweb] WGLC for security drafts
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 04:33:34 -0000

Dear WG,

This starts a working group last call for our the two security-related =
drafts:

draft-ietf-rtcweb-security-07
draft-ietf-rtcweb-security-arch-10

Please review them in detail.  This WGLC will end on 8 August, 2014.

Ted, Sean, Cullen=


From nobody Fri Jul 11 05:26:47 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040EA1B2891 for ; Fri, 11 Jul 2014 05:26:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 hmD2ZGQ8D00D for ; Fri, 11 Jul 2014 05:26:44 -0700 (PDT)
Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE6E31B288F for ; Fri, 11 Jul 2014 05:26:44 -0700 (PDT)
Received: by mail-qa0-f41.google.com with SMTP id j7so146003qaq.14 for ; Fri, 11 Jul 2014 05:26:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=1jZhYCe8agV/LrmFoN8f5ofhBhJtwKGatg9UiIudwiI=; b=EOpgOPFc9nHdC4wzRop2sSVUtRxr6b+87SBoK0LMIIX9uE1iekt1DTFFj/AoR9CPYY RjDt0zn/G1gy3kj0Ig4avIuMszwPcrAZjzWHla0G0ON0+KIWwLybhaeRfEUj9FdPXmpi sAMndr3mKgEbKd3kRurqgeC+DekWcZgxjdBlUqm8x7LrwbCGwz+qWRY1XZtLJOL+LitB 5vn2i4v0e6WDNdF5ahFjsAd1FJKTHI/OrG2YNa7v+KmGV4kfZvvo42AyNUi4Q4Jt5+T5 TLIkNBOATh+S1CR5i5vggKfHDrAqurYuNVgYmFwFZw5QiUK2hk2C4xT3QbEITMkIueXs ckuw==
X-Gm-Message-State: ALoCoQlJOETg8z7Jm2025KSWcDOICnhDY112L8lkCP17BQdWz29c+MYxDo+DPLpzN746JBLkGEKX
X-Received: by 10.140.34.55 with SMTP id k52mr85844747qgk.13.1405081603940; Fri, 11 Jul 2014 05:26:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Fri, 11 Jul 2014 05:26:23 -0700 (PDT)
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Fri, 11 Jul 2014 14:26:23 +0200
Message-ID: 
To: "rtcweb@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GslHXUKxjCRoxf3IfFbRL1isI3E
Subject: [rtcweb] Which hashes are valid for the fingerprint attribute?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 12:26:46 -0000

Hi,

Hi, RFC 5763 and RFC 5764 (DTLS-SRTP) do not mandate a specific hash
for the fingerprint attribute in the SDP. RFC 5763 refers to RFC 4572
"Connection-Oriented Media Transport over TLS in SDP=E2=80=9D. Its section =
5
clearly opens the door to multiple hash functions:

   hash-func    =3D  "sha-1" / "sha-224" / "sha-256" /
                         "sha-384" / "sha-512" /
                         "md5" / "md2" / token
                         ; Additional hash functions can only come
                         ; from updates to RFC 3279


I'm pretty sure that WebRTC implementations are not ready for all
those hash functions. Is there any WebRTC related draft constraining
the hash functions that can be used?

Thanks a lot.


PS: Not sure if this question should be placed here or in public-webrtc ML.

--=20
I=C3=B1aki Baz Castillo



From nobody Fri Jul 11 06:10:11 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A151A04CD for ; Fri, 11 Jul 2014 06:10:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 4u3qmUI4sRUk for ; Fri, 11 Jul 2014 06:10:03 -0700 (PDT)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B961B2ABD for ; Fri, 11 Jul 2014 06:09:26 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id hr17so423740lab.30 for ; Fri, 11 Jul 2014 06:09:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=LSjeBF0g4ZIEa9yVBPR2fMPQCGDeIR96QA7s3WFR6x4=; b=0ese/PQa4eWjGMFOGdLz6/gugFqc4+ObWI9LezCuxGDqOj22X7vOEdl6mP4WBwydYR QYzDlGVfYlQb2isPFwxXab4w+RhY7oJMSLCcjLTxYgt4GpC/yYNkqXnreOT4t8lXnbFi TEOinsgVUJxFjwl7qQcxtYEfozc2Pdty8NDzY+gOFr11vGlyao0ofvS2iXbHJkmpC3S4 Rvx4buDGr/N3AykllfofiV11pCphXIgQNTGOWhlsxJKVWIxurZYe15WpLg92nMGOMTY3 BsRQsb3Ex5KHkWmtD3IeDD2e9RH95kmWx6+j4xsHGFi4IePaHurOcGAKuyPomIrwqm80 kpZg==
MIME-Version: 1.0
X-Received: by 10.112.13.106 with SMTP id g10mr3618476lbc.79.1405084164795; Fri, 11 Jul 2014 06:09:24 -0700 (PDT)
Sender: xavier.marjou@gmail.com
Received: by 10.114.243.198 with HTTP; Fri, 11 Jul 2014 06:09:24 -0700 (PDT)
In-Reply-To: <7F2087CA-E3B9-41B1-8022-62953BB7A6C9@iii.ca>
References: <7F2087CA-E3B9-41B1-8022-62953BB7A6C9@iii.ca>
Date: Fri, 11 Jul 2014 15:09:24 +0200
X-Google-Sender-Auth: u6_4BwC3ad5VBWIKlEQUq8edeCA
Message-ID: 
From: Xavier Marjou 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c3b66e85b59504fdeaa6b9
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0JwUZIuuF0dJ6JOfmzm6BaVU6Dg
Subject: Re: [rtcweb] Draft agenda for IETF 90
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 13:10:04 -0000

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

> Audio (15 min)

> - people wanted a consensus call on other codecs (AMR, etc)



Regarding this item, I understand that the chairs will recap the discussion
(comments and way-forward) of the interim meeting about
draft-proust-rtcweb-audio-codecs-for-interop-00.

>From that perspective, a consensus call may rather occur at the meeting of
November to give more time to additional e-mail discussions and update of
the draft accordingly.

Is my understanding ok?



Cheers,

Xavier


On Wed, Jul 2, 2014 at 8:33 PM, Cullen Jennings  wrote:

>
> Here is a very rough draft of agenda for IETF 90 meeting. It will change a
> bunch.
>
> -------------------------------------
>
>
> Very draft agenda V1
>
>
> Agenda Bashing ( 5 min )
>
> WG Status Updates ( 5 min )
>
> JSEP ( 90 min )
>
> RTP Usage  (30 min)
>
> Transport (20 min)
>
> Overview (20 min)
>
> Stun Consent Freshness (20 min)
>
> Security (if no WGLC prior) (20 min)
>
> Audio (15 min)
> - people wanted a consensus call on other codecs (AMR, etc)
>
> Video (15 min)
> - review the issues other than the MTI codec part
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

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


> Audio (=
15 min)



> - people wanted a consen=
sus call on
other codecs (AMR, etc)



=C2=A0



Regarding this item, I unders=
tand that
the chairs will recap the discussion (comments and way-forward) of the inte=
rim
meeting about draft-proust-rtcweb-audio-codecs-for-interop-00. 



From that perspective, a cons=
ensus call
may rather occur at the meeting of November to give more time to additional
e-mail discussions and update of the draft accordingly.



Is my understanding ok?



=C2=A0



Cheers,



Xavier


On Wed, Jul 2, 2014 at 8:33 PM, Cu=
llen Jennings <fluffy@iii.ca> wrote:




Here is a very rough draft of agenda for IETF 90 meeting. It will change a =
bunch.



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





Very draft agenda V1





Agenda Bashing ( 5 min )



WG Status Updates ( 5 min )



JSEP ( 90 min )



RTP Usage =C2=A0(30 min)



Transport (20 min)



Overview (20 min)



Stun Consent Freshness (20 min)



Security (if no WGLC prior) (20 min)



Audio (15 min)

- people wanted a consensus call on other codecs (AMR, etc)



Video (15 min)

- review the issues other than the MTI codec part



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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





--001a11c3b66e85b59504fdeaa6b9--


From nobody Fri Jul 11 08:06:56 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B311B2911 for ; Fri, 11 Jul 2014 08:06:34 -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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 WXIFeIkvaQoF for ; Fri, 11 Jul 2014 08:06:33 -0700 (PDT)
Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE8E51B2B70 for ; Fri, 11 Jul 2014 08:05:54 -0700 (PDT)
Received: by mail-ob0-f169.google.com with SMTP id nu7so1315929obb.14 for ; Fri, 11 Jul 2014 08:05:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1ZpYyq+rwP4bnPEvs4QhorCMDf1bvfVw5Nt3Dtc/B+g=; b=uyteBHvri4CiPXFhMD/19JHJ12daX3COD3sNPJJ5p4q0FSNEFD62hX36MZLYzqyLwl hjur2NTHSownL7pvRyVksOLqrXu4ZRgBEzvirrTDwr/kc20PECstRo3jdocY2fQXBamw ulfPR7LBSsucy8nrQU49qMpaKWRZP2kZCMgVFxuaiOql40EmR25Do0ec4NvkbkTCtXr1 PMU1d+Z2gNRX3y2ottBLGB3x4B+fsKtX/ZQ1rTDD6HdcNIix1J/4ckC4UhYfuyVg53gD WnwJ3WFi50JnJ+XqauwoMB1IZZVbaASNitjioxiYwrJpCT3x6rD9U37VRvlMSgyVEo3W yx2g==
MIME-Version: 1.0
X-Received: by 10.182.245.164 with SMTP id xp4mr21498603obc.23.1405091154118;  Fri, 11 Jul 2014 08:05:54 -0700 (PDT)
Received: by 10.202.208.72 with HTTP; Fri, 11 Jul 2014 08:05:54 -0700 (PDT)
In-Reply-To: 
References: 
Date: Fri, 11 Jul 2014 23:05:54 +0800
Message-ID: 
From: Alexandre GOUAILLARD 
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Content-Type: multipart/alternative; boundary=001a11c2b2ee1e4dd704fdec47b8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9z7XRks_fl132TtEoCZgWvq-8lA
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Which hashes are valid for the fingerprint attribute?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 15:06:35 -0000

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

Inaki,

I checked a little bit, following our previous exchange.

There was a thread back in november last year in discuss-webrtc (how to
specify desired hash function(s) (sha-1, sha-256, sha-512) for DTLS-SRTP?)

Justin said "Chrome supports various hash functions in the remote
description (SHA-1, 256, 512). Local description currently only
supports SHA-256,
no plans to change that (although we will probably support longer hashes in
the future for hash agility). Asymmetric hash functions should not be an
issue. If multiple fingerprints are specified in the remote description, I
think Chrome will only use the first one."

then in ORTC there was this thread in april:
"Issue 64: Section 2.5.1 Fingerprint attribute"
in which bernard proposed:
"
dictionary RTCDtlsParameters {
    RTCDtlsRole                  role =3D "auto";
    sequence fingerprint;
};
dictionary RTCDtlsFingerprint {
    RTCDtlsCertificateHashAlgorithm algorithm;
    ArrayBuffer                     value;
};
enum RTCDtlsCertificateHashAlgorithm {
    "sha-1",
    "sha-224",
    "sha-256",
    "sha-384",
    "sha-512"
};
"







On Fri, Jul 11, 2014 at 8:26 PM, I=C3=B1aki Baz Castillo  wr=
ote:

> Hi,
>
> Hi, RFC 5763 and RFC 5764 (DTLS-SRTP) do not mandate a specific hash
> for the fingerprint attribute in the SDP. RFC 5763 refers to RFC 4572
> "Connection-Oriented Media Transport over TLS in SDP=E2=80=9D. Its sectio=
n 5
> clearly opens the door to multiple hash functions:
>
>    hash-func    =3D  "sha-1" / "sha-224" / "sha-256" /
>                          "sha-384" / "sha-512" /
>                          "md5" / "md2" / token
>                          ; Additional hash functions can only come
>                          ; from updates to RFC 3279
>
>
> I'm pretty sure that WebRTC implementations are not ready for all
> those hash functions. Is there any WebRTC related draft constraining
> the hash functions that can be used?
>
> Thanks a lot.
>
>
> PS: Not sure if this question should be placed here or in public-webrtc M=
L.
>
> --
> I=C3=B1aki Baz Castillo
> 
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>



--=20
Alex. Gouaillard, PhD, PhD, MBA
---------------------------------------------------------------------------=
---------
CTO - Temasys Communications, S'pore / Mountain View
President - CoSMo Software, Cambridge, MA
---------------------------------------------------------------------------=
---------
sg.linkedin.com/agouaillard

   -

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


Inaki,=C2=A0

I checked a little bit, fo=
llowing our previous exchange.

There was a thread back i=
n november last year in discuss-webrtc (how to specify desired hash function(s) (sha-1,=C2=A0sha-256,=C2=A0sha-512) for DTLS-SRTP?)




Justin said "Chrome supports various h=
ash functions in the remote description (SHA-1, 256, 512). Local description currently only supports=C2=A0<=
/span>SHA-256, no plans=
 to change that (although we will probably support longer hashes in the fut=
ure for hash agility).=C2=A0Asymmetric hash functions should not be an issue. If mu=
ltiple fingerprints are specified in the remote description, I think Chrome=
 will only use the first one."




then in ORTC there was this thread in ap=
ril:
"Issue 64: Section 2.5.1=C2=A0Fingerprint attribute"




in which bern=
ard proposed:
=
"
dictionary RTCDtlsParameters {

=C2=A0 =C2=A0 R=
TCDtlsRole =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ro=
le =3D "auto";
=
=C2=A0 =C2=A0 sequence<RTCDtlsFingerprint> fingerprint;

};
dictionary RTCDtl=
sFingerprint {

=C2=A0 =C2=A0 R=
TCDtlsCertificateHashAlgorithm algorithm;

=C2=A0 =C2=A0 A=
rrayBuffer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 value;
};
enum RTCDtlsCer=
tificateHashAlgorithm {

=C2=A0 =C2=A0 &=
quot;sha-1=
",

=C2=A0 =C2=A0 &=
quot;sha-224",

=C2=A0 =C2=A0 &=
quot;sha-256",

=C2=A0 =C2=A0 &=
quot;sha-384",

=C2=A0 =C2=A0 &=
quot;sha-512"

};
"














On Fri, Jul 11, 2014 at 8:26 PM, I=C3=B1aki Baz Castillo =
<ibc@aliax.net>=
; wrote:

Hi,



Hi, RFC 5763 and RFC 5764 (DTLS-SRTP) do not mandate a specific hash

for the fingerprint attribute in the SDP. RFC 5763 refers to RFC 4572

"Connection-Oriented Media Transport over TLS in SDP=E2=80=9D. Its sec=
tion 5

clearly opens the door to multiple hash functions:



=C2=A0 =C2=A0hash-func =C2=A0 =C2=A0=3D =C2=A0"sha-1" / "sha=
-224" / "sha-256" /

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0"sha-384" / "sha-512" /

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0"md5" / "md2" / token

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0; Additional hash functions can only come

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0; from updates to RFC 3279





I'm pretty sure that WebRTC implementations are not ready for all

those hash functions. Is there any WebRTC related draft constraining

the hash functions that can be used?



Thanks a lot.





PS: Not sure if this question should be placed here or in public-webrtc ML.=




--

I=C3=B1aki Baz Castillo

<ibc@aliax.net>



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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





-- 
Alex. Gouaillard, PhD, PhD, MBA
--------------------=
----------------------------------------------------------------

CTO - Temasys Communications, S'pore / Mountain View
Presiden=
t - CoSMo Software, Cambridge, MA
-------------------------------=
-----------------------------------------------------


    

  • 





--001a11c2b2ee1e4dd704fdec47b8--


From nobody Fri Jul 11 08:58:29 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46181B2B41 for ; Fri, 11 Jul 2014 08:58:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level: 
X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YA-Vl6DE1gIm for ; Fri, 11 Jul 2014 08:58:24 -0700 (PDT)
Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A61541A0AA7 for ; Fri, 11 Jul 2014 08:58:24 -0700 (PDT)
Received: by mail-vc0-f182.google.com with SMTP id hq11so2489307vcb.27 for ; Fri, 11 Jul 2014 08:58:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cTqChEy9ty1yv7t8iKgcSSKbuBoRk9eUQ60MgV9LN5k=; b=TyK4Eimm9V3DyoWNcRLAl1oFb5QYjVCxpc0Jf8oKgH82uEGmIaWUgNwdmGJGO7no2l kpg0BfwqbNM2SK9Sv1JXT1kpa/p10XaL00E7TxoSJEm1aUYc5IXzPceZvAesFdEpp618 AZ51K0wq5j8ZJHREaaEXqeGpeWHX20chGOW8S6CYTC9OVOC34Yw+H9Gul2C5Oj+BAqq6 M46kUBZk+mMKsL6BlXhSpIbSeCRzjU6Bcskz7qfubQUKY8YFD7XtgFYmlmwg9+bXYhjf r6dfGNw0T9Jvrqg+3f60FYPleneMPF6AzHTnR/oXrO+jpq+DkxEUu3zwGkwHzrA+m4kU 9Wxw==
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:content-type; bh=cTqChEy9ty1yv7t8iKgcSSKbuBoRk9eUQ60MgV9LN5k=; b=C8bs818xAKGzx47YVrFoTVMPmwn7lbxj2U/0zxyeqxBoC9WTkK+imBk3wB39JOkfOl uEmd+E9QLSkooeSN3rtXIX5WALJeBy32vmo4qvkZreydTEgFvvOuzhWa8q2N2R8DhaRl iCv1BJ+XzYtMrcKUHp5eYlbRBMgu21EYakqM6uJSpPw1+C2u6K0Gep0nt2MGvatXSl40 AbaX67Vfui7x1AyRCLfra2OQyNrjo0sBVZgAK6C7+maKYAKJl70mmLEMoGDD77eRqq70 XrNkyC1IaM7ZzhV38bo1iPkrWVaaNKi8dXFzE8zC2KVVTWxQ7Nh/K7XHyiD0uLzK9o81 yhTQ==
X-Gm-Message-State: ALoCoQmR6XASgSvLBdsXQNeFAK4MjOMI1h7otaq4NqyYtazPhCNc5FYJTdqOWHAndBDe+8T1QCAw
X-Received: by 10.58.228.74 with SMTP id sg10mr51487583vec.6.1405094303729; Fri, 11 Jul 2014 08:58:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.27.8 with HTTP; Fri, 11 Jul 2014 08:58:02 -0700 (PDT)
In-Reply-To: 
References:  
From: Justin Uberti 
Date: Fri, 11 Jul 2014 08:58:02 -0700
Message-ID: 
To: Alexandre GOUAILLARD 
Content-Type: multipart/alternative; boundary=047d7bd6a91cd9b3f104fded02ec
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/pPpQJHB1KIHp2O9unm8IvNXhAZo
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Which hashes are valid for the fingerprint attribute?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 15:58:27 -0000

--047d7bd6a91cd9b3f104fded02ec
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The recommended algorithms to support probably needs to appear in the
security document; JSEP should also mention or point to the recommended
algorithms to use when generating the digest.


On Fri, Jul 11, 2014 at 8:05 AM, Alexandre GOUAILLARD  wrote:

> Inaki,
>
> I checked a little bit, following our previous exchange.
>
> There was a thread back in november last year in discuss-webrtc (how to
> specify desired hash function(s) (sha-1, sha-256, sha-512) for DTLS-SRTP?=
)
>
> Justin said "Chrome supports various hash functions in the remote
> description (SHA-1, 256, 512). Local description currently only supports
> SHA-256, no plans to change that (although we will probably support
> longer hashes in the future for hash agility). Asymmetric hash functions
> should not be an issue. If multiple fingerprints are specified in the
> remote description, I think Chrome will only use the first one."
>
> then in ORTC there was this thread in april:
> "Issue 64: Section 2.5.1 Fingerprint attribute"
> in which bernard proposed:
> "
> dictionary RTCDtlsParameters {
>     RTCDtlsRole                  role =3D "auto";
>     sequence fingerprint;
> };
> dictionary RTCDtlsFingerprint {
>     RTCDtlsCertificateHashAlgorithm algorithm;
>     ArrayBuffer                     value;
> };
> enum RTCDtlsCertificateHashAlgorithm {
>     "sha-1",
>     "sha-224",
>     "sha-256",
>     "sha-384",
>     "sha-512"
> };
> "
>
>
>
>
>
>
>
> On Fri, Jul 11, 2014 at 8:26 PM, I=C3=B1aki Baz Castillo  =
wrote:
>
>> Hi,
>>
>> Hi, RFC 5763 and RFC 5764 (DTLS-SRTP) do not mandate a specific hash
>> for the fingerprint attribute in the SDP. RFC 5763 refers to RFC 4572
>> "Connection-Oriented Media Transport over TLS in SDP=E2=80=9D. Its secti=
on 5
>> clearly opens the door to multiple hash functions:
>>
>>    hash-func    =3D  "sha-1" / "sha-224" / "sha-256" /
>>                          "sha-384" / "sha-512" /
>>                          "md5" / "md2" / token
>>                          ; Additional hash functions can only come
>>                          ; from updates to RFC 3279
>>
>>
>> I'm pretty sure that WebRTC implementations are not ready for all
>> those hash functions. Is there any WebRTC related draft constraining
>> the hash functions that can be used?
>>
>> Thanks a lot.
>>
>>
>> PS: Not sure if this question should be placed here or in public-webrtc
>> ML.
>>
>> --
>> I=C3=B1aki Baz Castillo
>> 
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>
>
> --
> Alex. Gouaillard, PhD, PhD, MBA
>
> -------------------------------------------------------------------------=
-----------
>  CTO - Temasys Communications, S'pore / Mountain View
> President - CoSMo Software, Cambridge, MA
>
> -------------------------------------------------------------------------=
-----------
> sg.linkedin.com/agouaillard
>
>    -
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

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


The recommended algorithms to support probably needs to ap=
pear in the security document; JSEP should also mention or point to the rec=
ommended algorithms to use when generating the digest.




On Fri, Jul 11, 2014 at 8:05 AM, Alexand=
re GOUAILLARD <agouaillard@gmail.com> wrote:



Inaki,=C2=A0

I checked a little bit, fo=
llowing our previous exchange.

There was a thread back i=
n november last year in discuss-webrtc (how to specify desired hash function(s) (sha-1,=C2=A0sha-256,=C2=A0sha-512) for DTLS-SRTP?)






Justin said "Chrome supports various h=
ash functions in the remote description (SHA-1, 256, 512). Local description currently only supports=C2=A0<=
/span>SHA-256, no plans=
 to change that (although we will probably support longer hashes in the fut=
ure for hash agility).=C2=A0Asymmetric hash functions should not be an issue. If mu=
ltiple fingerprints are specified in the remote description, I think Chrome=
 will only use the first one."






then in ORTC there was this thread in ap=
ril:
"Issue 64: Section 2.5.1=C2=A0Fingerprint attribute"






in which bern=
ard proposed:
=
"
dictionary RTCDtlsParameters {



=C2=A0 =C2=A0 R=
TCDtlsRole =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ro=
le =3D "auto";
=
=C2=A0 =C2=A0 sequence<RTCDtlsFingerprint> fingerprint;



};
dictionary RTCDtl=
sFingerprint {



=C2=A0 =C2=A0 R=
TCDtlsCertificateHashAlgorithm algorithm;



=C2=A0 =C2=A0 A=
rrayBuffer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 value;
};


enum RTCDtlsCer=
tificateHashAlgorithm {



=C2=A0 =C2=A0 &=
quot;sha=
-=
1",



=C2=A0 =C2=A0 &=
quot;sha=
-224&quo=
t;,



=C2=A0 =C2=A0 &=
quot;sha=
-256&quo=
t;,



=C2=A0 =C2=A0 &=
quot;sha=
-384&quo=
t;,



=C2=A0 =C2=A0 &=
quot;sha=
-512&quo=
t;



};
"


















On Fri, Jul 11, 2014 at 8:26 PM, I=C3=B1aki Baz Castillo =
<ibc@aliax.net>=
; wrote:



Hi,



Hi, RFC 5763 and RFC 5764 (DTLS-SRTP) do not mandate a specific hash

for the fingerprint attribute in the SDP. RFC 5763 refers to RFC 4572

"Connection-Oriented Media Transport over TLS in SDP=E2=80=9D. Its sec=
tion 5

clearly opens the door to multiple hash functions:



=C2=A0 =C2=A0hash-func =C2=A0 =C2=A0=3D =C2=A0"sha-1" / "sha=
-224" / "sha-256" /

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0"sha-384" / "sha-512" /

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0"md5" / "md2" / token

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0; Additional hash functions can only come

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0; from updates to RFC 3279





I'm pretty sure that WebRTC implementations are not ready for all

those hash functions. Is there any WebRTC related draft constraining

the hash functions that can be used?



Thanks a lot.





PS: Not sure if this question should be placed here or in public-webrtc ML.=




--

I=C3=B1aki Baz Castillo

<ibc@aliax.net>=
;



_______________________________________________

rtcweb mailing list

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





-- 
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------=
------------------------------------------------




CTO - Temasys Communications, S'pore / Mountain View
Presiden=
t - CoSMo Software, Cambridge, MA
-------------------------------=
-----------------------------------------------------




    



  • 







_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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





--047d7bd6a91cd9b3f104fded02ec--


From nobody Fri Jul 11 09:03:55 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E971B2B14 for ; Fri, 11 Jul 2014 09:03:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.829
X-Spam-Level: 
X-Spam-Status: No, score=-0.829 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_18=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=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 toaAUMcsDRZB for ; Fri, 11 Jul 2014 09:03:48 -0700 (PDT)
Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0141D1A0659 for ; Fri, 11 Jul 2014 09:03:47 -0700 (PDT)
Received: by mail-vc0-f170.google.com with SMTP id hu12so1347286vcb.29 for ; Fri, 11 Jul 2014 09:03:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BjQGbMZtytmmktpwxYxZixrTE6jJ9C8f4pSZb1M/ouc=; b=inUFnyCh4HBn0wj/g6+foQF48ofuiTgS+gYE/CgF3fa877Or06iJRH0qfO6DM+5Rpn jEqRypf3Lg3FLTf4FqfAoOnErBjbD5dNSQYkMfOUBetHO8USo0qiqfBT9AN//VM+norK pTTtiYp67G20Qg+9ah3KhnLR+57oj4te93ywhG3FvRSqX7Bbklszcv/WfHV/eNP5Xs0F s/aIh5UdvjXAP0MXM7x/QPtgmA3kcsNs8UJtI+wHTPAa25+sbl7wHSjUkt+KhRZHOs+r /vGRTH/Bf6Y5LJnkWx+v5HPRQT+/eiRUqeJVpIJHDi1oJlqoqQdYRpjc0q+gbFhsTViE djaA==
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:content-type; bh=BjQGbMZtytmmktpwxYxZixrTE6jJ9C8f4pSZb1M/ouc=; b=TTJgnuZG7EgQYr2Nwoa+MYxW+a5NozMuVLgrtpx1qKxstt8Oh9ipuZoqaTPycRa/xk rp/HXIJfNcWG8cr5J38hFT+YlHsg/F7lhUCCGQ4II/ylvie7smIOS4iuApV5EI01XRsz Qg11i9deC9E1hb5hZdyJE2rM9C7Brg1P+QbSozPDiD6ewfIuRCoTmRX8KuW3XWcL3y+8 hvs8E0dEbL7VGNHGPgi4tf7Hq2axGxJ88p1zlrqiQsVi/PNmBD4oSd1ND+ajuh6CXNqK Y6tAv3DP04RjDDLGRTu7v1DIuvCirCg2XAKbmFXVIvFteummvIEue/qn8ASRPOfRz98v v4vw==
X-Gm-Message-State: ALoCoQmHMO8mwM5m/ib7r8NC12DGKMpeNqCQqPD5zgtW2pkvh+CRK7c7qtOcCFhuLJXZWEx+3hkF
X-Received: by 10.52.121.112 with SMTP id lj16mr44320219vdb.29.1405094627124;  Fri, 11 Jul 2014 09:03:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.27.8 with HTTP; Fri, 11 Jul 2014 09:03:27 -0700 (PDT)
In-Reply-To: 
References:  
From: Justin Uberti 
Date: Fri, 11 Jul 2014 09:03:27 -0700
Message-ID: 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=089e01184dc2204beb04fded16ec
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Kspzr505CtFYuO-nQJsSGslnMiw
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Security Architecture: IdP for RTP and RTCP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 16:03:50 -0000

--089e01184dc2204beb04fded16ec
Content-Type: text/plain; charset=UTF-8

On Tue, Jul 8, 2014 at 11:09 AM, Martin Thomson 
wrote:

> On 8 July 2014 10:54, Bernard Aboba  wrote:
> > In the situation where RTP and RTCP are not multiplexed, distinct DTLS
> > transports and DTLS/SRTP key exchanges would occur for RTP and RTCP.
> >
> > In looking for guidance within the security architecture document, some
> > questions came to mind:
> >
> > a. Are the certificates used for RTP and RTCP DTLS Transports necessarily
> > the same on both the local and remote side? If they are supposed to be
> the
> > same, what happens if they aren't?
>
> The certificates can be different.  As you might recall, one of the
> issues that we discussed was the possibility of having different
> a=fingerprint attributes on different m-lines, as well as having
> alternative a=fingerprint lines on the same m-lines.
>
> The current draft handles this by covering multiple fingerprints by
> the identity assertion.
>

Different m= lines can have different fingerprints, but do we expect to
support multiple fingerprints with the same digest algorithm on the same m=
line, where the receiver then checks that the received certificate matches
one of the possible fingerprints?


> > b. Can different identities be asserted for the RTP and RTCP DTLS
> > Transports? Does this make sense in some circumstances? If so, when?
>
> a=identity is a session-level attribute and they should (MUST?) only
> be one.  So no.  And I can think of any case where this makes sense in
> much the same way that having unmultiplexed RTP/RTCP doesn't make
> sense any more (if it ever did).
>
> > The WebRTC 1.0 API Section 8.3 seems to indicate that this should always
> be
> > the case:
> >
> > "It is possible that different values for the "a=identity" attribute is
> > provided at a media level in SDP. A browser may either choose to treat
> this
> > as an error or ignore the attribute. If multiple different assertions are
> > validated, then they must produce identical identity values."
>
> This is out of date.  I've sent the editors a pull request to have that
> fixed.
>
> > However, I am wondering whether there can be legitimate cases where a
> > browser communicating with a gateway or SFU might encounter distinct
> > identities or certificates for RTP and RTCP.  For example, could an SFU
> > potentially terminate RTCP but not RTP, in which case the certificates
> and
> > asserted identities might be different between RTP and RTCP?
>
> I think that the way that we manage identity in a multi-party
> situation probably needs something different to that.  I don't see any
> particular value in terminating RTCP when you aren't also terminating
> RTP, the two are far too tightly coupled.  They shouldn't really have
> been given different names in the first place.
>
> > The WebRTC 1.0 spec seems to indicate that this should be treated as a
> fatal
> > error, but I'm wondering whether the browser shouldn't be "strict in
> what it
> > sends but liberal in handling what it receives" by just using the
> identity
> > and certificates for RTP, and ignoring the RTCP identities.  Trying to
> > inform the user about different asserted identities for RTP and RTCP
> seems
> > way too complicated to even be worth considering.
>
> BTW, I wish that "liberal in what you permit" meme would go away.  I
> haven't found it to be particularly useful, except as a fatalistic
> acknowledgement of the messy end state that is the Internet.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

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





On Tue, Jul 8, 2014 at 11:09 AM, Martin Thomson &=
lt;martin.tho=
mson@gmail.com> wrote:



On 8 July 2014 10:54, Bernar=
d Aboba <bernard.aboba@gmail.=
com> wrote:



> In the situation where RTP and RTCP are not multiplexed, distinct DTLS=


> transports and DTLS/SRTP key exchanges would occur for RTP and RTCP.
>

> In looking for guidance within the security architecture document, som=
e

> questions came to mind:

>

> a. Are the certificates used for RTP and RTCP DTLS Transports necessar=
ily

> the same on both the local and remote side? If they are supposed to be=
 the

> same, what happens if they aren't?




The certificates can be different. =C2=A0As you might recall, one of =
the

issues that we discussed was the possibility of having different

a=3Dfingerprint attributes on different m-lines, as well as having

alternative a=3Dfingerprint lines on the same m-lines.



The current draft handles this by covering multiple fingerprints by

the identity assertion.

Different m=3D =
lines can have different fingerprints, but do we expect to support multiple=
 fingerprints with the same digest algorithm on the same m=3D line, where t=
he receiver then checks that the received certificate matches one of the po=
ssible fingerprints?








> b. Can different identities be asserted for the RTP and RTCP DTLS

> Transports? Does this make sense in some circumstances? If so, when?



a=3Didentity is a session-level attribute and they should (MUST?) onl=
y

be one. =C2=A0So no. =C2=A0And I can think of any case where this makes sen=
se in

much the same way that having unmultiplexed RTP/RTCP doesn't make

sense any more (if it ever did).




> The WebRTC 1.0 API Section 8.3 seems to indicate that this should alwa=
ys be

> the case:

>

> "It is possible that different values for the "a=3Didentity&=
quot; attribute is

> provided at a media level in SDP. A browser may either choose to treat=
 this

> as an error or ignore the attribute. If multiple different assertions =
are

> validated, then they must produce identical identity values."




This is out of date. =C2=A0I've sent the editors a pull request t=
o have that fixed.




> However, I am wondering whether there can be legitimate cases where a<=
br>
> browser communicating with a gateway or SFU might encounter distinct
> identities or certificates for RTP and RTCP. =C2=A0For example, could =
an SFU

> potentially terminate RTCP but not RTP, in which case the certificates=
 and

> asserted identities might be different between RTP and RTCP?




I think that the way that we manage identity in a multi-party

situation probably needs something different to that. =C2=A0I don't see=
 any

particular value in terminating RTCP when you aren't also terminating
RTP, the two are far too tightly coupled. =C2=A0They shouldn't really h=
ave

been given different names in the first place.




> The WebRTC 1.0 spec seems to indicate that this should be treated as a=
 fatal

> error, but I'm wondering whether the browser shouldn't be &quo=
t;strict in what it

> sends but liberal in handling what it receives" by just using the=
 identity

> and certificates for RTP, and ignoring the RTCP identities. =C2=A0Tryi=
ng to

> inform the user about different asserted identities for RTP and RTCP s=
eems

> way too complicated to even be worth considering.




BTW, I wish that "liberal in what you permit" meme would go=
 away. =C2=A0I

haven't found it to be particularly useful, except as a fatalistic

acknowledgement of the messy end state that is the Internet.



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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





--089e01184dc2204beb04fded16ec--


From nobody Fri Jul 11 09:08:16 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D461B2BA1 for ; Fri, 11 Jul 2014 09:08:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level: 
X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXuH-IG7l9ey for ; Fri, 11 Jul 2014 09:08:03 -0700 (PDT)
Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 191B81B2B67 for ; Fri, 11 Jul 2014 09:08:02 -0700 (PDT)
Received: by mail-vc0-f175.google.com with SMTP id hy4so2459526vcb.6 for ; Fri, 11 Jul 2014 09:08:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sjz+syDkEUbm9laF4ZmzTKequtHCKISBbAQY5DoVKDk=; b=l+Ya4clzaOxSikP5rv/A6EZ9Mh82ZeHPGt3kRTToVzJfW/sKfNyE/HqHgE0HqoUtoK JqgRzPqvIOzwNZ07NqN5S64v2uZ5P9KpIcFL05K41p0NUsvLFYc4WBaXOjjLpTgr8t+Q J9H88FoQrZwPtJRg/MI7CjVtYaJzrylOh0ATnBMBgqmT2vXkLeh5Q0padYkOZwjbb3xf E5PWSIjPCPEhB9JHWPPq9Q8lu6AngsdC2oj7jpHmIe7wLChnjsXnEwPeFqG83hC92gY5 S2et6tkUwI08yPQwBX3COZeA5pUYMkoKfExCko942E4613yq+n+Dn1k2LL0fFnurMSbz ckPQ==
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:content-type; bh=sjz+syDkEUbm9laF4ZmzTKequtHCKISBbAQY5DoVKDk=; b=d/bdqNaNfjNXfKnGQM0kDKA9Hxx5fVhckxObQcNy/MI34UmS98Oe4v5n5bbypYgaIh HyYdhKFD08UjkIf7waDrueBZAr/VNGOgN3Voc4Kniyqex692pliJDGtUHpiGPIjlL6RM uqzgE4Uvsa1iOUqs83Qri5MNxOWC9NFO3t9uIVA0ss6Ml6VVKcHCyzLYEHNsXkgbXHAf ZFhhkB3X8Ty9zeIqNlnx6jRgSQgn9aSVXdwAGUCL0S+BBQ+ra5deyn/QELJohmx04i03 Fe8xanuHP+ryZHg15PuGdQ62nyLJnJCrDSqH+K2JDUhWbz7Rxg5ierVEtOyChT+aZSZq ewvA==
X-Gm-Message-State: ALoCoQl7xC+ODgH/XxoiuMf22eALCf4/pX9D5EFa0q+5g5fO3EOpVCZ2ToXAb/EDhKZN197buHtC
X-Received: by 10.220.175.70 with SMTP id w6mr1838755vcz.72.1405094881241; Fri, 11 Jul 2014 09:08:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.27.8 with HTTP; Fri, 11 Jul 2014 09:07:41 -0700 (PDT)
In-Reply-To: 
References:  <53BC1D53.4080904@jitsi.org>  
From: Justin Uberti 
Date: Fri, 11 Jul 2014 09:07:41 -0700
Message-ID: 
To: Emil Ivov 
Content-Type: multipart/alternative; boundary=047d7b3a93e045d29004fded2562
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/iUnl3vPPb2XBbcziYlUxjbBRhVE
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ICE-Mismatch and WebRTC
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 16:08:06 -0000

--047d7b3a93e045d29004fded2562
Content-Type: text/plain; charset=UTF-8

The fact that WebRTC implementations MUST ignore the address and port in
the c=/m= lines will be written into JSEP, S 5.6/5.7.


On Tue, Jul 8, 2014 at 1:04 PM, Emil Ivov  wrote:

> On Tue, Jul 8, 2014 at 9:04 PM, Roman Shpount  wrote:
> > On Tue, Jul 8, 2014 at 12:33 PM, Emil Ivov  wrote:
> >>
> >> On 07.07.14, 21:48, Roman Shpount wrote:
> >>>
> >>> Is it possible to run into ICE-Mismatch with WebRTC? Should we specify
> >>> that default candidate (c= and m= line based candidate) should be
> >>> ignored and thus mismatch check should not be performed?
> >>
> >>
> >> I guess running into an ICE mismatch with WebRTC is just as possible as
> >> with any other ICE implementation. I suppose the only difference would
> be
> >> that rather than falling back to 3264 semantics, WebRTC implementations
> will
> >> rather drop the session because without ICE, they wouldn't be able to do
> >> consent checks for it.
> >>
> >
> > My point was that WebRTC would never use 3264 semantics
>
> Indeed. This was also my point.
>
> > and use address from
> > c= and m= lines for any purpose, so why does it need to check that this
> > address is correct? Would it be more sensible just ignore whatever value
> > happen to be there?
>
> With the exception of trickle ICE's use of :: (or 0.0.0.0) an ICE
> mismatch indicates that there is an entity on the signalling path that
> is overwriting c= line addresses and m= line ports. The idea of
> dropping ICE here is that the infrastructure is likely performing
> Hosted NAT Traversal and latching so insisting on ICE is likely to
> lead to unexpected situations.
>
> > Or, better yet end point can generate an error instead
> > of generating a response with ice-mismatch.
>
> Agreed. Sending an answer with ice-mismatch means downgrading to basic
> 3264 and that doesn't make sense for WebRTC.
>
> Agreed.
>
> Emil
>
> --
> https://jitsi.org
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

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


The fact that WebRTC implementations MUST ignore the addre=
ss and port in the c=3D/m=3D lines will be written into JSEP, S 5.6/5.7.


On Tue, Ju=
l 8, 2014 at 1:04 PM, Emil Ivov <emcho@jitsi.org> wrote:



On Tue, Jul 8, 2014 at 9:04 =
PM, Roman Shpount <roman@telurix.co=
m> wrote:



> On Tue, Jul 8, 2014 at 12:33 PM, Emil Ivov <emcho@jitsi.org> wrote:

>>

>> On 07.07.14, 21:48, Roman Shpount wrote:

>>>

>>> Is it possible to run into ICE-Mismatch with WebRTC? Should we=
 specify

>>> that default candidate (c=3D and m=3D line based candidate) sh=
ould be

>>> ignored and thus mismatch check should not be performed?

>>

>>

>> I guess running into an ICE mismatch with WebRTC is just as possib=
le as

>> with any other ICE implementation. I suppose the only difference w=
ould be

>> that rather than falling back to 3264 semantics, WebRTC implementa=
tions will

>> rather drop the session because without ICE, they wouldn't be =
able to do

>> consent checks for it.

>>

>

> My point was that WebRTC would never use 3264 semantics




Indeed. This was also my point.




> and use address from

> c=3D and m=3D lines for any purpose, so why does it need to check that=
 this

> address is correct? Would it be more sensible just ignore whatever val=
ue

> happen to be there?




With the exception of trickle ICE's use of :: (or 0.0.0.0) an ICE=


mismatch indicates that there is an entity on the signalling path that

is overwriting c=3D line addresses and m=3D line ports. The idea of

dropping ICE here is that the infrastructure is likely performing

Hosted NAT Traversal and latching so insisting on ICE is likely to

lead to unexpected situations.




> Or, better yet end point can generate an error instead

> of generating a response with ice-mismatch.




Agreed. Sending an answer with ice-mismatch means downgrading to basi=
c

3264 and that doesn't make sense for WebRTC.



Agreed.




Emil



--

https://jitsi.org



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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





--047d7b3a93e045d29004fded2562--


From nobody Fri Jul 11 09:13:26 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118F51B2B5F for ; Fri, 11 Jul 2014 09:13:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level: 
X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmAb35RiCDJ7 for ; Fri, 11 Jul 2014 09:13:22 -0700 (PDT)
Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB4761B2B55 for ; Fri, 11 Jul 2014 09:13:21 -0700 (PDT)
Received: by mail-vc0-f171.google.com with SMTP id id10so2494669vcb.30 for ; Fri, 11 Jul 2014 09:13:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Uo4KM/DxO3so0RSCm9c6ufnK8fOMuRCpCcm5r5sf9bI=; b=lFh9w1ylBLnjbxNEkjCoGstF6S23DWQxcBbCJbAeB9qzC/N3PwyFmOW/I2uKEng2DG lSWnJtIKOtqq/O9uqf2kqmb2pa+Lbe7KA5xvPckng6n89TvB2BvORS2cOhgks6LfPcQ8 zUYbaF3WKYOKKFER5sdIizE7yQQkwsDVUBqL5ELStiyV04Zn9hDoCXCkVT7IgrefLrXb fBWkdN13lhsIoPQXd8f/pwfg3H0GnTWW3rgboxDFmjUDgZu2AvCL5Hr/TolSgNOciks6 /4NNpfw+acJtaudYz9S6IZ5pO76q5uC9aivrEOoz7vI6nizZXnb3GUU4DOS2+CG0ayNy uIGA==
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:content-type; bh=Uo4KM/DxO3so0RSCm9c6ufnK8fOMuRCpCcm5r5sf9bI=; b=O2Ha07EjdWbIr35Ya0QfYJO1BYmtlpPuchznC1m0eiQVleCS4m4qfiRkJnQqiTOST7 Bg7VExYtia3n3vQEJC3GjpcI59V//Eq8mma45GjFBPBDkNJJf59SmzpSfM0LEZ6Ajtkl mR2EodzFcmQ4eEaW15QhKIzGd51VNJU1wD5jrBi0aUiXRX+7vt8hyHCjjXyIbyRm9TwL gw76ob0AuWhhDretUunCRE7J+3gUkl9ld5Y+LY9A/wQ0VhbWllH7Lg+gpvBgZME81AA6 kVg7c2sTeYIzd+b7R42qki7ZCsgfse8Orn80fHCg+dTEYFKzDJ2ujmnTcB5+86bEpdZx 92tA==
X-Gm-Message-State: ALoCoQn2l0ahRjmjJlz3oqAJq8iZWWbnMqEWrKPWmY+jE+9GOfQKSfb8g8mEnODbGU26VswOzGxh
X-Received: by 10.52.27.133 with SMTP id t5mr45299901vdg.9.1405095200918; Fri, 11 Jul 2014 09:13:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.27.8 with HTTP; Fri, 11 Jul 2014 09:13:00 -0700 (PDT)
In-Reply-To: 
References:     
From: Justin Uberti 
Date: Fri, 11 Jul 2014 09:13:00 -0700
Message-ID: 
To: Eric Rescorla 
Content-Type: multipart/alternative; boundary=20cf307d06e853ae5004fded38d0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6-cBH0sfGd8y6L1sXHhX6BOzZDs
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Question about ICE-Lite server
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 16:13:24 -0000

--20cf307d06e853ae5004fded38d0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 6, 2014 at 5:08 AM, Eric Rescorla  wrote:

>
>
>
> On Sun, Jul 6, 2014 at 1:16 AM, I=C3=B1aki Baz Castillo  w=
rote:
>
>> 2014-07-06 6:53 GMT+02:00 Eric Rescorla :
>> > On Sat, Jul 5, 2014 at 9:18 PM, Roman Shpount 
>> wrote:
>> >>
>> >> According to RFC 5245: "If its peer has a lite implementation, an age=
nt
>> >> MUST use a regular nomination algorithm." So, this whole problem cann=
ot
>> >> occur.
>>
>> Good point, thanks. Anyhow I don't think I should trust clients :)
>>
>>
>> > Nice catch. That actually changes things, since Firefox always uses
>> > aggressive nomination and for performance reasons, I'm not excited
>> > about moving to regular nomination. This seems like an argument
>> > for perhaps forbidding ICE-Lite.
>>
>> I don't understand, shouldn't that be fixed in Firefox?
>
>
> That's one way to fix it. The other is to require that WebRTC peers do
> full ICE. I'd be interested in hearing what Chrome does.
>

Chrome supports ICE lite, with regular nomination. There were a lot of
requests for it.

>
>
> This is not
>> about performance but about real issues in scenarios with IPv4 and
>> IPv6 in which Firefox talks to an ICE Lite peer.
>>
>> Should I address an issue? or is it already known?
>
>
> Feel free to file an issue.
>
> -Ekr
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

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





On Sun, Jul 6, 2014 at 5:08 AM, Eric Rescorla <=
;ekr@rtfm.com> wrote:






On Sun, Jul 6, 2014 =
at 1:16 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:





2014-07-06 6:53 GMT+02:00 Eric Rescorla <=
ekr@rtfm.com>:


> On Sat, Jul 5, 2014 at 9:18 PM, Roman Shpount <roman@telurix.com> wrote:
>>

>> According to RFC 5245: "If its peer has a lite implementation=
, an agent

>> MUST use a regular nomination algorithm." So, this whole prob=
lem cannot

>> occur.




Good point, thanks. Anyhow I don't think I should trust clients :=
)






> Nice catch. That actually changes things, since Firefox always uses
> aggressive nomination and for performance reasons, I'm not excited=


> about moving to regular nomination. This seems like an argument

> for perhaps forbidding ICE-Lite.




I don't understand, shouldn't that be fixed in Firefox?

That's one way to fix it. The other is=
 to require that WebRTC peers do =C2=A0
full ICE. I'd be inte=
rested in hearing what Chrome does.




Chrome supports ICE lite=
, with regular nomination. There were a lot of requests for it.=C2=A0
=









 This is not
about performance but about real issues in scenarios with IPv4 and

IPv6 in which Firefox talks to an ICE Lite peer.



Should I address an issue? or is it already known?

Feel free to file an issue.

-Ekr



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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





--20cf307d06e853ae5004fded38d0--


From nobody Fri Jul 11 09:13:50 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EEC1B2B55 for ; Fri, 11 Jul 2014 09:13:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level: 
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 zEf1DqG_n_pn for ; Fri, 11 Jul 2014 09:13:38 -0700 (PDT)
Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A623A1B2BBC for ; Fri, 11 Jul 2014 09:13:36 -0700 (PDT)
Received: by mail-qc0-f174.google.com with SMTP id x13so1137540qcv.19 for ; Fri, 11 Jul 2014 09:13:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yw4vI1f9+gC/eJlNdOJmr0P1Or09XzOLNdHeywMBOVY=; b=eLPjddjBtwg6kyqH1VDfEJmCFzHWO1QtSV4JQm9PZS1T3M747ilbg5FFzn20xXkwqk 4kLh8w9rf+rAVhFdSPv2pUcpDh9uu8kUJ7Zg0YOF1/AuKl0aXb79D9QvNFiunyynTCRS xV2TSAMuE0ITp9goMoQgPD9ns6cD4CuGwgxEHyID6ZqK21ANZ/ryaFGhKrmjSKGft2UM 1peHjVNr7qQuu4E1VPa6MiDN55GEACI/ugc11n3NYXgS1LuLcF+auOo4/PEuVF0S2br2 UB5Ts0xdHv/J+A8Z/2TP/zgDr8oM4dtPq+/OtvuKzJ93iVkPXZG/2e6Kqwmlu7WYcmBu IdEA==
X-Gm-Message-State: ALoCoQnHr6aml1MqfLtLwJ+1CmP+3bh4LbsFwM/liFNOK5hGDZJhWNogdJDVUMy5VqpP627H56fw
MIME-Version: 1.0
X-Received: by 10.224.87.130 with SMTP id w2mr93876588qal.5.1405095214471; Fri, 11 Jul 2014 09:13:34 -0700 (PDT)
Received: by 10.96.234.161 with HTTP; Fri, 11 Jul 2014 09:13:34 -0700 (PDT)
Received: by 10.96.234.161 with HTTP; Fri, 11 Jul 2014 09:13:34 -0700 (PDT)
In-Reply-To: 
References:  <53BC1D53.4080904@jitsi.org>   
Date: Fri, 11 Jul 2014 18:13:34 +0200
Message-ID: 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
To: Justin Uberti 
Content-Type: multipart/alternative; boundary=001a1133d5f62273c204fded39ae
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qNmw5kzejzxZIm-cetDDFU7Pdu8
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] ICE-Mismatch and WebRTC
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 16:13:40 -0000

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

I suggest renaming JSEP draft to "SDP made simple".

--
I=C3=B1aki Baz Castillo

On Jul 11, 2014 6:08 PM, "Justin Uberti"  wrote:

> The fact that WebRTC implementations MUST ignore the address and port in
> the c=3D/m=3D lines will be written into JSEP, S 5.6/5.7.
>
>
> On Tue, Jul 8, 2014 at 1:04 PM, Emil Ivov  wrote:
>
>> On Tue, Jul 8, 2014 at 9:04 PM, Roman Shpount  wrote:
>> > On Tue, Jul 8, 2014 at 12:33 PM, Emil Ivov  wrote:
>> >>
>> >> On 07.07.14, 21:48, Roman Shpount wrote:
>> >>>
>> >>> Is it possible to run into ICE-Mismatch with WebRTC? Should we speci=
fy
>> >>> that default candidate (c=3D and m=3D line based candidate) should b=
e
>> >>> ignored and thus mismatch check should not be performed?
>> >>
>> >>
>> >> I guess running into an ICE mismatch with WebRTC is just as possible =
as
>> >> with any other ICE implementation. I suppose the only difference woul=
d
>> be
>> >> that rather than falling back to 3264 semantics, WebRTC
>> implementations will
>> >> rather drop the session because without ICE, they wouldn't be able to
>> do
>> >> consent checks for it.
>> >>
>> >
>> > My point was that WebRTC would never use 3264 semantics
>>
>> Indeed. This was also my point.
>>
>> > and use address from
>> > c=3D and m=3D lines for any purpose, so why does it need to check that=
 this
>> > address is correct? Would it be more sensible just ignore whatever val=
ue
>> > happen to be there?
>>
>> With the exception of trickle ICE's use of :: (or 0.0.0.0) an ICE
>> mismatch indicates that there is an entity on the signalling path that
>> is overwriting c=3D line addresses and m=3D line ports. The idea of
>> dropping ICE here is that the infrastructure is likely performing
>> Hosted NAT Traversal and latching so insisting on ICE is likely to
>> lead to unexpected situations.
>>
>> > Or, better yet end point can generate an error instead
>> > of generating a response with ice-mismatch.
>>
>> Agreed. Sending an answer with ice-mismatch means downgrading to basic
>> 3264 and that doesn't make sense for WebRTC.
>>
>> Agreed.
>>
>> Emil
>>
>> --
>> https://jitsi.org
>>
>> _______________________________________________
>> 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
>
>

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


I suggest renaming JSEP draft to "SDP made simple"=
.


--

I=C3=B1aki Baz Castillo

<ibc@aliax.net>


On Jul 11, 2014 6:08 PM, "Justin Uberti&quo=
t; <juberti@google.com> wro=
te:


The fact that WebRTC implementations MUST ignore the addre=
ss and port in the c=3D/m=3D lines will be written into JSEP, S 5.6/5.7.


On Tue, Ju=
l 8, 2014 at 1:04 PM, Emil Ivov <emcho@jitsi.org> wrote:




On Tue, Jul 8, 2014 at 9:04 PM, Roman S=
hpount <roman@tel=
urix.com> wrote:




> On Tue, Jul 8, 2014 at 12:33 PM, Emil Ivov <emcho@jitsi.org> wrote:

>>

>> On 07.07.14, 21:48, Roman Shpount wrote:

>>>

>>> Is it possible to run into ICE-Mismatch with WebRTC? Should we=
 specify

>>> that default candidate (c=3D and m=3D line based candidate) sh=
ould be

>>> ignored and thus mismatch check should not be performed?

>>

>>

>> I guess running into an ICE mismatch with WebRTC is just as possib=
le as

>> with any other ICE implementation. I suppose the only difference w=
ould be

>> that rather than falling back to 3264 semantics, WebRTC implementa=
tions will

>> rather drop the session because without ICE, they wouldn't be =
able to do

>> consent checks for it.

>>

>

> My point was that WebRTC would never use 3264 semantics




Indeed. This was also my point.




> and use address from

> c=3D and m=3D lines for any purpose, so why does it need to check that=
 this

> address is correct? Would it be more sensible just ignore whatever val=
ue

> happen to be there?




With the exception of trickle ICE's use of :: (or 0.0.0.0) an ICE=


mismatch indicates that there is an entity on the signalling path that

is overwriting c=3D line addresses and m=3D line ports. The idea of

dropping ICE here is that the infrastructure is likely performing

Hosted NAT Traversal and latching so insisting on ICE is likely to

lead to unexpected situations.




> Or, better yet end point can generate an error instead

> of generating a response with ice-mismatch.




Agreed. Sending an answer with ice-mismatch means downgrading to basi=
c

3264 and that doesn't make sense for WebRTC.



Agreed.




Emil



--

https://jitsi.org



_______________________________________________

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




--001a1133d5f62273c204fded39ae--


From nobody Fri Jul 11 09:17:05 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CB41B2B63 for ; Fri, 11 Jul 2014 09:17:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level: 
X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKLkq2AqUT9c for ; Fri, 11 Jul 2014 09:17:01 -0700 (PDT)
Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD9181B2B60 for ; Fri, 11 Jul 2014 09:17:01 -0700 (PDT)
Received: by mail-vc0-f170.google.com with SMTP id hu12so1383682vcb.29 for ; Fri, 11 Jul 2014 09:17:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wYrKUeJ2I3rTLJ0IxsHfRaiTASuMPzZrSQLwpfM848E=; b=ElxH7u0yQoksCRFg8xKnEJUR+/DkBeIpxgIw8L2mCyEhsVeUCrnAmZ4RI1VBpr9mQU ojANC2YXfHvHYArKS0XXkBN7fuXsf0KhmWpKtvaF/oqxKqWFyi8OnM420pcRCa8dXK51 6AtdIBblc/+hLK98PiipKzbCK8pa2N64byHkOgoeEco0kD/eVNJKKhiYa14OV4p6o1jy mZ5qbH6sP9xYyzCBswi8Bbqo7ssBgkyklNPEgJftEaXz3HYu8ZvzBc1r9srp/yQ89Bk7 afUI1BLjau/0mmWNYgpS/gve1DUtzrfiVLvkLTMpWlXKOf3EVaX4QGV/z9uKB+aVOnmQ bGoQ==
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:content-type; bh=wYrKUeJ2I3rTLJ0IxsHfRaiTASuMPzZrSQLwpfM848E=; b=EOmjFs0hIvVRXyQ9QwnF58gVtbMbqhk1z4bt0RNu+Ubecj/1gnwV4FJi3XvNfLOaQx +LJcmoBC+Tvlh0TLZAqu9/ukAgMzVBIQI76gc7sJybXfy6AsAIW8MVjUImvMxAxTFJVj 541mJiLHVMJbt7NlqyILIEdkcIwhYET0lBHs01mT90CHEWBXpn6XlGwXsX+qK42euglA wIP7O+F7WI8i097a5BqKBJi846jX+WBwdOxccBdUonsBoAP5KDBXOyHU/7aEXo7NQe9l bfkbX6GzUROlDQDnXf2r/dLSFs+hkgib27KxKmj9w8mOgKTlh+Rz9v3ml6MMBKJTmMVf Y15Q==
X-Gm-Message-State: ALoCoQlFc3w3a46M3XcwR5htAfSLYK416pBJoZ43zWJXcJ32VDsd4knuvamdIw0b6ZXBPQvAsfXp
X-Received: by 10.220.59.65 with SMTP id k1mr10778366vch.22.1405095420959; Fri, 11 Jul 2014 09:17:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.27.8 with HTTP; Fri, 11 Jul 2014 09:16:39 -0700 (PDT)
In-Reply-To: 
References:  <53B91327.50401@alvestrand.no> 
From: Justin Uberti 
Date: Fri, 11 Jul 2014 09:16:39 -0700
Message-ID: 
To: Roman Shpount 
Content-Type: multipart/alternative; boundary=001a11c295027144fd04fded45df
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/YZxmlpNERyaqmL8Z2tiuQyKmU7s
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Question about ICE-Lite server
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 16:17:03 -0000

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

On Mon, Jul 7, 2014 at 12:46 PM, Roman Shpount  wrote:

> To me this sounds like "can an endpoint participate in ICE without
>> participating in the exchange of candidates" - and my immediate reaction is
>> "if it could, it would be a security risk".
>>
>> I don't think it's possible. And I think that's a Good Thing.
>>
>>
> Since ICE-Lite server does not send any connectivity checks, it can
> operate with virtually no information about the remote side. It certainly
> does not need any information about the candidates. All it cares about that
> the other side supports ICE, if there was an ICE mismatch and if remote
> side is full or lite implementation. All checks from remote side are
> validated using the local password. If remote side is lite or does not
> support ICE media can be sent immediately, otherwise it will need to wait
> for a connectivity check with the use attribute. Very, very simple.
>
>
This seems fine to me. For ICE server implementations, there really is no
need to receive candidates from the client. All client candidates can be
generated based on incoming connectivity checks (i.e. prflx candidatates).
And yes, you would use the contents of the PRIORITY attribute to determine
the candidate priority.

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





On Mon, Jul 7, 2014 at 12:46 PM, Roman Shpount &l=
t;roman@telurix.com<=
/a>> wrote:



=





To me this sounds like "can an endpoint participate in ICE withou=
t participating in the exchange of candidates" - and my immediate reac=
tion is "if it could, it would be a security risk".





I don't think it's possible. And I think that's a Good Thing.












--001a11c295027144fd04fded45df--


From nobody Fri Jul 11 09:17:13 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734F81B2BB9 for ; Fri, 11 Jul 2014 09:17:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level: 
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 2ccY0Y65JsYR for ; Fri, 11 Jul 2014 09:17:07 -0700 (PDT)
Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937571B2BB8 for ; Fri, 11 Jul 2014 09:17:07 -0700 (PDT)
Received: by mail-qc0-f171.google.com with SMTP id w7so1180534qcr.2 for ; Fri, 11 Jul 2014 09:17:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wIRItnzqpyDwBm3bs1EKQuQxuRCEzwyRTJjO8Q4s650=; b=gUPW/rnIK5ZRszQ/f57f4FBJpfJTLd+Z2S9U8P1IdCWVWOHR0YfPiTIuhUTyQFcUSE xKUxcbzGsAaTtH2RtBd/J2hA/M56HxcHUASJ5y+bdwANUFBDCPEFpOnj+lt/IWg2D4d0 zUJpJLQCxXhTzD27XgihezQS9e6HiDewEH4lKq/7KMjXuK3u5ptMIxFRbRq0iMMo451+ yO5dJlGqps07t2ipo7PHzMTzidmFqI1avOxWM55QkXCU/ZWFVjMQ9dXzc469oqbZgK9X gjSJ1lJrZDyOU++6kb+2fY27Mt+6zIPI12gtVt4dJHdRl45UY8b2JWVWGAyMfbZimBSL qeFw==
X-Gm-Message-State: ALoCoQn5fSNwDkj5ua0y54kTkNOyITaCGFjR7pNBe1GTQQ1+LDA6/+tDxPe+UtNJGZwczbxbHVlp
MIME-Version: 1.0
X-Received: by 10.224.129.68 with SMTP id n4mr94032840qas.66.1405095426773; Fri, 11 Jul 2014 09:17:06 -0700 (PDT)
Received: by 10.96.234.161 with HTTP; Fri, 11 Jul 2014 09:17:06 -0700 (PDT)
Received: by 10.96.234.161 with HTTP; Fri, 11 Jul 2014 09:17:06 -0700 (PDT)
In-Reply-To: 
References:      
Date: Fri, 11 Jul 2014 18:17:06 +0200
Message-ID: 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
To: Justin Uberti 
Content-Type: multipart/alternative; boundary=001a11c2bac4c9e7e004fded4598
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/KiLBs9tUFni7NnIOrglk-6ftEeo
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Question about ICE-Lite server
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 16:17:09 -0000

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

On Jul 11, 2014 6:13 PM, "Justin Uberti"  wrote:
>
>

> Chrome supports ICE lite, with regular nomination. There were a lot of
requests for it.

That is great. BTW does Chrome use aggressive nomination when the peer is
full ICE? I did not check that.

Thanks.

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




On Jul 11, 2014 6:13 PM, "Justin Uberti" <juberti@google.com> wrote:

>

>


> Chrome supports ICE lite, with regular nomination. Ther=
e were a lot of requests for it.=C2=A0


That is great. BTW does Chrome use aggressive nomination whe=
n the peer is full ICE? I did not check that.


Thanks.


--001a11c2bac4c9e7e004fded4598--


From nobody Fri Jul 11 09:31:52 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCA41B2BBC for ; Fri, 11 Jul 2014 09:31:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 Lx-wA2RoDJhr for ; Fri, 11 Jul 2014 09:31:48 -0700 (PDT)
Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73F141B2BA9 for ; Fri, 11 Jul 2014 09:31:42 -0700 (PDT)
Received: by mail-qc0-f178.google.com with SMTP id i17so1197167qcy.9 for ; Fri, 11 Jul 2014 09:31:41 -0700 (PDT)
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:content-type:content-transfer-encoding; bh=rp9qzQIh4MSEM23Q6fyY9DlzXTRpJ6kstPhn3z/wFjc=; b=UDB7GdgphIQUvqFfP8gQzshji623DWbUz5b7bnVYUIj2DYki4EgUYcTnVLgya+s40+ 5E4awGVJP/iKMTdv4fClDxPIdUPUnZlHRDryL9cC0hebJ0k97wN5Os2cywY+2nAubbIp SYCL2jEl3pULxrb7sw0+FqSxBoGFtuHoLD0Oxk2bCazPIIZJ1dz7XcAqs3OhXX3/g8sF caIZeu5cO6CpOCnXlHmssDA29Vji9HPEU1h8hZcwY+vty3Abcr2hk3CLB5nEIkxjbjEg +gJs8/rxDveWRcXAFknyTqg3gGoipO2gCCdIfKaOJYF4UPkWmjqa6t+yGYzfx+seQUvl GH2w==
X-Gm-Message-State: ALoCoQllvKtCiIow7ivj2jkc1waD+DzQVxtHhreuRokWTw3+bJ/RhCJPOrYjjiTwcsPs5psxk5As
X-Received: by 10.140.47.173 with SMTP id m42mr91217621qga.9.1405096301692; Fri, 11 Jul 2014 09:31:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Fri, 11 Jul 2014 09:31:21 -0700 (PDT)
In-Reply-To: 
References:   
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Fri, 11 Jul 2014 18:31:21 +0200
Message-ID: 
To: Justin Uberti 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uj3E6xYzgNoKQHyIAa-CDAotnrA
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Which hashes are valid for the fingerprint attribute?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 16:31:50 -0000

2014-07-11 17:58 GMT+02:00 Justin Uberti :
> The recommended algorithms to support probably needs to appear in the
> security document; JSEP should also mention or point to the recommended
> algorithms to use when generating the digest.

Agreed. There are too many possible hash algorithms and it's
unfeasible to expect that different implementations may support all of
them.


--=20
I=C3=B1aki Baz Castillo



From nobody Fri Jul 11 09:34:24 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC091B2BA9 for ; Fri, 11 Jul 2014 09:34:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.729
X-Spam-Level: 
X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=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 ezEEj8whlAG1 for ; Fri, 11 Jul 2014 09:34:16 -0700 (PDT)
Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD30C1B2B74 for ; Fri, 11 Jul 2014 09:34:15 -0700 (PDT)
Received: by mail-vc0-f175.google.com with SMTP id hy4so2527711vcb.6 for ; Fri, 11 Jul 2014 09:34:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1OFgA5w57K218Movowteg6NZrddjnNfqlevRvmLuseM=; b=TuPGdMHsf4DqceBFYg64x7AAFUBZtyWEoPjHHGKDeYHWuXxSXx+ehVCgnXb0ZD+r6C iki95/RNGgKVtlJrqGK/yfA3v8q26R1A5FaXZPF63xJJwQgObsbgGPxFE3jvYA3aZ/Xe BxmADUZCwpdg176Cr02A+a/ehq9DAP6CJglCPVsztduzA+XxVc4cIPsx/TsU8uB2kBJO FT2jiZDkKGSy5qr3wKJAWl2Pir91eJa5tkhLOqJ2dR0TBu9b0UYUwRViMEa99uEFdE6o o1qxFTboR9NNoI45w+WVV87gNoAC2Qvy/jHhbo3+x2qCwUZDPdYGlGMl7sXmNdI1Ls8S 6QsA==
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:content-type; bh=1OFgA5w57K218Movowteg6NZrddjnNfqlevRvmLuseM=; b=jKeR6U+aXBVurCrVKD4pkv7OopGUsaznwia8o3qziRBHsex6TUxo8Yd0zBNEnzq7SQ 3LrMS3AwyZHngob4d3OuS1aN0Zno0L9x8T7I0h8UVjbPADeso7r5aQkFHRUmm7JubF7r lmit2W1G9fptGKBzPjnpfCI1i16Biv399mLH9QQ48gdIA3nv90L/jjCGO0nOVktksjaX vU4ufXaluxspYRNziGik4vVQZKWp1BXA0P0HZUstTMq7o8TU4jGyDzcPuIVQhh3dsGEJ GBHD0oivkPOdTUsXXMJN0kOJ+Kje0vxCLjAKp8/hCby+Ef96Q9TxISdFWjwRdoIQHH1q MwsQ==
X-Gm-Message-State: ALoCoQmWBkqbtN4RwHcEcZEqqBLy8BiP3WMXTtDIz2DUlPjZjKkvLN40TaJ6PdJ2gd5DuUKRQOl7
X-Received: by 10.220.185.132 with SMTP id co4mr1928173vcb.74.1405096455129; Fri, 11 Jul 2014 09:34:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.27.8 with HTTP; Fri, 11 Jul 2014 09:33:54 -0700 (PDT)
In-Reply-To: 
References:       
From: Justin Uberti 
Date: Fri, 11 Jul 2014 09:33:54 -0700
Message-ID: 
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Content-Type: multipart/alternative; boundary=047d7b671d1c156c7c04fded83c4
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/CJ8ff5kLh4SgaMBO9hJjG2Ivaro
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Question about ICE-Lite server
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 16:34:17 -0000

--047d7b671d1c156c7c04fded83c4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yes, Chrome always uses aggressive nomination unless ICE Lite is used.


On Fri, Jul 11, 2014 at 9:17 AM, I=C3=B1aki Baz Castillo  wr=
ote:

>
> On Jul 11, 2014 6:13 PM, "Justin Uberti"  wrote:
> >
> >
>
> > Chrome supports ICE lite, with regular nomination. There were a lot of
> requests for it.
>
> That is great. BTW does Chrome use aggressive nomination when the peer is
> full ICE? I did not check that.
>
> Thanks.
>

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


Yes, Chrome always uses aggressive nomination unless ICE L=
ite is used.


On Fri, Jul 11, 2014 at 9:17 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:





On Jul 11, 2014 6:13 PM, "Justin Uberti" <juberti@google.com> wrote:

>

>


> Chrome supports ICE lite, with regular nomination. Ther=
e were a lot of requests for it.=C2=A0


That is great. BTW does Chrome use aggressive nominati=
on when the peer is full ICE? I did not check that.


Thanks.





--047d7b671d1c156c7c04fded83c4--


From nobody Fri Jul 11 09:47:45 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F94B1B2B63 for ; Fri, 11 Jul 2014 09:47:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 L3puDCsFkfUy for ; Fri, 11 Jul 2014 09:47:41 -0700 (PDT)
Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB97D1B2B40 for ; Fri, 11 Jul 2014 09:47:41 -0700 (PDT)
Received: by mail-qc0-f176.google.com with SMTP id w7so1195323qcr.7 for ; Fri, 11 Jul 2014 09:47:41 -0700 (PDT)
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:content-type:content-transfer-encoding; bh=POLNDYULYYrT/n3EiunRkWn7rSWmnyYLxfrUK2vX234=; b=OoyTxsWLlIYVQhCoGj1je909uTbutlcPJQbjj+PzDyPEVgJF50nI+9rm5On692Hqkr yTB4TN1AEYJzLU1sajjL9242m0YNWQ+SL+zLk0YdfilO7MpdnyDJKrphrd9BoB1nFzrt ESFP1e/FKq75G1M0NlEo0hdIxxYtYgCLaVoRjrNshYRERNo4jh45wyqZuiJBi8yQQ6P2 A+j6/VMiGGEF2B+MH2zTCdgT4CLOEu3F+eNrjUqlOUeoG7Z3KQ/3EQM+Vh563oPBOmLr ZbvJghsvSR0THKfySsrrmDGKR2Ze5OFretdBbG6mdctSh/sEdi5tTD6YhiW93fx1eLb2 llgw==
X-Gm-Message-State: ALoCoQnnOhRPk9fmGZNOaGb5jZR1NbCHXSg9UZ5As5ZRE7uLdWvb6cbFL45BKCcI02kOmr7Y9rrd
X-Received: by 10.224.128.9 with SMTP id i9mr156709qas.50.1405097260960; Fri, 11 Jul 2014 09:47:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Fri, 11 Jul 2014 09:47:19 -0700 (PDT)
In-Reply-To: 
References:  <53B91327.50401@alvestrand.no>  
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Fri, 11 Jul 2014 18:47:19 +0200
Message-ID: 
To: Justin Uberti 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/P6HQBvF9d64w8M4EAaA_YW1zPDE
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Question about ICE-Lite server
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 16:47:42 -0000

2014-07-11 18:16 GMT+02:00 Justin Uberti :
> And yes, you would use the contents of the PRIORITY attribute to determin=
e
> the candidate priority.

Thanks for confirming that!


--=20
I=C3=B1aki Baz Castillo



From nobody Fri Jul 11 10:03:07 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70551A0AD4 for ; Fri, 11 Jul 2014 10:03:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNIwlzbpjS1R for ; Fri, 11 Jul 2014 10:03:04 -0700 (PDT)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33C61A0AD2 for ; Fri, 11 Jul 2014 10:03:03 -0700 (PDT)
Received: by mail-wi0-f174.google.com with SMTP id d1so16261wiv.7 for ; Fri, 11 Jul 2014 10:02:57 -0700 (PDT)
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:content-type; bh=eZbLFRhoPhpW8FP3PaGAShv3nk9b2Gpmu3B7F9N3VaQ=; b=Yu0u8WfTW7YtuLNI/wKeTzTXykStj8OmSHrh0597n5TLAe56MHRMoyNA6xnuMrbaYG 3+CEtCo0KtUOZzCxMdzqJWOUSCmCpee7ZrTHQ3gQeo1YRHhDrfH0Qa5uHVLDZjzDcdD3 pP3fwxBynxnkMvLKBDBYB45g23mwYMcT2dgUDnFpkeqcYWhomY+o2W+SSrCmwzOmk3ay sMkCy8isF3OCE2w/QLT7WPTy+Pfc75togxH2XPRaaaFHa0vQGHOkN2HaZBSa8rJuXk48 TRQ+0XBO5aWYJeo7G+80CWayysOqAVWo7ibVXomBGWseRjOml9pAVaz7Zbzvu97bfBwp dqMg==
X-Gm-Message-State: ALoCoQlNwI4Ph/wNaMzwJttUi0hnpORpwXEDSni+BadAI5dnxFZLianR3yz2ZHMyH4qhac+S2y74
X-Received: by 10.194.109.71 with SMTP id hq7mr154284wjb.114.1405098175915; Fri, 11 Jul 2014 10:02:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.217.128.12 with HTTP; Fri, 11 Jul 2014 10:02:15 -0700 (PDT)
X-Originating-IP: [207.106.178.163]
In-Reply-To: 
References:      
From: Eric Rescorla 
Date: Fri, 11 Jul 2014 10:02:15 -0700
Message-ID: 
To: Justin Uberti 
Content-Type: multipart/alternative; boundary=089e0102e6e6a67f0504fdede981
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/W6_dlIeo_8ybAheSn1vGggvxAKE
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Question about ICE-Lite server
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 17:03:05 -0000

--089e0102e6e6a67f0504fdede981
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 11, 2014 at 9:13 AM, Justin Uberti  wrote:

>
>
>
> On Sun, Jul 6, 2014 at 5:08 AM, Eric Rescorla  wrote:
>
>>
>>
>>
>> On Sun, Jul 6, 2014 at 1:16 AM, I=C3=B1aki Baz Castillo  =
wrote:
>>
>>> 2014-07-06 6:53 GMT+02:00 Eric Rescorla :
>>> > On Sat, Jul 5, 2014 at 9:18 PM, Roman Shpount 
>>> wrote:
>>> >>
>>> >> According to RFC 5245: "If its peer has a lite implementation, an
>>> agent
>>> >> MUST use a regular nomination algorithm." So, this whole problem
>>> cannot
>>> >> occur.
>>>
>>> Good point, thanks. Anyhow I don't think I should trust clients :)
>>>
>>>
>>> > Nice catch. That actually changes things, since Firefox always uses
>>> > aggressive nomination and for performance reasons, I'm not excited
>>> > about moving to regular nomination. This seems like an argument
>>> > for perhaps forbidding ICE-Lite.
>>>
>>> I don't understand, shouldn't that be fixed in Firefox?
>>
>>
>> That's one way to fix it. The other is to require that WebRTC peers do
>> full ICE. I'd be interested in hearing what Chrome does.
>>
>
> Chrome supports ICE lite, with regular nomination. There were a lot of
> requests for it.
>

OK. I withdraw my objection. We'll get on fixing the relevant piece of
Firefox.

-Ekr


>> This is not
>>> about performance but about real issues in scenarios with IPv4 and
>>> IPv6 in which Firefox talks to an ICE Lite peer.
>>>
>>> Should I address an issue? or is it already known?
>>
>>
>> Feel free to file an issue.
>>
>> -Ekr
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>

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





On Fri, Jul 11, 2014 at 9:13 AM, Justin Uberti &l=
t;juberti@google.co=
m> wrote:






On Sun, Jul 6, 2014 =
at 5:08 AM, Eric Rescorla <ekr@rtfm.com> wrote:








On Sun, Jul 6, 2014 at 1:16 AM,=
 I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:







2014-07-06 6:53 GMT+02:00 Eric Rescorla <=
ekr@rtfm.com>:


> On Sat, Jul 5, 2014 at 9:18 PM, Roman Shpount <roman@telurix.com> wrote:
>>

>> According to RFC 5245: "If its peer has a lite implementation=
, an agent

>> MUST use a regular nomination algorithm." So, this whole prob=
lem cannot

>> occur.




Good point, thanks. Anyhow I don't think I should trust clients :=
)






> Nice catch. That actually changes things, since Firefox always uses
> aggressive nomination and for performance reasons, I'm not excited=


> about moving to regular nomination. This seems like an argument

> for perhaps forbidding ICE-Lite.




I don't understand, shouldn't that be fixed in Firefox?

That's one way to fix it. The other is=
 to require that WebRTC peers do =C2=A0
full ICE. I'd be inte=
rested in hearing what Chrome does.






Chrome supports IC=
E lite, with regular nomination. There were a lot of requests for it.=C2=A0=


OK. I withdraw my =
objection. We'll get on fixing the relevant piece of Firefox.




-Ekr





 This is not=


about performance but about real issues in scenarios with IPv4 and

IPv6 in which Firefox talks to an ICE Lite peer.



Should I address an issue? or is it already known?

Feel free to file an issue.

-Ekr



_______________________________________________
rtcweb mailing list

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








--089e0102e6e6a67f0504fdede981--


From nobody Fri Jul 11 10:05:10 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1EA1A0AD2 for ; Fri, 11 Jul 2014 10:05:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 jPsWiX2f5fOc for ; Fri, 11 Jul 2014 10:05:07 -0700 (PDT)
Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B274C1A0AA8 for ; Fri, 11 Jul 2014 10:05:07 -0700 (PDT)
Received: by mail-qc0-f173.google.com with SMTP id c9so1244780qcz.4 for ; Fri, 11 Jul 2014 10:05:06 -0700 (PDT)
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:content-type:content-transfer-encoding; bh=3n8593Tx//E2AIteCS/9uSbHjwvVrLqGSVRdUYrq6FQ=; b=DFnDwmzEF/BbqXGjFELkBu82wpas7NMI4FRHiZq8Zb6UU4bX0HRQYHFS0xOo6YqdBC KI/DOkqcOhhCEm7LBV3K+Lpn83fvQEIcjG5LFxn3sW/KGd0+TNVRFT9NS2vkqDBYD6Kh 5A/Gb9iQuXfREX4pho+fUgp6ZJXOytAPvUzH8OhVeyzd6R7HQV15WgnRrB4z74aNalGO T0aAPg21yrtFebeYrSyxe2frLPEfAz/KxucCprLW/USk9N9lcDRf8YV9Orm734dH/iC3 uU7Voa8lQqD5qNwA5lzPbppsjywVDH4E4R5tOcOR2qAMzt4uES4ZM8kziu1yfi6E/Xd/ gMWg==
X-Gm-Message-State: ALoCoQmEGS+m98w0VEG0TSg8tYpcY/vyyy2ZZvhC5JDjt2GzW71z4Y1VuwFiurz6Hb6eQALQAG1b
X-Received: by 10.140.88.230 with SMTP id t93mr59502qgd.47.1405098306800; Fri, 11 Jul 2014 10:05:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.234.161 with HTTP; Fri, 11 Jul 2014 10:04:46 -0700 (PDT)
In-Reply-To: 
References:       
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Fri, 11 Jul 2014 19:04:46 +0200
Message-ID: 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2LFE69z_jepE9dKbmC6K2BlHb5U
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Question about ICE-Lite server
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 17:05:08 -0000

2014-07-11 19:02 GMT+02:00 Eric Rescorla :
>> Chrome supports ICE lite, with regular nomination. There were a lot of
>> requests for it.
>
>
> OK. I withdraw my objection. We'll get on fixing the relevant piece of
> Firefox.


So many thanks Eric.

--=20
I=C3=B1aki Baz Castillo



From nobody Fri Jul 11 10:26:58 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780461B2BF0 for ; Fri, 11 Jul 2014 10:26:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paGWRP33w-P8 for ; Fri, 11 Jul 2014 10:26:56 -0700 (PDT)
Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410AA1B2BED for ; Fri, 11 Jul 2014 10:26:54 -0700 (PDT)
Received: by mail-we0-f174.google.com with SMTP id u57so1443537wes.5 for ; Fri, 11 Jul 2014 10:26:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ybCAKedv2Hrbq4VGlT+oZgSuWxc/zye3uqTDoY28W2o=; b=XwMEhfcXbiB970XZ440ejUkRQMNmFBE6FxYuRvYxZbS2y0bClsvVHjShfBTna+/rt9 0qwa3bwfD9t5Q+EsOCxRA46J/LcWTupUJwHznYnTYH8FTouAZZnPELXlJNcw2g9NMpWJ XO29/w0+JqYEtCaXVovSVIuRE9KndfqTo/SPsRFMxnGMY5hFvsUHQq93GQA98/EdZf9N NFjuyRTD7sKgisM6VPaDvAJCrpAqtk+vIpDae+9Ykuj+W0N8vyLHc0s02JBREGLlDHKQ n0cQmVEJjzlLHQl0w2lGWLKY5NQjA0vhvgaRilJOB8RDKCUQDQ8Emb/4fxiV3iROgRvR +gvw==
X-Gm-Message-State: ALoCoQnLBcs0D9Eg+rB0AtRS1N3yBdRItc/ujb05ys3bNcimvf7rjG2N09XRbKUE8CZJPBijYFum
X-Received: by 10.180.99.97 with SMTP id ep1mr6696727wib.64.1405099609925; Fri, 11 Jul 2014 10:26:49 -0700 (PDT)
Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by mx.google.com with ESMTPSA id fw4sm9561702wib.19.2014.07.11.10.26.48 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 10:26:48 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id w62so1120812wes.1 for ; Fri, 11 Jul 2014 10:26:48 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.37.42 with SMTP id v10mr6412146wij.43.1405099608660; Fri, 11 Jul 2014 10:26:48 -0700 (PDT)
Received: by 10.217.131.17 with HTTP; Fri, 11 Jul 2014 10:26:48 -0700 (PDT)
In-Reply-To: 
References:        
Date: Fri, 11 Jul 2014 13:26:48 -0400
Message-ID: 
From: Roman Shpount 
To: Justin Uberti 
Content-Type: multipart/alternative; boundary=e89a8f6473c70c61b904fdee3f6f
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sQdWLjoVuog4sunGzSR_5_npPzE
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Question about ICE-Lite server
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 17:26:57 -0000

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

On Fri, Jul 11, 2014 at 12:33 PM, Justin Uberti  wrote:

> Yes, Chrome always uses aggressive nomination unless ICE Lite is used.
>
>
What about the cases when it sees unknown "ice-options" attribute? This
should make Chrome use regular nomination as well.
_____________
Roman Shpount

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


On F=
ri, Jul 11, 2014 at 12:33 PM, Justin Uberti <juberti@google.com>=
 wrote:


Yes, Chrome always uses aggressive nomina=
tion unless ICE Lite is used.




What about the cases when it sees =
unknown "ice-options" attribute? This should make Chrome use regu=
lar nomination as well.


_____________
Roman Shpount
=C2=A0


--e89a8f6473c70c61b904fdee3f6f--


From nobody Fri Jul 11 10:42:43 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0C51A0352 for ; Fri, 11 Jul 2014 10:42:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmD9yGoDVBaJ for ; Fri, 11 Jul 2014 10:42:40 -0700 (PDT)
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 452D31B27A1 for ; Fri, 11 Jul 2014 10:42:40 -0700 (PDT)
Received: by mail-wi0-f170.google.com with SMTP id cc10so1193560wib.5 for ; Fri, 11 Jul 2014 10:42:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wKAwNCPvVu3+oOwPLNp4t7+IpvkkZ6uB0UqEASgcTls=; b=f60vcBSwzv90mZyJS7QmNp3fLv1Lkmcf/CRWLb7RH8Uq5FcAXZbBXz3X5Rlc+W7WDI uks16vyX0XQ14/uYRgxL0/x6EJKUJ91WPIBiJsC9oYwZVq7jTqK5u29fUo4StVedHuJA 7kb5iZiG/rsyXi4DIfLjBpaQGThWKj/c7uYGsEfixTlL/GL2HwJ+xW0iAFSwecTDlKYN PHg6cuZ3K9P7FWNyI7XYyE7KZxugeB06y0yEOD5VXd7fVtIrtDhV1IAYxWpUQ8176Mo4 xSGZAei9e8UcNJT0e+HWrV+fZOCr2QARgZ/5ZwtvEASGgXBjBTTijqhqS5JK/xkHB/17 +kFA==
X-Gm-Message-State: ALoCoQlIfB25SN3zcmL5zPhLcN/uyZvmBZuXJCfVWFM2q31rowgPgoWJL7IQtoRXCQp0scd/N4aC
X-Received: by 10.194.62.110 with SMTP id x14mr364420wjr.15.1405100556517; Fri, 11 Jul 2014 10:42:36 -0700 (PDT)
Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by mx.google.com with ESMTPSA id x13sm9680109wib.23.2014.07.11.10.42.35 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 10:42:35 -0700 (PDT)
Received: by mail-wg0-f51.google.com with SMTP id y10so1418343wgg.34 for ; Fri, 11 Jul 2014 10:42:34 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.37.42 with SMTP id v10mr6511253wij.43.1405100554778; Fri, 11 Jul 2014 10:42:34 -0700 (PDT)
Received: by 10.217.131.17 with HTTP; Fri, 11 Jul 2014 10:42:34 -0700 (PDT)
In-Reply-To: 
References:  <53BC1D53.4080904@jitsi.org>   
Date: Fri, 11 Jul 2014 13:42:34 -0400
Message-ID: 
From: Roman Shpount 
To: Justin Uberti 
Content-Type: multipart/alternative; boundary=e89a8f6473c770fd7c04fdee7769
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HP1T8MaHDjr4Am66mjSX7TNnsGw
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ICE-Mismatch and WebRTC
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 17:42:42 -0000

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

On Fri, Jul 11, 2014 at 12:07 PM, Justin Uberti  wrote:

> The fact that WebRTC implementations MUST ignore the address and port in
> the c=/m= lines will be written into JSEP, S 5.6/5.7.
>
>
> Is it going to completely ignore these parameters or would it still honor
port 0 to indicate that m line disabled?

What about 0.0.0.0 address to indicate hold? These should not be allowed
per RFC 5245 section 9.1.1.1 but I still do see it used in SIP, especially
with various B2BUA scenarios where this is the only way for a pure
signaling agent to put a call on hold or to resolve collision. There are
other ways to deal with this in WebRTC but this will still come up during
interop with SIP.

Would it also document on what happens when WebRTC implementation receives
an answer SDP with ice-mismatch attribute? An error in such case is
probably the most appropriate action.
_____________
Roman Shpount

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


On F=
ri, Jul 11, 2014 at 12:07 PM, Justin Uberti <juberti@google.com>=
 wrote:


The fact that WebRTC implementations MUST=
 ignore the address and port in the c=3D/m=3D lines will be written into JS=
EP, S 5.6/5.7.




Is it going to c=
ompletely ignore these parameters or would it still honor port 0 to indicat=
e that m line disabled?

What about 0.0.0.0 address=
 to indicate hold? These should not be allowed per RFC 5245 section 9.1.1.1=
 but I still do see it used in SIP, especially with various B2BUA scenarios=
 where this is the only way for a pure signaling agent to put a call on hol=
d or to resolve collision. There are other ways to deal with this in WebRTC=
 but this will still come up during interop with SIP.



Would it also document on what happens when WebRTC impl=
ementation receives an answer SDP with ice-mismatch attribute? An error in =
such case is probably the most appropriate action.
_____________<=
br>
Roman Shpount
=C2=A0


--e89a8f6473c770fd7c04fdee7769--


From nobody Fri Jul 11 10:44:24 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664DF1A0AEE for ; Fri, 11 Jul 2014 10:44:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level: 
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 tO_IlxjyS9Gs for ; Fri, 11 Jul 2014 10:44:19 -0700 (PDT)
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89E11A0A9D for ; Fri, 11 Jul 2014 10:44:18 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id bs8so71128wib.8 for ; Fri, 11 Jul 2014 10:44:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fI+5YxKJhsy0vq175caEBqgOMSsJqKy1atAvfRtYSXA=; b=F/LX1HKUpGTZMq8SJhXAWSFmg0+a8amD1wXtaf7NZnVUwqWosLZIXj0zi0DfiFr9jt q80toTb7F0DqPRtmbgasds40VlisS4KWx8S1K29OiNmANpXRgAJE32zEpZcIBs4bKf12 x2+OeEJO1ndYDG0kIOrHD/snGg2OWV4MsqXSgP78OtLIJvLQP+kQKTZc+rpHOKucjli9 rSC4iYoxJZSHEWoSwNv6vCt02SvC+FyGnZHyiQPeVlmWbFUv3/ZyPwXbwu/jb2XPiN6Q cVjLg9kqiaouDhGV9XGBFba/vkEzXEE9oQzSnEhXORBAvw2NZGQe6OhICmoGgeo7WRVZ +cKQ==
X-Gm-Message-State: ALoCoQlQ6zslvEO/mn9rJY9EP1YWYZ/54yBb5+C3u3uorxcRo38AVPSJL6mJ2qwz7Em5IF7bZcM9
X-Received: by 10.194.123.105 with SMTP id lz9mr423232wjb.122.1405100653176; Fri, 11 Jul 2014 10:44:13 -0700 (PDT)
Received: from [192.168.1.23] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id ev9sm6447051wjc.49.2014.07.11.10.44.10 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 10:44:12 -0700 (PDT)
Message-ID: <53C02268.9030109@jitsi.org>
Date: Fri, 11 Jul 2014 19:44:08 +0200
From: Emil Ivov 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Justin Uberti 
References:  <53BC1D53.4080904@jitsi.org>   
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/tgTYSWxbyHtqOTBnTyivI_Tqtcg
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ICE-Mismatch and WebRTC
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 17:44:20 -0000

On 11.07.14, 18:07, Justin Uberti wrote:
> The fact that WebRTC implementations MUST ignore the address and port in
> the c=/m= lines will be written into JSEP, S 5.6/5.7.

MUST sounds unnecessarily strong here. Imagine Alice's WebRTC client 
sends offer:

        ...
        c=IN IP4 *192.168.0.1*
        t=0 0
        a=ice-pwd:asd88fgpdd777uzjYhagZg
        a=ice-ufrag:8hhY
        a=ice-options:trickle
        m=audio 5000 RTP/AVP 0
        a=candidate:1 1 UDP 2130706431 *192.168.0.1* 5000 typ host
        ...

and then Bob's browser gets

        ...
        c=IN IP4 *87.65.43.21*
        t=0 0
        a=ice-pwd:asd88fgpdd777uzjYhagZg
        a=ice-ufrag:8hhY
        a=ice-options:trickle
        m=audio 2626 RTP/AVP 0
        a=candidate:1 1 UDP 2130706431 *192.168.0.1* 5000 typ host
        ...

Don't you think Bob's browser has a pretty good reason to reject the 
offer because chances are the call would fail anyway?

Emil

>
> On Tue, Jul 8, 2014 at 1:04 PM, Emil Ivov  > wrote:
>
>     On Tue, Jul 8, 2014 at 9:04 PM, Roman Shpount      > wrote:
>      > On Tue, Jul 8, 2014 at 12:33 PM, Emil Ivov      > wrote:
>      >>
>      >> On 07.07.14, 21:48, Roman Shpount wrote:
>      >>>
>      >>> Is it possible to run into ICE-Mismatch with WebRTC? Should we
>     specify
>      >>> that default candidate (c= and m= line based candidate) should be
>      >>> ignored and thus mismatch check should not be performed?
>      >>
>      >>
>      >> I guess running into an ICE mismatch with WebRTC is just as
>     possible as
>      >> with any other ICE implementation. I suppose the only difference
>     would be
>      >> that rather than falling back to 3264 semantics, WebRTC
>     implementations will
>      >> rather drop the session because without ICE, they wouldn't be
>     able to do
>      >> consent checks for it.
>      >>
>      >
>      > My point was that WebRTC would never use 3264 semantics
>
>     Indeed. This was also my point.
>
>      > and use address from
>      > c= and m= lines for any purpose, so why does it need to check
>     that this
>      > address is correct? Would it be more sensible just ignore
>     whatever value
>      > happen to be there?
>
>     With the exception of trickle ICE's use of :: (or 0.0.0.0) an ICE
>     mismatch indicates that there is an entity on the signalling path that
>     is overwriting c= line addresses and m= line ports. The idea of
>     dropping ICE here is that the infrastructure is likely performing
>     Hosted NAT Traversal and latching so insisting on ICE is likely to
>     lead to unexpected situations.
>
>      > Or, better yet end point can generate an error instead
>      > of generating a response with ice-mismatch.
>
>     Agreed. Sending an answer with ice-mismatch means downgrading to basic
>     3264 and that doesn't make sense for WebRTC.
>
>     Agreed.
>
>     Emil
>
>     --
>     https://jitsi.org
>
>     _______________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org 
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>

-- 
https://jitsi.org


From nobody Fri Jul 11 10:56:58 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545B31B2C82 for ; Fri, 11 Jul 2014 10:56:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_111=0.6, SPF_PASS=-0.001] autolearn=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 0ysX5aJ9TIph for ; Fri, 11 Jul 2014 10:56:48 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE1BE1B2C7A for ; Fri, 11 Jul 2014 10:56:47 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id x13so1465007wgg.7 for ; Fri, 11 Jul 2014 10:56:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RsdhWGEelJM6MLvxsrnB/KdVWyitEhLo9ULlGT2jasw=; b=Aimnn8nsXVU0/S5wqOv3U5aFsQyT+owuQUYz6/Z8H7Z5VVXpMd0PXWK9R1hQfx2Dlz BY6DDHjgP/93wgJt4JzXCRIY+bTisR8a4Ti+EmbFEtr+uCgzwRMnmIDe65WToxwzWjpl 3Q6yRKs/ftYditz3s7oslJGuMmKSwHQJoTikU8t4k8IR84ftkg5LSdy3YA1qNbOLKYiX wwbZTJ5spQ4lTY8S2w7yDdtw403eLt9fCDSGnsiVxcFoj3SKnNq9z9eB+csN+7G/7Alu JaD6URwjTtGzYAu+7A+fI2Es+xBpHx/Z2zVQD6FrRxddywdAGsO7bz2Q7l4TSExNmHyu F4mQ==
MIME-Version: 1.0
X-Received: by 10.180.37.230 with SMTP id b6mr6760273wik.47.1405101404123; Fri, 11 Jul 2014 10:56:44 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Fri, 11 Jul 2014 10:56:44 -0700 (PDT)
In-Reply-To: 
References:   
Date: Fri, 11 Jul 2014 10:56:44 -0700
Message-ID: 
From: Martin Thomson 
To: Justin Uberti 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VUZIdRsVeALj945z9TM1wNRF1XI
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Security Architecture: IdP for RTP and RTCP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 17:56:49 -0000

On 11 July 2014 09:03, Justin Uberti  wrote:
> Different m= lines can have different fingerprints, but do we expect to
> support multiple fingerprints with the same digest algorithm on the same m=
> line, where the receiver then checks that the received certificate matches
> one of the possible fingerprints?

That's what the spec says to do.  That's how Firefox currently
operates.  It's not particularly hard to do.

To be precise, it assembles all relevant a=fingerprint attributes for
the m= section and allows the session to proceed if all sections have
one match, using the provided hash function.  I think that we provide
SHA-256, but support the full intersection of the textual names
registry and what is implemented and enabled (i.e., sha1 is OK).

I don't think that we require that the hash function match the
function used in the certificate signature; that's a nonsensical
requirement.


From nobody Fri Jul 11 11:05:31 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730EF1B28E3 for ; Fri, 11 Jul 2014 11:05:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 lsziZ_Cs_Z-f for ; Fri, 11 Jul 2014 11:05:27 -0700 (PDT)
Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4557D1B2883 for ; Fri, 11 Jul 2014 11:05:26 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id a1so698173wgh.11 for ; Fri, 11 Jul 2014 11:05:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XZYvJ5J/B3SxdDUHyeD6oVz7oOzQ0Ds33Pz7Sj2gQ/U=; b=kp2CorSR6Arw8TYO1yOhNGJcNhw/WqIRCjvNKjc7dZS76jvxwBYKescwv3GWwCfbrP wjv4nJdCBEUdBcSDWdBtYkNAYp4HLfPKTyH+7/Cje7tQwe8vcJS0dvh+ZCXZ1buL952z 9r3E2IqdsaEvivByLX+CrIrjDNpU7KFuDnueYXWbvSwIRZWGQtoqK18jxsA9okjuD3qp 8lhVvS3yCt5ACa3lwLcyKEnnDPOi4phHtFe4l6R2Mq2pryFrciGN9wFtoOTVQexBKmGN jZTCZ5erOq9y7rjZNW+2HhXQ5N6fs9VK0t7JElD8Vk2VYHEEXWkevX29gf8vjd9FDR+Q Xfug==
MIME-Version: 1.0
X-Received: by 10.194.91.228 with SMTP id ch4mr448323wjb.59.1405101921479; Fri, 11 Jul 2014 11:05:21 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Fri, 11 Jul 2014 11:05:21 -0700 (PDT)
In-Reply-To: 
References: 
Date: Fri, 11 Jul 2014 11:05:21 -0700
Message-ID: 
From: Martin Thomson 
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_X6FRywRVT77JY5Zw9sKz9FDblg
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Which hashes are valid for the fingerprint attribute?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 18:05:28 -0000

On 11 July 2014 05:26, I=C3=B1aki Baz Castillo  wrote:
>
>    hash-func    =3D  "sha-1" / "sha-224" / "sha-256" /
>                          "sha-384" / "sha-512" /
>                          "md5" / "md2" / token


Firefox supports sha*.  We will not support md* and don't believe that
we are obligated to.  Forbidding md* might be a good idea:
https://github.com/rtcweb-wg/security-arch/issues/10


From nobody Fri Jul 11 11:07:25 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E561B28E3 for ; Fri, 11 Jul 2014 11:07:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 j-dVTcwM6cU1 for ; Fri, 11 Jul 2014 11:07:12 -0700 (PDT)
Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 040CA1B2930 for ; Fri, 11 Jul 2014 11:07:11 -0700 (PDT)
Received: by mail-we0-f169.google.com with SMTP id t60so1453410wes.28 for ; Fri, 11 Jul 2014 11:07:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BJ4MolwNxW0ib/kmOf8tDBy+4TxCxrVot/uAVKo/WbU=; b=sPn2wLFLqTQlqoGrQGUNasFwFIHkPRsmuNLiurObvRAUVZf3cpatWhD5r2NZNi47wq 2dYkcrhgw/CnIaRXu7wN9tbR/P9fgEK++LpTthxHmfmOg5o6S6WjwD354YQzSIn8/rPq 2NmUIkOlIOzDF3ww6QQdNlhldeEuiK4LIuS7L95k3KvVuGdv6dxO/c/X3amdUHHBrNbF EEvjhsjZKJoKJV3NoeHA82mW9lQrmRhLZyFzguivsTbPqK/L0RytL43e3WLSUx5nU4T5 jae0ndFUKpLYHX9MXvBQJdpvSnCUaIMEgO5I58VKb/1uxdmn+z6RBbYNMNEDK/a2rlEO QkOQ==
MIME-Version: 1.0
X-Received: by 10.180.210.239 with SMTP id mx15mr6672435wic.65.1405102028633;  Fri, 11 Jul 2014 11:07:08 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Fri, 11 Jul 2014 11:07:08 -0700 (PDT)
In-Reply-To: 
References:  
Date: Fri, 11 Jul 2014 11:07:08 -0700
Message-ID: 
From: Martin Thomson 
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/FKRXsG00TTmb8cdClOp4B9K4h94
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Which hashes are valid for the fingerprint attribute?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 18:07:14 -0000

On 11 July 2014 11:05, Martin Thomson  wrote:
> On 11 July 2014 05:26, I=C3=B1aki Baz Castillo  wrote:
>>
>>    hash-func    =3D  "sha-1" / "sha-224" / "sha-256" /
>>                          "sha-384" / "sha-512" /
>>                          "md5" / "md2" / token
>
>
> Firefox supports sha*.  We will not support md* and don't believe that
> we are obligated to.  Forbidding md* might be a good idea:
> https://github.com/rtcweb-wg/security-arch/issues/10

Oh, and I forgot to add, like Chrome, we will *provide* sha-256.  For
the near term, that is what we consider to be the right choice.


From nobody Fri Jul 11 11:43:41 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3F81B2935 for ; Fri, 11 Jul 2014 11:43:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level: 
X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyhVkft1vAmo for ; Fri, 11 Jul 2014 11:43:37 -0700 (PDT)
Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 220561B2938 for ; Fri, 11 Jul 2014 11:43:36 -0700 (PDT)
Received: by mail-vc0-f173.google.com with SMTP id lf12so2839280vcb.4 for ; Fri, 11 Jul 2014 11:43:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ce2qAa6YJ2MkDQHE/FI29Knwc+Vcwo8tc3JEcaNQVkY=; b=aO/hNTzkPleemAHdAAz0vnIxLlSV+7mOj9QjmgKbbtyQ+uh5tXAepD084uk/1WGZvH 7ocrqreUJUvxg9VauCbLSwbPDXqkgvoL97io0U1abafw4yLcrDWuBAsCMAn5rvPN8Q10 ZGG3vWpXCliyEfAsZ30UCp6PDLBetwphNVMNKZGLkrWN/gU5qscnHIyzmLBFA0tHWfCr g+LSH8IxeRWd8f4Q/YQrG4e2MNZwx0sWq3Gk2T0z5DrUW1CJWNQyeNYEAXBNtpezqug9 JajRo5bwzPzKzvmp0e8/pPROpubBXcdxL1EHxHb4uuo/rwddoBSVY8HI60dv330tlcDO WHDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ce2qAa6YJ2MkDQHE/FI29Knwc+Vcwo8tc3JEcaNQVkY=; b=hg9SlImLAFjZNEegzdmAsfYvoj4GeTLGrCSFAaVzbZftwFjFyccK3MWemHKWrArly4 GyJVSc6NxxTisFFa5ySCH7C/0InqE4/PtFA7J/v/z/b9SDbWOssrW8sQ3vfDOrfpIA18 /ho44LdRgzUx4zU/iXh6PynXQSGCrb2vb7f/29c60+Gjc7fZre+lTARww0gLjRf6ARQf eOUuY7yGg3hOnTH1Kp5CKLYi8aL/N4FD05/MLJDXz8ssOU0u3X9xNc1O48DARRRJPjtC fcCD/aVlfjw/kD09G0VsP5HcRUDlTojvL0yMhSid+7q+rvxSRx06wb0Ho+A2umg8n3C5 BanQ==
X-Gm-Message-State: ALoCoQll0hoU90QsHwh7WXRRrU3X3L50pNhSCDJ9Bkkg6F2IcpS6oTzYvU0vEfqvTAdnHCDsl1Lp
MIME-Version: 1.0
X-Received: by 10.52.189.161 with SMTP id gj1mr732200vdc.2.1405104215186; Fri, 11 Jul 2014 11:43:35 -0700 (PDT)
Received: by 10.52.27.8 with HTTP; Fri, 11 Jul 2014 11:43:35 -0700 (PDT)
Received: by 10.52.27.8 with HTTP; Fri, 11 Jul 2014 11:43:35 -0700 (PDT)
In-Reply-To: 
References:         
Date: Fri, 11 Jul 2014 11:43:35 -0700
Message-ID: 
From: Justin Uberti 
To: Roman Shpount 
Content-Type: multipart/alternative; boundary=001a1133f7389e811c04fdef51a4
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/K4dR3BQ6IOnwMrekYieQusBeIzw
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Question about ICE-Lite server
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 18:43:39 -0000

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

Chrome doesn't do that. I think that behavior is harmful and is going to be
changed in ice-bis.
On Jul 11, 2014 1:26 PM, "Roman Shpount"  wrote:

> On Fri, Jul 11, 2014 at 12:33 PM, Justin Uberti 
> wrote:
>
>> Yes, Chrome always uses aggressive nomination unless ICE Lite is used.
>>
>>
> What about the cases when it sees unknown "ice-options" attribute? This
> should make Chrome use regular nomination as well.
> _____________
> Roman Shpount
>
>

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


Chrome doesn't do that. I think that behavior is harmful=
 and is going to be changed in ice-bis.


On Jul 11, 2014 1:26 PM, "Roman Shpount&quo=
t; <roman@telurix.com> wrote=
:


On F=
ri, Jul 11, 2014 at 12:33 PM, Justin Uberti <juberti@google.com>=
 wrote:



Yes, Chrome always uses aggressive nomina=
tion unless ICE Lite is used.





What about the cases when it sees unknown "ice-option=
s" attribute? This should make Chrome use regular nomination as well.<=
/div>


_____________
Roman Shpount
=C2=A0




--001a1133f7389e811c04fdef51a4--


From nobody Fri Jul 11 11:47:56 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB22D1B2940 for ; Fri, 11 Jul 2014 11:47:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.429
X-Spam-Level: 
X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=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 19WhdqhSVSLG for ; Fri, 11 Jul 2014 11:47:42 -0700 (PDT)
Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33A221A0364 for ; Fri, 11 Jul 2014 11:46:44 -0700 (PDT)
Received: by mail-vc0-f175.google.com with SMTP id hy4so2852268vcb.6 for ; Fri, 11 Jul 2014 11:46:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tfzVr6FPy929/fX8owqPJe9dlH9I3Aa93n+f6sNfncU=; b=jPcd1HKU9rJLPkWptQnBNvUvr1Ng6YH4dCa7quYP4t09e2px6e8AekrO+Q1D+e9vCk DjkPAKFikQE5nEtO4miqJkYEmtUfXN3JkztJO5YJc1rgSh4z0oCz7PM746JT32/A6agx zrMNoYhcFT3//7mZ42fQkhScjxq5YjYeW6RZOhQhvd0CNn6+Wif0B5on7CAI6uysq9X5 ZBjt2K83Ud3kom93CKzQA8XQA6i5mVAhPqAVnEM4c6jPENAlkwf1VsR8eoUbTbey9Wda jNaQIcNp2EA3CVKIUnGlb0xD5zw2FEHIIqLqGOMuFKGsmOxwDQiNA3yFztndX8vgq+4f sM/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tfzVr6FPy929/fX8owqPJe9dlH9I3Aa93n+f6sNfncU=; b=A5OgUqpoizaZZFCLAeWmfWlC4aSY2gcdvL/GqDmvNswUF8unm89E9OHA5Oef3ZQKz1 Q5IPjMkHUmFs3xInkzO5YSSeS7CUsFuuPpgOLUxOUKq7Of7hKOPDJNsUZQ51Q6cjD40y BnHWu1f2wk2QPvNgoyQ/GJvwbzi1zwURdHpx9Pjfa1/hK+D0btJzramnw826Phj7AZEd LI7fxTnH+eShXg3nXJMiMp9aXybsV+xhN43iwOwz6/Msl9/6ToTQzpGr8dGtXA6PAYtB m8pXwVofV9kqT7qB3jBkWZw2dR9GkViZBrNQdMfa2AfRt4qyB+giOiOEIKbwtHA0ZMD0 vyFg==
X-Gm-Message-State: ALoCoQm4LfPTvsfVQ9DJjX6+xyewNmUt9ihcdrflQFX4xwnGRgyA7MdjgTZR60WySSnkq4StHe05
MIME-Version: 1.0
X-Received: by 10.221.56.132 with SMTP id wc4mr841215vcb.38.1405104403285; Fri, 11 Jul 2014 11:46:43 -0700 (PDT)
Received: by 10.52.27.8 with HTTP; Fri, 11 Jul 2014 11:46:43 -0700 (PDT)
Received: by 10.52.27.8 with HTTP; Fri, 11 Jul 2014 11:46:43 -0700 (PDT)
In-Reply-To: 
References:    
Date: Fri, 11 Jul 2014 11:46:43 -0700
Message-ID: 
From: Justin Uberti 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=001a1133793ed4a6df04fdef5c4a
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3wy7gLj1heQTGL5W54TJZ5Skpoo
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Security Architecture: IdP for RTP and RTCP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 18:47:43 -0000

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

That seems fine, as you say, it's not hard to implement. I just wasn't
aware the spec had provisions for that.
On Jul 11, 2014 1:56 PM, "Martin Thomson"  wrote:

> On 11 July 2014 09:03, Justin Uberti  wrote:
> > Different m= lines can have different fingerprints, but do we expect to
> > support multiple fingerprints with the same digest algorithm on the same
> m=
> > line, where the receiver then checks that the received certificate
> matches
> > one of the possible fingerprints?
>
> That's what the spec says to do.  That's how Firefox currently
> operates.  It's not particularly hard to do.
>
> To be precise, it assembles all relevant a=fingerprint attributes for
> the m= section and allows the session to proceed if all sections have
> one match, using the provided hash function.  I think that we provide
> SHA-256, but support the full intersection of the textual names
> registry and what is implemented and enabled (i.e., sha1 is OK).
>
> I don't think that we require that the hash function match the
> function used in the certificate signature; that's a nonsensical
> requirement.
>

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


That seems fine, as you say, it's not hard to implement.=
 I just wasn't aware the spec had provisions for that.


On Jul 11, 2014 1:56 PM, "Martin Thomson&qu=
ot; <martin.thomson@gmail.co=
m> wrote:

On 11 July 2014 09:03, Justin Uberti <juberti@google.com> wrote:

> Different m=3D lines can have different fingerprints, but do we expect=
 to

> support multiple fingerprints with the same digest algorithm on the sa=
me m=3D

> line, where the receiver then checks that the received certificate mat=
ches

> one of the possible fingerprints?



That's what the spec says to do. =C2=A0That's how Firefox currently=


operates. =C2=A0It's not particularly hard to do.



To be precise, it assembles all relevant a=3Dfingerprint attributes for

the m=3D section and allows the session to proceed if all sections have

one match, using the provided hash function. =C2=A0I think that we provide<=
br>
SHA-256, but support the full intersection of the textual names

registry and what is implemented and enabled (i.e., sha1 is OK).



I don't think that we require that the hash function match the

function used in the certificate signature; that's a nonsensical

requirement.




--001a1133793ed4a6df04fdef5c4a--


From nobody Fri Jul 11 11:56:13 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CABC1A039C for ; Fri, 11 Jul 2014 11:55:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.829
X-Spam-Level: 
X-Spam-Status: No, score=-0.829 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=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 Gno6BWP17jy7 for ; Fri, 11 Jul 2014 11:55:57 -0700 (PDT)
Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D0081A0522 for ; Fri, 11 Jul 2014 11:55:49 -0700 (PDT)
Received: by mail-vc0-f179.google.com with SMTP id id10so2904474vcb.10 for ; Fri, 11 Jul 2014 11:55:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=68SlSH1LdBf33Zbm61JL1L1hP4sHKMiQnXZidCKzvTc=; b=aDmbvLj05zGb/nl03XgBXFjo8PY5L/8r+h5VnqXLQ0EEIY23bs3056HR+m9YZEJYUa 1WwXgL6UNsEAz2h+DKXkdMqyjRiObcEMU2cqyWjhANQ6Yqntjd6afDXC6o3wwJxdaoWg mjIjJRHRWcfO5WfAv3C1xoYHtTtwrL2k+tgNzEBtAIG0bzCUExAHsAI8DwojfacRAATL EsbtkXLJ6i0ZPcAmPl614NrcTmLqSV/N1BAqtkM/xV8JpVFopGB1ert+rh4mfevTRjcD 1qCpCsuYu+hrptostdeKhZzWnsb/p7Rizro8f0tF/b8kYYbMBKs3rSC1ps/FI89XQd/u EU6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=68SlSH1LdBf33Zbm61JL1L1hP4sHKMiQnXZidCKzvTc=; b=Rbr+cDKKll+7/y5g3IqTSR+4AsLP8VJiWk/lAReL9XyOt8FBOqly9pgNRfzhfJquTa aVMS5/ncfNV4RJw2oJIOj/VM+9VR/hKcLMAbfvU2m5NzBhZzm9Ht9YD12+1ZJFwwIvQE XUr3UVX7SPaIjwbET6y2+ri3aV2j0b+Nm1bvYgbH0/3FWcqmR6lT+z27sMpSymnRva7+ giQKfWzgBpta7KORrpA9uggdppo2Nj+Vf7B/ynSqtogJFPWNXnP3uW+8IgURIstvbmIO CgPNAf6Ptnk1vcOvFcc/BoNqvsawPeT1EJ/jNvBPPFii6e4qRBrL4Kth/7B5bLdUZ2Mz wZgg==
X-Gm-Message-State: ALoCoQlXNp2qar9/0rtd0waelR/h9BDqvVI2B6YvVHhIZtCuaCOVpyHU3ygtn6FkIh4zu4fTJOX1
MIME-Version: 1.0
X-Received: by 10.220.44.20 with SMTP id y20mr824870vce.60.1405104948509; Fri, 11 Jul 2014 11:55:48 -0700 (PDT)
Received: by 10.52.27.8 with HTTP; Fri, 11 Jul 2014 11:55:46 -0700 (PDT)
Received: by 10.52.27.8 with HTTP; Fri, 11 Jul 2014 11:55:46 -0700 (PDT)
In-Reply-To: <53C02268.9030109@jitsi.org>
References:  <53BC1D53.4080904@jitsi.org>    <53C02268.9030109@jitsi.org>
Date: Fri, 11 Jul 2014 11:55:46 -0700
Message-ID: 
From: Justin Uberti 
To: Emil Ivov 
Content-Type: multipart/alternative; boundary=047d7b3a98d0541e6704fdef7df4
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xBfw4pzz_frpoegdp7_mZFypO3E
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] ICE-Mismatch and WebRTC
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 18:55:59 -0000

--047d7b3a98d0541e6704fdef7df4
Content-Type: text/plain; charset=UTF-8

Well, it should either be MUST ignore, or MUST fail. I can go either way, I
just want deterministic API behavior.
On Jul 11, 2014 1:44 PM, "Emil Ivov"  wrote:

> On 11.07.14, 18:07, Justin Uberti wrote:
>
>> The fact that WebRTC implementations MUST ignore the address and port in
>> the c=/m= lines will be written into JSEP, S 5.6/5.7.
>>
>
> MUST sounds unnecessarily strong here. Imagine Alice's WebRTC client sends
> offer:
>
>        ...
>        c=IN IP4 *192.168.0.1*
>        t=0 0
>        a=ice-pwd:asd88fgpdd777uzjYhagZg
>        a=ice-ufrag:8hhY
>        a=ice-options:trickle
>        m=audio 5000 RTP/AVP 0
>        a=candidate:1 1 UDP 2130706431 *192.168.0.1* 5000 typ host
>        ...
>
> and then Bob's browser gets
>
>        ...
>        c=IN IP4 *87.65.43.21*
>        t=0 0
>        a=ice-pwd:asd88fgpdd777uzjYhagZg
>        a=ice-ufrag:8hhY
>        a=ice-options:trickle
>        m=audio 2626 RTP/AVP 0
>        a=candidate:1 1 UDP 2130706431 *192.168.0.1* 5000 typ host
>        ...
>
> Don't you think Bob's browser has a pretty good reason to reject the offer
> because chances are the call would fail anyway?
>
> Emil
>
>
>> On Tue, Jul 8, 2014 at 1:04 PM, Emil Ivov > > wrote:
>>
>>     On Tue, Jul 8, 2014 at 9:04 PM, Roman Shpount >     > wrote:
>>      > On Tue, Jul 8, 2014 at 12:33 PM, Emil Ivov >     > wrote:
>>      >>
>>      >> On 07.07.14, 21:48, Roman Shpount wrote:
>>      >>>
>>      >>> Is it possible to run into ICE-Mismatch with WebRTC? Should we
>>     specify
>>      >>> that default candidate (c= and m= line based candidate) should be
>>      >>> ignored and thus mismatch check should not be performed?
>>      >>
>>      >>
>>      >> I guess running into an ICE mismatch with WebRTC is just as
>>     possible as
>>      >> with any other ICE implementation. I suppose the only difference
>>     would be
>>      >> that rather than falling back to 3264 semantics, WebRTC
>>     implementations will
>>      >> rather drop the session because without ICE, they wouldn't be
>>     able to do
>>      >> consent checks for it.
>>      >>
>>      >
>>      > My point was that WebRTC would never use 3264 semantics
>>
>>     Indeed. This was also my point.
>>
>>      > and use address from
>>      > c= and m= lines for any purpose, so why does it need to check
>>     that this
>>      > address is correct? Would it be more sensible just ignore
>>     whatever value
>>      > happen to be there?
>>
>>     With the exception of trickle ICE's use of :: (or 0.0.0.0) an ICE
>>     mismatch indicates that there is an entity on the signalling path that
>>     is overwriting c= line addresses and m= line ports. The idea of
>>     dropping ICE here is that the infrastructure is likely performing
>>     Hosted NAT Traversal and latching so insisting on ICE is likely to
>>     lead to unexpected situations.
>>
>>      > Or, better yet end point can generate an error instead
>>      > of generating a response with ice-mismatch.
>>
>>     Agreed. Sending an answer with ice-mismatch means downgrading to basic
>>     3264 and that doesn't make sense for WebRTC.
>>
>>     Agreed.
>>
>>     Emil
>>
>>     --
>>     https://jitsi.org
>>
>>     _______________________________________________
>>     rtcweb mailing list
>>     rtcweb@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>>
> --
> https://jitsi.org
>

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


Well, it should either be MUST ignore, or MUST fail. I can g=
o either way, I just want deterministic API behavior.


On Jul 11, 2014 1:44 PM, "Emil Ivov" &=
lt;emcho@jitsi.org> wrote:

On 11.07.14, 18:07, Justin Uberti wrote:



The fact that WebRTC implementations MUST ignore the address and port in
the c=3D/m=3D lines will be written into JSEP, S 5.6/5.7.





MUST sounds unnecessarily strong here. Imagine Alice's WebRTC client se=
nds offer:



=C2=A0 =C2=A0 =C2=A0 =C2=A0...

=C2=A0 =C2=A0 =C2=A0 =C2=A0c=3DIN IP4 *192.168.0.1*

=C2=A0 =C2=A0 =C2=A0 =C2=A0t=3D0 0

=C2=A0 =C2=A0 =C2=A0 =C2=A0a=3Dice-pwd:asd88fgpdd777uzjYhagZg

=C2=A0 =C2=A0 =C2=A0 =C2=A0a=3Dice-ufrag:8hhY

=C2=A0 =C2=A0 =C2=A0 =C2=A0a=3Dice-options:trickle

=C2=A0 =C2=A0 =C2=A0 =C2=A0m=3Daudio 5000 RTP/AVP 0

=C2=A0 =C2=A0 =C2=A0 =C2=A0a=3Dcandidate:1 1 UDP 2130706431 *192.168.0.1* 5=
000 typ host

=C2=A0 =C2=A0 =C2=A0 =C2=A0...



and then Bob's browser gets



=C2=A0 =C2=A0 =C2=A0 =C2=A0...

=C2=A0 =C2=A0 =C2=A0 =C2=A0c=3DIN IP4 *87.65.43.21*

=C2=A0 =C2=A0 =C2=A0 =C2=A0t=3D0 0

=C2=A0 =C2=A0 =C2=A0 =C2=A0a=3Dice-pwd:asd88fgpdd777uzjYhagZg

=C2=A0 =C2=A0 =C2=A0 =C2=A0a=3Dice-ufrag:8hhY

=C2=A0 =C2=A0 =C2=A0 =C2=A0a=3Dice-options:trickle

=C2=A0 =C2=A0 =C2=A0 =C2=A0m=3Daudio 2626 RTP/AVP 0

=C2=A0 =C2=A0 =C2=A0 =C2=A0a=3Dcandidate:1 1 UDP 2130706431 *192.168.0.1* 5=
000 typ host

=C2=A0 =C2=A0 =C2=A0 =C2=A0...



Don't you think Bob's browser has a pretty good reason to reject th=
e offer because chances are the call would fail anyway?



Emil







On Tue, Jul 8, 2014 at 1:04 PM, Emil Ivov <emcho@jitsi.org

<mailto:emcho@jitsi=
.org>> wrote:



=C2=A0 =C2=A0 On Tue, Jul 8, 2014 at 9:04 PM, Roman Shpount <roman@telurix.com

=C2=A0 =C2=A0 <mailto:roman@telurix.com>> wrote:

=C2=A0 =C2=A0 =C2=A0> On Tue, Jul 8, 2014 at 12:33 PM, Emil Ivov <emcho@jitsi.org

=C2=A0 =C2=A0 <mailto:emcho@jitsi.org>> wrote:

=C2=A0 =C2=A0 =C2=A0>>

=C2=A0 =C2=A0 =C2=A0>> On 07.07.14, 21:48, Roman Shpount wrote:

=C2=A0 =C2=A0 =C2=A0>>>

=C2=A0 =C2=A0 =C2=A0>>> Is it possible to run into ICE-Mismatch wi=
th WebRTC? Should we

=C2=A0 =C2=A0 specify

=C2=A0 =C2=A0 =C2=A0>>> that default candidate (c=3D and m=3D line=
 based candidate) should be

=C2=A0 =C2=A0 =C2=A0>>> ignored and thus mismatch check should not=
 be performed?

=C2=A0 =C2=A0 =C2=A0>>

=C2=A0 =C2=A0 =C2=A0>>

=C2=A0 =C2=A0 =C2=A0>> I guess running into an ICE mismatch with WebR=
TC is just as

=C2=A0 =C2=A0 possible as

=C2=A0 =C2=A0 =C2=A0>> with any other ICE implementation. I suppose t=
he only difference

=C2=A0 =C2=A0 would be

=C2=A0 =C2=A0 =C2=A0>> that rather than falling back to 3264 semantic=
s, WebRTC

=C2=A0 =C2=A0 implementations will

=C2=A0 =C2=A0 =C2=A0>> rather drop the session because without ICE, t=
hey wouldn't be

=C2=A0 =C2=A0 able to do

=C2=A0 =C2=A0 =C2=A0>> consent checks for it.

=C2=A0 =C2=A0 =C2=A0>>

=C2=A0 =C2=A0 =C2=A0>

=C2=A0 =C2=A0 =C2=A0> My point was that WebRTC would never use 3264 sema=
ntics



=C2=A0 =C2=A0 Indeed. This was also my point.



=C2=A0 =C2=A0 =C2=A0> and use address from

=C2=A0 =C2=A0 =C2=A0> c=3D and m=3D lines for any purpose, so why does i=
t need to check

=C2=A0 =C2=A0 that this

=C2=A0 =C2=A0 =C2=A0> address is correct? Would it be more sensible just=
 ignore

=C2=A0 =C2=A0 whatever value

=C2=A0 =C2=A0 =C2=A0> happen to be there?



=C2=A0 =C2=A0 With the exception of trickle ICE's use of :: (or 0.0.0.0=
) an ICE

=C2=A0 =C2=A0 mismatch indicates that there is an entity on the signalling =
path that

=C2=A0 =C2=A0 is overwriting c=3D line addresses and m=3D line ports. The i=
dea of

=C2=A0 =C2=A0 dropping ICE here is that the infrastructure is likely perfor=
ming

=C2=A0 =C2=A0 Hosted NAT Traversal and latching so insisting on ICE is like=
ly to

=C2=A0 =C2=A0 lead to unexpected situations.



=C2=A0 =C2=A0 =C2=A0> Or, better yet end point can generate an error ins=
tead

=C2=A0 =C2=A0 =C2=A0> of generating a response with ice-mismatch.



=C2=A0 =C2=A0 Agreed. Sending an answer with ice-mismatch means downgrading=
 to basic

=C2=A0 =C2=A0 3264 and that doesn't make sense for WebRTC.



=C2=A0 =C2=A0 Agreed.



=C2=A0 =C2=A0 Emil



=C2=A0 =C2=A0 --

=C2=A0 =C2=A0 https://jitsi=
.org



=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 rtcweb mailing list

=C2=A0 =C2=A0 rtcweb@i=
etf.org <mailto:rtcweb@ietf.org>

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









-- 

https://jitsi.org




--047d7b3a98d0541e6704fdef7df4--


From nobody Fri Jul 11 12:03:11 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9346F1B2C7D for ; Fri, 11 Jul 2014 12:03:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level: 
X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9Z_SmP8k1s7 for ; Fri, 11 Jul 2014 12:03:07 -0700 (PDT)
Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9CB51A0522 for ; Fri, 11 Jul 2014 12:03:07 -0700 (PDT)
Received: by mail-vc0-f176.google.com with SMTP id ik5so2859078vcb.7 for ; Fri, 11 Jul 2014 12:03:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5SaFW5ToV4vbfbBjcoZ34AGwW3irz/SaTy5tIrErWtg=; b=edwAlKxjWlxXvcImiXeFve3KNglVyEZAzgvlFPPYcgm4QWpymtSkPJGvt3T/s/coj/ iVO+T2isdTJ+HCP6GOvcyh4JXJbSv52GpWuuGzdNK4V5jGDNDtJroP11V0vKM2FhwavF e0RLWkAityCyNlkMh3MZpa0q6ESdS/zOmx6dSDLb3jc1iorFHEAtZB5sYcWSznLt4Btt kzMSnQRfVe9S9r6dbnmQhPCJ7tWaedJUo24GO/i6dr0plkfgt7aALivow35C55jD40i/ q8P4b/ptjXypG2JtCaO6o3M2Rz0ek/XtazFHYMB+PDq36upCllXdhLY2ZN+kczAqiidi 2Uiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5SaFW5ToV4vbfbBjcoZ34AGwW3irz/SaTy5tIrErWtg=; b=WO+tVoGAVkuDSbdFwUO8YRV9JeFP2a7TwEvJhVuhVRZlyMbNcqCkWyRsq6xzf+15RU +CmLvRTn3BvWXgUgUF1y9vtw1IV/9nxaKRE35qp+I8MoLR0wkIw9Ve+6QrsFwZf196US nebPhOupPRWDAGLFAhbJXsoM1bGkPkcXGuO5jGhmZayJdP/r8ltA+vi8+pbmJt3K0+In OHsFsyR+FZGaeJkKF1xIKcD5ZHnuXfKy2zbDkyFQfuqSaykXigzF+avNogi3iVZfbdST Q2pEbhVi5Z+wNp4e7Wwt+N43zv2Qk3QmdB4DhzWoYAv6rp+yoUpGtM5D4CHJZIXmcE10 W9oQ==
X-Gm-Message-State: ALoCoQlQ7UNIr+roKSQJPA6lzx1N1X5FgXUHmpdMjV/EqSGwYEAB0iHpJcw2lZEun+pqSLGBttRs
MIME-Version: 1.0
X-Received: by 10.52.69.172 with SMTP id f12mr767813vdu.26.1405105386936; Fri, 11 Jul 2014 12:03:06 -0700 (PDT)
Received: by 10.52.27.8 with HTTP; Fri, 11 Jul 2014 12:03:06 -0700 (PDT)
Received: by 10.52.27.8 with HTTP; Fri, 11 Jul 2014 12:03:06 -0700 (PDT)
In-Reply-To: 
References:  <53BC1D53.4080904@jitsi.org>    
Date: Fri, 11 Jul 2014 12:03:06 -0700
Message-ID: 
From: Justin Uberti 
To: Roman Shpount 
Content-Type: multipart/alternative; boundary=20cf307cffd675f87e04fdef972f
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qXhRrHLTqp9YghbNGGNpd4R4YcU
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] ICE-Mismatch and WebRTC
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 19:03:09 -0000

--20cf307cffd675f87e04fdef972f
Content-Type: text/plain; charset=UTF-8

Yes, port 0 will be understood.
No, 0.0.0.0 will not be handled.
Agree ice-mismatch should result in an error, similar to that if no ICE
info was present.
On Jul 11, 2014 1:42 PM, "Roman Shpount"  wrote:

> On Fri, Jul 11, 2014 at 12:07 PM, Justin Uberti 
> wrote:
>
>> The fact that WebRTC implementations MUST ignore the address and port in
>> the c=/m= lines will be written into JSEP, S 5.6/5.7.
>>
>>
>> Is it going to completely ignore these parameters or would it still honor
> port 0 to indicate that m line disabled?
>
> What about 0.0.0.0 address to indicate hold? These should not be allowed
> per RFC 5245 section 9.1.1.1 but I still do see it used in SIP, especially
> with various B2BUA scenarios where this is the only way for a pure
> signaling agent to put a call on hold or to resolve collision. There are
> other ways to deal with this in WebRTC but this will still come up during
> interop with SIP.
>
> Would it also document on what happens when WebRTC implementation receives
> an answer SDP with ice-mismatch attribute? An error in such case is
> probably the most appropriate action.
> _____________
> Roman Shpount
>
>

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


Yes, port 0 will be understood. 

No, 0.0.0.0 will not be handled.

Agree ice-mismatch should result in an error, similar to that if no ICE inf=
o was present.


On Jul 11, 2014 1:42 PM, "Roman Shpount&quo=
t; <roman@telurix.com> wrote=
:


On F=
ri, Jul 11, 2014 at 12:07 PM, Justin Uberti <juberti@google.com>=
 wrote:



The fact that WebRTC implementations MUST=
 ignore the address and port in the c=3D/m=3D lines will be written into JS=
EP, S 5.6/5.7.





Is it going to c=
ompletely ignore these parameters or would it still honor port 0 to indicat=
e that m line disabled?

What about 0.0.0.0 address=
 to indicate hold? These should not be allowed per RFC 5245 section 9.1.1.1=
 but I still do see it used in SIP, especially with various B2BUA scenarios=
 where this is the only way for a pure signaling agent to put a call on hol=
d or to resolve collision. There are other ways to deal with this in WebRTC=
 but this will still come up during interop with SIP.




Would it also document on what happens when WebRTC impl=
ementation receives an answer SDP with ice-mismatch attribute? An error in =
such case is probably the most appropriate action.
_____________<=
br>

Roman Shpount
=C2=A0




--20cf307cffd675f87e04fdef972f--


From nobody Fri Jul 11 12:04:05 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832151A0251 for ; Fri, 11 Jul 2014 12:04:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_111=0.6, SPF_PASS=-0.001] autolearn=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 pgQrz_n_-QsE for ; Fri, 11 Jul 2014 12:04:03 -0700 (PDT)
Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B4121A0174 for ; Fri, 11 Jul 2014 12:04:03 -0700 (PDT)
Received: by mail-wg0-f42.google.com with SMTP id l18so1490967wgh.25 for ; Fri, 11 Jul 2014 12:03:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m2/lRgs7awJOGLom9W5wwJLu1c02oa5fciw6WRS3Mi4=; b=HdfeTy2Symkq8erLviytHlF/mllVG4krTDjwPZFPezSw/c6zuoMJ5n9ZjF5a6XdjLF kfwon36Yt5YPlWwmKGNkknEKM5faQZWpqOXfhUwQdjdQDiwvs6sb+1QAp301hiQti59f 2LCqYEXJ2G+77ZmS4YAQRxFwKhbbv6UpYCPpHn5gO4Xn0x9umfW0laRMz4jJydI2evE7 no+rSVXvhkLouTD9iv0jpJlCy1u8yMmkkRAGS8NL0Oy9UsEblMX7vtwUbRVwV5Fkp7Cs Ep+NWyvrJiQ78w9bl3jkgCn8pjh01+WPKVgjDtd+tt4jjNDtki3rhECC0y27NYYPZ3XV QKwQ==
MIME-Version: 1.0
X-Received: by 10.180.187.113 with SMTP id fr17mr7126653wic.51.1405105438235;  Fri, 11 Jul 2014 12:03:58 -0700 (PDT)
Received: by 10.194.21.69 with HTTP; Fri, 11 Jul 2014 12:03:58 -0700 (PDT)
Received: by 10.194.21.69 with HTTP; Fri, 11 Jul 2014 12:03:58 -0700 (PDT)
In-Reply-To: 
References:    
Date: Fri, 11 Jul 2014 12:03:58 -0700
Message-ID: 
From: Watson Ladd 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=001a11c383b284a52d04fdef9a28
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5_fMCazGYA_3abI-u-82pQp8ZGk
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Security Architecture: IdP for RTP and RTCP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 19:04:04 -0000

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

On Jul 11, 2014 10:57 AM, "Martin Thomson"  wrote:
>
> On 11 July 2014 09:03, Justin Uberti  wrote:
> > Different m= lines can have different fingerprints, but do we expect to
> > support multiple fingerprints with the same digest algorithm on the
same m=
> > line, where the receiver then checks that the received certificate
matches
> > one of the possible fingerprints?
>
> That's what the spec says to do.  That's how Firefox currently
> operates.  It's not particularly hard to do.
>
> To be precise, it assembles all relevant a=fingerprint attributes for
> the m= section and allows the session to proceed if all sections have
> one match, using the provided hash function.  I think that we provide
> SHA-256, but support the full intersection of the textual names
> registry and what is implemented and enabled (i.e., sha1 is OK).
>

So break one hash from the set and win. Why not require all to match?

> I don't think that we require that the hash function match the
> function used in the certificate signature; that's a nonsensical
> requirement.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

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




On Jul 11, 2014 10:57 AM, "Martin Thomson" <martin.thomson@gmail.com> wrote:

>

> On 11 July 2014 09:03, Justin Uberti <juberti@google.com> wrote:

> > Different m=3D lines can have different fingerprints, but do we e=
xpect to

> > support multiple fingerprints with the same digest algorithm on t=
he same m=3D

> > line, where the receiver then checks that the received certificat=
e matches

> > one of the possible fingerprints?

>

> That's what the spec says to do. =C2=A0That's how Firefox curr=
ently

> operates. =C2=A0It's not particularly hard to do.

>

> To be precise, it assembles all relevant a=3Dfingerprint attributes fo=
r

> the m=3D section and allows the session to proceed if all sections hav=
e

> one match, using the provided hash function. =C2=A0I think that we pro=
vide

> SHA-256, but support the full intersection of the textual names

> registry and what is implemented and enabled (i.e., sha1 is OK).

>


So break one hash from the set and win. Why not require all =
to match?


> I don't think that we require that the hash functio=
n match the

> function used in the certificate signature; that's a nonsensical
> requirement.

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.i=
etf.org/mailman/listinfo/rtcweb




--001a11c383b284a52d04fdef9a28--


From nobody Fri Jul 11 12:39:41 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70BD81B2CBF for ; Fri, 11 Jul 2014 12:39:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5Vh-kbBZrZn for ; Fri, 11 Jul 2014 12:39:38 -0700 (PDT)
Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF0881B2CBC for ; Fri, 11 Jul 2014 12:39:37 -0700 (PDT)
Received: by mail-we0-f179.google.com with SMTP id p10so1309337wes.10 for ; Fri, 11 Jul 2014 12:39: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:content-type; bh=TKoTM/qtVMxhhUegVofAMwhj3hvw5PtPrnqCYM8XwdA=; b=P3c/HL1JKywuZV/EA9IUQx9AxphKjUJjpHGBi87AqPXc1iTSzF3MebOJYsSqjt+zLA cHyM7QD6fOB+efFK9hxiaOujVk+pnY4RJ38P3NT74NJAd6jjfPGunpg9WkSkrMPAhq0P C0JK/URzNGm8+dyV+3cb+RnmmTB4UWgzvgR26QDle5T3amGHO5tARhc2rb7NAr04syB+ /LhbC6iYXWJaVv9u1/9hqZvBZPhED9xMzLjFnK34OjSol0OD8Ojx0qNN7FsD+DLd1R2u di0bUFfj9rjxSqf2mS1LWT3Y15fZC1PrnNI/mT4+uACtK8CZyfm8puwm1lT/7eKfKBX2 b/oA==
MIME-Version: 1.0
X-Received: by 10.194.90.7 with SMTP id bs7mr1095332wjb.25.1405107572091; Fri, 11 Jul 2014 12:39:32 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Fri, 11 Jul 2014 12:39:31 -0700 (PDT)
In-Reply-To: 
References:     
Date: Fri, 11 Jul 2014 12:39:31 -0700
Message-ID: 
From: Martin Thomson 
To: Watson Ladd 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kal5K3eiFDtnqbREmvqeoxgSwW4
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Security Architecture: IdP for RTP and RTCP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 19:39:39 -0000

On 11 July 2014 12:03, Watson Ladd  wrote:
> So break one hash from the set and win. Why not require all to match?

That would prevent someone from ever adding a new hash function to the protocol.

http://tools.ietf.org/html/draft-thomson-mmusic-fingerprint explains a
little more, though I note that (with fresh eyes) Section 3 is pretty
damned cryptic and needs to be rewritten.


From nobody Fri Jul 11 13:23:16 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0DF1B2D21 for ; Fri, 11 Jul 2014 13:23:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level: 
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 LlXSdGzkWOBI for ; Fri, 11 Jul 2014 13:23:12 -0700 (PDT)
Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DC7F1A0406 for ; Fri, 11 Jul 2014 13:23:12 -0700 (PDT)
Received: by mail-we0-f178.google.com with SMTP id w61so683187wes.37 for ; Fri, 11 Jul 2014 13:23:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4HFDhJwgz633PGBAceLrMRvlBJjJf5dW7492T1aFPkQ=; b=iJgE2lkcX+N1s3shYIBCCohlDe3G+cB7LIKf4kAY1brVtO8NM2TSMEONE1hwKMCRxA NdVgt560l0FBbL/TwHwiPrPT04DMgjHCfgKeXRe8zvneT0QYDEp8SOhqITrZgaCU634J cgqbiVS4v5MY2ghNrHJkb/qTv/DaZRNLptUIzlMyZ5+aTkF3Li+1lwYcMJabNoYDIFV/ HdK2Xj0d3o6gejF0gp4kJp8OOIxr/DYdoT59QpEAal9K9YxxE3o2vlri8Utvh+HgDzIG 3er+RObDavI1SRS2SGYCp23vPVHVm8N+Eb59JIODiMWa6YvVrBwfx4I7LA7TL2e1+rnL qdnw==
X-Gm-Message-State: ALoCoQkR9mqVlTxwENzdwvvOCMmEQ0bJtqkQFXoQkVZngfQXClX9utdOItbRwebj+jH05vMKgn3B
X-Received: by 10.180.99.97 with SMTP id ep1mr7802581wib.64.1405110185380; Fri, 11 Jul 2014 13:23:05 -0700 (PDT)
Received: from [192.168.1.23] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id da9sm11082973wib.5.2014.07.11.13.23.04 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 13:23:04 -0700 (PDT)
Message-ID: <53C047A4.9000706@jitsi.org>
Date: Fri, 11 Jul 2014 22:23:00 +0200
From: Emil Ivov 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Justin Uberti 
References: 	<53BC1D53.4080904@jitsi.org>				<53C02268.9030109@jitsi.org> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/z_4pIalA__e7zxG0UfvcSsG9rdc
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] ICE-Mismatch and WebRTC
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 20:23:14 -0000

On 11.07.14, 20:55, Justin Uberti wrote:
> Well, it should either be MUST ignore, or MUST fail. I can go either
> way, I just want deterministic API behavior.

I'd completely agree with MUST fail.

> On Jul 11, 2014 1:44 PM, "Emil Ivov"  > wrote:
>
>     On 11.07.14, 18:07, Justin Uberti wrote:
>
>         The fact that WebRTC implementations MUST ignore the address and
>         port in
>         the c=/m= lines will be written into JSEP, S 5.6/5.7.
>
>
>     MUST sounds unnecessarily strong here. Imagine Alice's WebRTC client
>     sends offer:
>
>             ...
>             c=IN IP4 *192.168.0.1*
>             t=0 0
>             a=ice-pwd:__asd88fgpdd777uzjYhagZg
>             a=ice-ufrag:8hhY
>             a=ice-options:trickle
>             m=audio 5000 RTP/AVP 0
>             a=candidate:1 1 UDP 2130706431 *192.168.0.1* 5000 typ host
>             ...
>
>     and then Bob's browser gets
>
>             ...
>             c=IN IP4 *87.65.43.21*
>             t=0 0
>             a=ice-pwd:__asd88fgpdd777uzjYhagZg
>             a=ice-ufrag:8hhY
>             a=ice-options:trickle
>             m=audio 2626 RTP/AVP 0
>             a=candidate:1 1 UDP 2130706431 *192.168.0.1* 5000 typ host
>             ...
>
>     Don't you think Bob's browser has a pretty good reason to reject the
>     offer because chances are the call would fail anyway?
>
>     Emil
>
>
>         On Tue, Jul 8, 2014 at 1:04 PM, Emil Ivov          
>         >> wrote:
>
>              On Tue, Jul 8, 2014 at 9:04 PM, Roman Shpount
>         
>              >> wrote:
>               > On Tue, Jul 8, 2014 at 12:33 PM, Emil Ivov
>         
>              >> wrote:
>               >>
>               >> On 07.07.14, 21:48, Roman Shpount wrote:
>               >>>
>               >>> Is it possible to run into ICE-Mismatch with WebRTC?
>         Should we
>              specify
>               >>> that default candidate (c= and m= line based
>         candidate) should be
>               >>> ignored and thus mismatch check should not be performed?
>               >>
>               >>
>               >> I guess running into an ICE mismatch with WebRTC is just as
>              possible as
>               >> with any other ICE implementation. I suppose the only
>         difference
>              would be
>               >> that rather than falling back to 3264 semantics, WebRTC
>              implementations will
>               >> rather drop the session because without ICE, they
>         wouldn't be
>              able to do
>               >> consent checks for it.
>               >>
>               >
>               > My point was that WebRTC would never use 3264 semantics
>
>              Indeed. This was also my point.
>
>               > and use address from
>               > c= and m= lines for any purpose, so why does it need to
>         check
>              that this
>               > address is correct? Would it be more sensible just ignore
>              whatever value
>               > happen to be there?
>
>              With the exception of trickle ICE's use of :: (or 0.0.0.0)
>         an ICE
>              mismatch indicates that there is an entity on the
>         signalling path that
>              is overwriting c= line addresses and m= line ports. The idea of
>              dropping ICE here is that the infrastructure is likely
>         performing
>              Hosted NAT Traversal and latching so insisting on ICE is
>         likely to
>              lead to unexpected situations.
>
>               > Or, better yet end point can generate an error instead
>               > of generating a response with ice-mismatch.
>
>              Agreed. Sending an answer with ice-mismatch means
>         downgrading to basic
>              3264 and that doesn't make sense for WebRTC.
>
>              Agreed.
>
>              Emil
>
>              --
>         https://jitsi.org
>
>              _________________________________________________
>              rtcweb mailing list
>         rtcweb@ietf.org           >
>         https://www.ietf.org/mailman/__listinfo/rtcweb
>         
>
>
>
>     --
>     https://jitsi.org
>

-- 
https://jitsi.org


From nobody Fri Jul 11 14:20:54 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3901B29BB for ; Fri, 11 Jul 2014 14:20:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 LfGNpQOnHKhW for ; Fri, 11 Jul 2014 14:20:49 -0700 (PDT)
Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EBF21B29B8 for ; Fri, 11 Jul 2014 14:20:49 -0700 (PDT)
Received: by mail-qg0-f53.google.com with SMTP id i50so1471913qgf.40 for ; Fri, 11 Jul 2014 14:20:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LKBAdDNrmMiv7DHiePnZk9G2fyZ49OE4BRdi3oQbT0k=; b=Qh8xsc6leh4fAdygixD61B3eiMBHCg6ccIipoKLRPqdZjgnG3KOySnj0tXohDZ/Gyt dhipaDVst13WuAv6E1RJBplUpQWHePxlGLcU/xNtPx/66V0nkrwgTL5w515AH1E5xLLx J6iyQHBWtgN/L3SeHEUcRt8HcoCzkgDvBbWoCCEwEZab1t0IZNcdB7AscbKoALxBq1Gn +h8zs+v/dXg4DXJV94rodu3mYdm7E0aCk5qr6k+hqNyIZi/5kLaAeuepStfbNSx2O4xv +bVD3dFUJGIzvn+DSik6/cxlz+v29x9U2AGq64W2cqLRBWakHCliQfJQIxe/JVKhncO2 ZolQ==
X-Gm-Message-State: ALoCoQkVMhjwsrbxRKnpJ3MwV/TKSnB4QIFXWQuNwom6hUuFZPLCYCYB79Vqt6INb5gZQxHuRio2
X-Received: by 10.140.87.236 with SMTP id r99mr2458364qgd.43.1405113648515; Fri, 11 Jul 2014 14:20:48 -0700 (PDT)
Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by mx.google.com with ESMTPSA id b49sm3422946qgb.27.2014.07.11.14.20.46 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 14:20:46 -0700 (PDT)
Received: by mail-qa0-f49.google.com with SMTP id dc16so1342354qab.8 for ; Fri, 11 Jul 2014 14:20:46 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.85.101 with SMTP id m92mr2698706qgd.26.1405113646145; Fri, 11 Jul 2014 14:20:46 -0700 (PDT)
Received: by 10.96.210.37 with HTTP; Fri, 11 Jul 2014 14:20:46 -0700 (PDT)
In-Reply-To: <53C047A4.9000706@jitsi.org>
References:  <53BC1D53.4080904@jitsi.org>    <53C02268.9030109@jitsi.org>  <53C047A4.9000706@jitsi.org>
Date: Fri, 11 Jul 2014 17:20:46 -0400
Message-ID: 
From: Roman Shpount 
To: Emil Ivov 
Content-Type: multipart/alternative; boundary=001a11c155eabf698404fdf183dd
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DznEjat8GTYqmyhQUz4vEa6NMA0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ICE-Mismatch and WebRTC
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 21:20:51 -0000

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

I would agree with:

1. Must fail if c=/m= line IP does not match any candidate. Must also fail
if rtcp attribute does not match any RTCP candidates.

2. Must fail if "ice-mismatch" attribute is present same as no ICE

3. Port 0 in m= line to disable the line must be understood

4. c= line with 0.0.0.0 must fail

Does this make sense?
_____________
Roman Shpount

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


I would agree with:

1. Must fail if c=3D=
/m=3D line IP does not match any candidate. Must also fail if rtcp attribut=
e does not match any RTCP candidates.

2. Must fail=
 if "ice-mismatch" attribute is present same as no ICE



3. Port 0 in m=3D line to disable the line must be unde=
rstood

4. c=3D line with 0.0.0.0 must fail

Does this make =
sense?


_____________
Roman Shpount





--001a11c155eabf698404fdf183dd--


From nobody Fri Jul 11 15:06:57 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797601B29E6 for ; Fri, 11 Jul 2014 15:06:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level: 
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 qmPPOVoJBf0w for ; Fri, 11 Jul 2014 15:06:35 -0700 (PDT)
Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E79901B29D8 for ; Fri, 11 Jul 2014 15:06:17 -0700 (PDT)
Received: by mail-qa0-f48.google.com with SMTP id x12so1359049qac.21 for ; Fri, 11 Jul 2014 15:06:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=x6SHmTnyqZsNg6fPB9I3XPNBYNYMhdaUoMhRs+/eNnM=; b=KzFrrRcfKjSGHqnaiXQHzKGFPO1Ml1BIS/exjqsKN5ZR2AKLh5K8LGBz2NbkJb0ZO7 ZwrBwOZLz50DfuUO9TGtILQR2hdq5/kxwfZat8zIpVCs/d0mKZT1tozzEJkokavWf7F4 CICCEPPwK2OCZMTqdAbVSpSRuDZsil7H4N499GkmSm3C1Dh+XcE42t4mAwkVD4Gb1YVu 0C1QOUTjwL3+zr7bVMNiTHxqUGXPJlb8wI/e9d5mvfa1tSxMuOXrpI3jpQAiZUxn1oGp 4G5vBHqZXYONl/ZGxYg5vxa0HsnhecyGxVnKp3u/ydrbLm4jHNsFJBoLVpUBN7LswlLa 8i+g==
X-Gm-Message-State: ALoCoQl4jWcZGeRlyosTsMKRZZAc28ijxlDhAjTZCAT2Gg/b2tsxlMY5+dqRFA2MNNyLB3PbpQ99
MIME-Version: 1.0
X-Received: by 10.224.126.66 with SMTP id b2mr156296qas.99.1405116377154; Fri, 11 Jul 2014 15:06:17 -0700 (PDT)
Received: by 10.96.234.161 with HTTP; Fri, 11 Jul 2014 15:06:16 -0700 (PDT)
Received: by 10.96.234.161 with HTTP; Fri, 11 Jul 2014 15:06:16 -0700 (PDT)
In-Reply-To: 
References:          
Date: Sat, 12 Jul 2014 00:06:16 +0200
Message-ID: 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
To: Justin Uberti 
Content-Type: multipart/alternative; boundary=001a11c2f98e875c3c04fdf226a3
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hHUajHENAQVb7_IGAjWdIkd0ow8
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Question about ICE-Lite server
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 22:06:36 -0000

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

Agreed. Imagine a future RFC defining
a=3Dice-option:no-regular-nomitation-support so Chrome does not understand =
it
and thus... uses regular nomination...

--
I=C3=B1aki Baz Castillo

On Jul 11, 2014 8:43 PM, "Justin Uberti"  wrote:

> Chrome doesn't do that. I think that behavior is harmful and is going to
> be changed in ice-bis.
> On Jul 11, 2014 1:26 PM, "Roman Shpount"  wrote:
>
>> On Fri, Jul 11, 2014 at 12:33 PM, Justin Uberti 
>> wrote:
>>
>>> Yes, Chrome always uses aggressive nomination unless ICE Lite is used.
>>>
>>>
>> What about the cases when it sees unknown "ice-options" attribute? This
>> should make Chrome use regular nomination as well.
>> _____________
>> Roman Shpount
>>
>>
>

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


Agreed. Imagine a future RFC defining a=3Dice-option:no-regu=
lar-nomitation-support so Chrome does not understand it and thus... uses re=
gular nomination...


--

I=C3=B1aki Baz Castillo

<ibc@aliax.net>


On Jul 11, 2014 8:43 PM, "Justin Uberti&quo=
t; <juberti@google.com> wro=
te:


Chrome doesn't do that. I think that behavior is harmful=
 and is going to be changed in ice-bis.


On Jul 11, 2014 1:26 PM, "Roman Shpount&quo=
t; <roman@telurix=
.com> wrote:



On F=
ri, Jul 11, 2014 at 12:33 PM, Justin Uberti <juberti@google.com>=
 wrote:




Yes, Chrome always uses aggressive nomina=
tion unless ICE Lite is used.






What about the cases when it sees unknown "ice-option=
s" attribute? This should make Chrome use regular nomination as well.<=
/div>



_____________
Roman Shpount
=C2=A0






--001a11c2f98e875c3c04fdf226a3--


From nobody Fri Jul 11 20:17:33 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7EA1A03A0 for ; Fri, 11 Jul 2014 20:17:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KoNp6ZTTJEH for ; Fri, 11 Jul 2014 20:17:30 -0700 (PDT)
Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC2DA1A01BE for ; Fri, 11 Jul 2014 20:17:29 -0700 (PDT)
Received: by mail-we0-f180.google.com with SMTP id k48so943613wev.11 for ; Fri, 11 Jul 2014 20:17:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8SeEyM2HDcINghVRazltqKiORVYAaQ4NQd8u4WQtb/o=; b=UiPIDsWmnp+VojJJMajPCBCb52JmSys3cf3FvpS6aiRUBFFelVK/NyIxk9tA2VoPn1 MPwdQjz8qxrOChQLRwKrz1J9CwCUspn72OGOContiTYCL2pBuCd5J96rHJXun5YOrn5w vO+Ns7WGnfBoF10s8VYJtrsiPd9GeIJ49ebNLw4Z8yDTRnmrfmCbh54LPJFvQVGQ6Oi/ fntOwCYbngcJzNzsttw4M8lFr1hIqlzqTGReu+5PWIZ9PZ/Jxc+Ws5+II6+Osmwe72eP YlkHOxAbuTcNYphMyVpDdfXlOKbE2MT3KRUr9ohHHd/0SuuVcYt/3rorgVTUUNCDMqoD kOUQ==
MIME-Version: 1.0
X-Received: by 10.194.219.70 with SMTP id pm6mr3637122wjc.53.1405135048361; Fri, 11 Jul 2014 20:17:28 -0700 (PDT)
Received: by 10.194.21.69 with HTTP; Fri, 11 Jul 2014 20:17:28 -0700 (PDT)
In-Reply-To: 
References:      
Date: Fri, 11 Jul 2014 20:17:28 -0700
Message-ID: 
From: Watson Ladd 
To: Martin Thomson 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2i3jUB91JBEf1G0KecDyW-1AfzM
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Security Architecture: IdP for RTP and RTCP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 12 Jul 2014 03:17:32 -0000

On Fri, Jul 11, 2014 at 12:39 PM, Martin Thomson
 wrote:
> On 11 July 2014 12:03, Watson Ladd  wrote:
>> So break one hash from the set and win. Why not require all to match?
>
> That would prevent someone from ever adding a new hash function to the protocol.
>
> http://tools.ietf.org/html/draft-thomson-mmusic-fingerprint explains a
> little more, though I note that (with fresh eyes) Section 3 is pretty
> damned cryptic and needs to be rewritten.
Ah, the spec does say all must match if present. Relevant sentence
from 2 " An endpoint that validates
a session using  fingerprint attributes MUST report failure if any
hash that it checks
doesn't match."

Sincerely,
Watson Ladd


-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin


From nobody Fri Jul 11 20:43:24 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4B91B281A for ; Fri, 11 Jul 2014 20:43:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjcKvQdbQJi7 for ; Fri, 11 Jul 2014 20:43:21 -0700 (PDT)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 071251B2879 for ; Fri, 11 Jul 2014 20:43:19 -0700 (PDT)
Received: by mail-wg0-f51.google.com with SMTP id y10so1864898wgg.34 for ; Fri, 11 Jul 2014 20:43:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=S9IzJMREG+Fr8eZd4JGwuxJqHcJvqwapvVyiSKsplhk=; b=OpKLP5e/iOZnHidLBN/q1cCNx7Rb7LoTYfrr0CtjBBN63OwlO1Clf3a8ppQJnIRULm 6mCkBAoEfN/YVMuim299MnjU2NU4UwTq95Y1pyw6htCkCAFRmqD5K0epzokkrldDm2MQ GNiGXUxy8pFlyyJ67VOHLEwgUACu0yFRic12N+7+FDfQEmfg2yZEFULRyuxNzE/kllHM WjZ6KVs2YrXz00k/a0amFfg3c1sMbSYtOGNnDzZS2RxU4GQAtb3RF2mWEC9wPUoNUXGK ZpOETBfWuQiTZ8xYCerktDwTtqAMgtJws+Op4dB8Gm9njhrpjkKpiWA64/3dn3ycs/2o rn1w==
MIME-Version: 1.0
X-Received: by 10.194.91.228 with SMTP id ch4mr3809628wjb.59.1405136598623; Fri, 11 Jul 2014 20:43:18 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Fri, 11 Jul 2014 20:43:18 -0700 (PDT)
In-Reply-To: 
References:       
Date: Fri, 11 Jul 2014 20:43:18 -0700
Message-ID: 
From: Martin Thomson 
To: Watson Ladd 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/t7MYZCr9UpP8kWxRAxUtRs0C404
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Security Architecture: IdP for RTP and RTCP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 12 Jul 2014 03:43:23 -0000

On 11 July 2014 20:17, Watson Ladd  wrote:
> On Fri, Jul 11, 2014 at 12:39 PM, Martin Thomson
>  wrote:
>> On 11 July 2014 12:03, Watson Ladd  wrote:
>>> So break one hash from the set and win. Why not require all to match?
>>
>> That would prevent someone from ever adding a new hash function to the protocol.
>>
>> http://tools.ietf.org/html/draft-thomson-mmusic-fingerprint explains a
>> little more, though I note that (with fresh eyes) Section 3 is pretty
>> damned cryptic and needs to be rewritten.
> Ah, the spec does say all must match if present. Relevant sentence
> from 2 " An endpoint that validates
> a session using  fingerprint attributes MUST report failure if any
> hash that it checks
> doesn't match."

That's only a proposed update to the spec we're talking about: rfc
4572 (section 5)


From nobody Sat Jul 12 08:28:16 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA4A1B2B0F for ; Sat, 12 Jul 2014 08:28:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level: 
X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qg0XwC7lGBiJ for ; Sat, 12 Jul 2014 08:28:13 -0700 (PDT)
Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F20D51B2914 for ; Sat, 12 Jul 2014 08:28:12 -0700 (PDT)
Received: by mail-vc0-f175.google.com with SMTP id hy4so4349536vcb.34 for ; Sat, 12 Jul 2014 08:28:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4Wdt/r4TBCC4uOJjOq2Q7r86yTs5aClfNwtJUo+qcpw=; b=NeYTiAR7+7XG3EMmQyyawWrweqOfiXBJCGS/5WflI3ifdPc+fE4xhH2YkC3VjQ0w0w jNtZPe8D2POjHqELuQSJtCylM407c8Xx56Ai5VFGY1hETBomaVuhaBxl/S7oGusEx9TG 1hiOGJ97YnCIwXDI0NM8XzFQH1OpiOwmgNMHM3xsEqWgsfYyFyhTknVOpYp8K5ovvWB4 Wl/uz86ESnCkybhCZa1TAUesW5P5OM7YsMCDWgPQ9h+XVsat44ZIIaAZrdM84Jr7tPKo 4kllYPxc4z5TzrrExISo25MU+EZxJRwYJCq+lulbQSHpNQy0b3Us99+gtkwA2GrCSnXn MgsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4Wdt/r4TBCC4uOJjOq2Q7r86yTs5aClfNwtJUo+qcpw=; b=AM2oySlr8i4YNM52B004rNCtp2t6KDRhXmFAEYzJ5tJPOV5RAt/OI0EpCGR4jICWUp 69HerT8rtUZ+h2HIug2iGUiubmH65VPryK3CN+esLqzVD7uYjx4hgG6vlBDsWSFSJodw N6fcHsdPt8voFAes4Pjz+Ff0iUC6Sfu6mSRXqwvEFbiRAp4Q7ynPhCCVt+4dnfy3g1dO JEYb6qjjTISCNVORQ3wnTbGxDUZTf6OKdNYhyZut8EzadLovoIum6MCetC/O+rme0IPm joPmtPL3u3rz6FUaA5biczNljDtT/2ksXn0378r4gQF6u9kd+YVYNO77qJCc/VVtKTBO RJ+g==
X-Gm-Message-State: ALoCoQkZxQndLN3j9MtlgmtECR0yn6UGOcQ+lpAdjSIZqDisMBRFpbEGuan84atV0ZB3Jw1Kfpzy
MIME-Version: 1.0
X-Received: by 10.58.212.66 with SMTP id ni2mr5952324vec.12.1405178891813; Sat, 12 Jul 2014 08:28:11 -0700 (PDT)
Received: by 10.52.27.8 with HTTP; Sat, 12 Jul 2014 08:28:10 -0700 (PDT)
Received: by 10.52.27.8 with HTTP; Sat, 12 Jul 2014 08:28:10 -0700 (PDT)
In-Reply-To: 
References:  <53BC1D53.4080904@jitsi.org>    <53C02268.9030109@jitsi.org>  <53C047A4.9000706@jitsi.org> 
Date: Sat, 12 Jul 2014 08:28:10 -0700
Message-ID: 
From: Justin Uberti 
To: Roman Shpount 
Content-Type: multipart/alternative; boundary=047d7bd6c0a2b162f204fe00b4c9
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/UQr4-qM-qZrsCL-qVTwz5y6yO4k
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] ICE-Mismatch and WebRTC
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 12 Jul 2014 15:28:14 -0000

--047d7bd6c0a2b162f204fe00b4c9
Content-Type: text/plain; charset=UTF-8

Agreed, with a special case for the no-candidates trickle ICE situation.
On Jul 11, 2014 5:20 PM, "Roman Shpount"  wrote:

> I would agree with:
>
> 1. Must fail if c=/m= line IP does not match any candidate. Must also fail
> if rtcp attribute does not match any RTCP candidates.
>
> 2. Must fail if "ice-mismatch" attribute is present same as no ICE
>
> 3. Port 0 in m= line to disable the line must be understood
>
> 4. c= line with 0.0.0.0 must fail
>
> Does this make sense?
> _____________
> Roman Shpount
>
>
>

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


Agreed, with a special case for the no-candidates trickle IC=
E situation.


On Jul 11, 2014 5:20 PM, "Roman Shpount&quo=
t; <roman@telurix.com> wrote=
:


I would agree with:

1. Must fail if c=3D=
/m=3D line IP does not match any candidate. Must also fail if rtcp attribut=
e does not match any RTCP candidates.

2. Must fail=
 if "ice-mismatch" attribute is present same as no ICE




3. Port 0 in m=3D line to disable the line must be unde=
rstood

4. c=3D line with 0.0.0.0 must fail

Does this make =
sense?



_____________
Roman Shpount







--047d7bd6c0a2b162f204fe00b4c9--


From nobody Sun Jul 13 19:21:33 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58491A026A for ; Sun, 13 Jul 2014 19:21:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level: 
X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xxn4NW01iKSk for ; Sun, 13 Jul 2014 19:21:28 -0700 (PDT)
Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40BD11A0267 for ; Sun, 13 Jul 2014 19:21:28 -0700 (PDT)
Received: by mail-vc0-f175.google.com with SMTP id hu12so917854vcb.20 for ; Sun, 13 Jul 2014 19:21:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Bmp5WjrA6JcKWWYGRfgI4sah17aofAmMAYDGgg+BPbM=; b=Lz/uR0qKnTuPx6UwgWL16ffvc6k0ZvHEOnwJkrXGv7MioKl6PP0onJMdcz5xv95Mo2 BdP9z4BvQCzJ4ByFXAO5SwS3QJqqKET7JXCiP4MQvjoXv/P5Cj7WNYjPEokcvxx+EpkH 5iZxsKDwoQ9wgTmjf7i11zJxbjO992tPKQwCKWj6G2gzzZhx37BMZOUHZhbvDPqt2jJ0 NmtZOqP4iG0sZjnvzXwmIh0jueY1Nz/jwLuyElqryDbT42QZnIeUTGEhPFyH7tqvIZEB ewMFOWRpWJ6bR6+olXAoSNYTw10jQP5ESaMRV30u7iApCuiQ2DFLT9MpeMHF0CXzlDiL knhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=Bmp5WjrA6JcKWWYGRfgI4sah17aofAmMAYDGgg+BPbM=; b=j7HLulSGgdRhDd3pNlgxYSQZdqLCekOEZu7IVtawQBmcW5lvYqDVZw3jrc7pA8ZJ/y LdMRW/RgtOS2E870HnwRtbbYnSWJ78h61Kr3vezPa5lDVv9odTRRadHZlYyk/ZbCVBdj R5YpbyTlbFXcvetZQwtyFAYa2lsttD2dPvbfZ+X7OtyDrc4iXCeBfERfTtqpsjJFditu zi+OfWrMs63VM7TED+4bV84lKhAKNfqpqCz9veyGfwJiJtxwTw+L55GQK5NfrBeKAn+q 0vhwr17YKVGHjJ90jo+gXIckw36uCyCWQCB3qfJtoKgxX22czq9tFfMUop8aP22H2X2q Ecug==
X-Gm-Message-State: ALoCoQkFVh2KwzNr2fkoswdPkbN65dftZan8yx+ADxrSBmLFl+fSOvqF62jsGfVlgC4dxN9yH4bG
X-Received: by 10.220.92.135 with SMTP id r7mr13426436vcm.11.1405304486976; Sun, 13 Jul 2014 19:21:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.27.8 with HTTP; Sun, 13 Jul 2014 19:21:06 -0700 (PDT)
From: Justin Uberti 
Date: Sun, 13 Jul 2014 19:21:06 -0700
Message-ID: 
To: "rtcweb@ietf.org" , martin.ekblom@icewarp.com
Content-Type: multipart/alternative; boundary=047d7b66f5fbbf7d6504fe1df203
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wnNW1Wx-wlhqfCzFL3tQtuMzHGQ
Subject: [rtcweb] About the current JSEP-06 draft
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 14 Jul 2014 02:21:30 -0000

--047d7b66f5fbbf7d6504fe1df203
Content-Type: text/plain; charset=UTF-8

Adding rtcweb@ietf.org, the right mailing list for this.

This behavior (of OfferToReceiveAudio/Video) was added to be conformant
with Unified Plan, where each media stream requires its own m= line, and
therefore the offerer needs the ability to advertise additional m= lines if
it needs to receive more media streams than it is offering.

I agree that the w3c spec's handling of this topic could be clarified.

On Wed, Jul 2, 2014 at 2:37 AM, Martin Ekblom 
wrote:

> Hi,
>
> I believe there is a conceptual misunderstanding in section 5.2.3.1. and
> 5.2.3.2. It seems to contradict the requirements of RFC 3264 / 4566 (SDP
> offers and answers) and not be in line with the WebRTC draft. I would like
> to contribute to improve  or clarify this section, or in case I'm mistaken
> confirm this.
>
> Is this the appropriate mailing list to disuss this?
>
> Regards,
> Martin Ekblom
> Front-end Developer
> www.icewarp.com
>
>
>

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


Adding rtcweb@ietf.org, the right mailing list for this.


This behavior (of OfferToReceiveAudio/Video) was added to be conformant wit=
h Unified Plan, where each media stream requires its own m=3D line, and the=
refore the offerer needs the ability to advertise additional m=3D lines if =
it needs to receive more media streams than it is offering.







I agree that the w3c spec's handling of this topic =
could be clarified.

On Wed, Jul 2, 2014 at 2:37 AM, Martin Ekblom <martin.ekblom@icewarp.com> wrote:






Hi,



I believe there is a conceptual misunderstanding in section 5.2.3.1. and 5.=
2.3.2. It seems to contradict the requirements of RFC 3264 / 4566 (SDP offe=
rs and answers) and not be in line with the WebRTC draft. I would like to c=
ontribute to improve=C2=A0 or clarify this section, or in case I'm mist=
aken confirm this.








Is this the appropriate mailing list to disuss this?



Regards,

Martin Ekblom

Front-end Developer

www.icewarp.com














--047d7b66f5fbbf7d6504fe1df203--


From nobody Mon Jul 14 01:06:52 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453621A0351 for ; Mon, 14 Jul 2014 01:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 uwSOYurTS82p for ; Mon, 14 Jul 2014 01:06:49 -0700 (PDT)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 046AC1A0350 for ; Mon, 14 Jul 2014 01:06:48 -0700 (PDT)
Received: by mail-la0-f52.google.com with SMTP id e16so1052836lan.39 for ; Mon, 14 Jul 2014 01:06:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PffRan+6DlBHldKgG/w/OgEGMMlr8jyHIfL+Twjp43c=; b=hC2e4yE0TQurnF2DyiTi3sImmgTone5a7TuVw95IUKJzLN+tlGpNkSUXZ45yMiI17/ Z09ZSSmF8ZThloG1FFvq+7vdoZUZE4NXiYvHikc3p7+5Fh0EU1Pl+tmnrqmW5E4e+x4x tkXDNhEab3xlx8XxOipC6j3E1oDVAphS1pikfK/grRM4ztNmDsaTxm1vJ+BYl01TDPJO 9pMqzN8AgK2+EQ6LFMn/OcuTvwO1uDBDbFUmbOe6rETqANOreHaSJHD+mkSP1urFgXu+ JbC/Eyrzr1vQUFIyhQCSATrBQuKA2hJewKWclc7AngZ0iBp2h7xwkwrsKFlyUbU0dYUz 2mlw==
MIME-Version: 1.0
X-Received: by 10.152.37.194 with SMTP id a2mr13055153lak.29.1405325207345; Mon, 14 Jul 2014 01:06:47 -0700 (PDT)
Received: by 10.114.167.9 with HTTP; Mon, 14 Jul 2014 01:06:47 -0700 (PDT)
In-Reply-To: 
References:  <53BC1D53.4080904@jitsi.org>    <53C02268.9030109@jitsi.org>  <53C047A4.9000706@jitsi.org>  
Date: Mon, 14 Jul 2014 09:06:47 +0100
Message-ID: 
From: Kevin Dempsey 
To: Justin Uberti 
Content-Type: multipart/alternative; boundary=089e013d1656c71eec04fe22c54d
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/FvS2O-hMZpktESPqGd-_caLOzwM
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] ICE-Mismatch and WebRTC
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 14 Jul 2014 08:06:50 -0000

--089e013d1656c71eec04fe22c54d
Content-Type: text/plain; charset=UTF-8

In Emil's example, Bob might later receive a trickled candidate:
a=candidate:1 1 UDP 1130706431 *87.65.43.21* 5000 typ srflx raddr
192.168.0.1 rport 5000
which, if it was in the initial offer, would mean there was no mismatch.


On 12 July 2014 16:28, Justin Uberti  wrote:

> Agreed, with a special case for the no-candidates trickle ICE situation.
> On Jul 11, 2014 5:20 PM, "Roman Shpount"  wrote:
>
>> I would agree with:
>>
>> 1. Must fail if c=/m= line IP does not match any candidate. Must also
>> fail if rtcp attribute does not match any RTCP candidates.
>>
>> 2. Must fail if "ice-mismatch" attribute is present same as no ICE
>>
>> 3. Port 0 in m= line to disable the line must be understood
>>
>> 4. c= line with 0.0.0.0 must fail
>>
>> Does this make sense?
>> _____________
>> Roman Shpount
>>
>>
>>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

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


In Emil's example, Bob might later receive a trickled =
candidate:
=
a=3Dcandidate:1 1 UDP 1130706431 *87.65.43.21* 5000 typ srflx raddr 192.168=
.0.1 rport 5000


whic=
h, if it was in the initial offer, would mean there was no mismatch.=



O=
n 12 July 2014 16:28, Justin Uberti <juberti@google.com> wr=
ote:


Agreed, with a special case f=
or the no-candidates trickle ICE situation.



On Jul 11, 2014 5:20 PM, "Roman Shpount&quo=
t; <roman@telurix=
.com> wrote:



I would agree with:

1. Must fail if c=3D=
/m=3D line IP does not match any candidate. Must also fail if rtcp attribut=
e does not match any RTCP candidates.

2. Must fail=
 if "ice-mismatch" attribute is present same as no ICE





3. Port 0 in m=3D line to disable the line must be unde=
rstood

4. c=3D line with 0.0.0.0 must fail

Does this make =
sense?




_____________
Roman Shpount








_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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





--089e013d1656c71eec04fe22c54d--


From nobody Mon Jul 14 01:57:23 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0601A001E for ; Mon, 14 Jul 2014 01:57:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyMS89tjEDbO for ; Mon, 14 Jul 2014 01:57:20 -0700 (PDT)
Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BCBB1A000A for ; Mon, 14 Jul 2014 01:57:20 -0700 (PDT)
Received: by mail-vc0-f177.google.com with SMTP id ij19so6508201vcb.22 for ; Mon, 14 Jul 2014 01:57:19 -0700 (PDT)
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:content-type; bh=cNJ61XAIDj1AkY1BoXlYgXsf0jYAeYlxHZpbbkz0iYc=; b=JrjGnym2EpPqgV3nBJT/oaXsRA+NQrHPsAJf9pf77ihpGyUF+/mOeIxRfVqodhn4xk 7D+54yQWSLFtcKRcZhzpJwzRZNNA7V5ATp17fttoVESAxMwZFQvMLvjqpinMqENBE9qn hLpOslSoej1a8e2A1zaq/JPWfc/v5xnn4v3KKKNNgyBAD08WZQ7vRi3gOYOO4TqNt9uM NSBaxEUehFWjn40d63gLT7gBycCzDAVNooQK1bUBMNzqNLlSOpOsMFNxo5xeb+rJia82 xZH4XFosnz8YA44GgpuHWCgXHhjrYlYhWU8cqX1x8oxKPIjSYmwLBnwyuwQuJ2utPAbZ VFjQ==
X-Gm-Message-State: ALoCoQkLqKZpzRPK8MxnhSV0/sU5JKIWh3pbHj7uO7bG4JmN3eAcwP5eIme2RD1GDQvXcb00aAhL
X-Received: by 10.220.103.141 with SMTP id k13mr1985498vco.25.1405328239185; Mon, 14 Jul 2014 01:57:19 -0700 (PDT)
Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by mx.google.com with ESMTPSA id qf7sm18617728vdb.4.2014.07.14.01.57.18 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jul 2014 01:57:18 -0700 (PDT)
Received: by mail-vc0-f170.google.com with SMTP id lf12so2771083vcb.15 for ; Mon, 14 Jul 2014 01:57:18 -0700 (PDT)
X-Received: by 10.220.17.199 with SMTP id t7mr15272676vca.1.1405328238772; Mon, 14 Jul 2014 01:57:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.238.75 with HTTP; Mon, 14 Jul 2014 01:56:58 -0700 (PDT)
In-Reply-To: 
References:  <53BC1D53.4080904@jitsi.org>    <53C02268.9030109@jitsi.org>  <53C047A4.9000706@jitsi.org>   
From: Emil Ivov 
Date: Mon, 14 Jul 2014 10:56:58 +0200
Message-ID: 
To: Kevin Dempsey 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3BLof05Vf0EVR63pO2QQa0nZm7Q
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ICE-Mismatch and WebRTC
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 14 Jul 2014 08:57:22 -0000

On Mon, Jul 14, 2014 at 10:06 AM, Kevin Dempsey
 wrote:
> In Emil's example, Bob might later receive a trickled candidate:
> a=candidate:1 1 UDP 1130706431 *87.65.43.21* 5000 typ srflx raddr
> 192.168.0.1 rport 5000
> which, if it was in the initial offer, would mean there was no mismatch.

How would that happen?

If you are thinking of a trickle ICE capable middle box then it
could/should simply do it all at once. What reason would it have to
delay the extra candidate?

Emil

>
> On 12 July 2014 16:28, Justin Uberti  wrote:
>>
>> Agreed, with a special case for the no-candidates trickle ICE situation.
>>
>> On Jul 11, 2014 5:20 PM, "Roman Shpount"  wrote:
>>>
>>> I would agree with:
>>>
>>> 1. Must fail if c=/m= line IP does not match any candidate. Must also
>>> fail if rtcp attribute does not match any RTCP candidates.
>>>
>>> 2. Must fail if "ice-mismatch" attribute is present same as no ICE
>>>
>>> 3. Port 0 in m= line to disable the line must be understood
>>>
>>> 4. c= line with 0.0.0.0 must fail
>>>
>>> Does this make sense?
>>> _____________
>>> Roman Shpount
>>>
>>>
>>
>> _______________________________________________
>> 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
>



-- 
https://jitsi.org


From nobody Mon Jul 14 02:10:16 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2664C1A00AD for ; Mon, 14 Jul 2014 02:10:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 ojGb-mS1nvx1 for ; Mon, 14 Jul 2014 02:10:13 -0700 (PDT)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 898A91A0051 for ; Mon, 14 Jul 2014 02:10:13 -0700 (PDT)
Received: by mail-lb0-f174.google.com with SMTP id u10so2607368lbd.19 for ; Mon, 14 Jul 2014 02:10:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ovHb/RR+078tglaBADe2DTqIuRNdPwUtHRExZ963qhk=; b=vjq9J7abQCRDy6ECMkS9KfVNXm9+Yom47yYeT+4RQGrBPR8PCkrzx/heXhTmt6Ol7w m5AjMDwyjQNIrcph/++7fculPh8f8/UTr1XHWPWdzdn//GdLAehH+j7TKI5KXlnrp6kI w+sZQUmA1iIT8lqEEg0EbkWRLpX5Ttbva6rZFV5z8n+mBMkk6uNjnzDcmEa5zIzxloKt YWloI4nA7hfdwajbb8vUx1BRUDPYhIpqaWhwdTgsikMKCdtCc9KeGWDH6J3zieFTV2LF H9WfZxH4FKpIYxqftFwMgxVf19e1Pig3sPtuQdeZ/Gphr0U3ZytLaa99Yg7x394PIsLu o5AQ==
MIME-Version: 1.0
X-Received: by 10.112.170.10 with SMTP id ai10mr410690lbc.93.1405329011765; Mon, 14 Jul 2014 02:10:11 -0700 (PDT)
Received: by 10.114.167.9 with HTTP; Mon, 14 Jul 2014 02:10:11 -0700 (PDT)
In-Reply-To: 
References:  <53BC1D53.4080904@jitsi.org>    <53C02268.9030109@jitsi.org>  <53C047A4.9000706@jitsi.org>    
Date: Mon, 14 Jul 2014 10:10:11 +0100
Message-ID: 
From: Kevin Dempsey 
To: Emil Ivov 
Content-Type: multipart/alternative; boundary=001a11c25f3c89f76604fe23a822
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rI2NOoLjtSwPAoi4UDxp0KxkoXo
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] ICE-Mismatch and WebRTC
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 14 Jul 2014 09:10:15 -0000

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

The initial offer is sent with only host candidates and the c= line gets
mangled by Alice's gateway* to match her external IP. Alice's client then
'discovers' the external address using STUN and sends the srflx candidate
which happens to match the mangled c= line.

*an application gateway that claims to be 'SIP aware' and modifies the SDP
to match the externally visible IP address. I suppose it may also modify
the candidate line if it does a simple match/replace.


On 14 July 2014 09:56, Emil Ivov  wrote:

> On Mon, Jul 14, 2014 at 10:06 AM, Kevin Dempsey
>  wrote:
> > In Emil's example, Bob might later receive a trickled candidate:
> > a=candidate:1 1 UDP 1130706431 *87.65.43.21* 5000 typ srflx raddr
> > 192.168.0.1 rport 5000
> > which, if it was in the initial offer, would mean there was no mismatch.
>
> How would that happen?
>
> If you are thinking of a trickle ICE capable middle box then it
> could/should simply do it all at once. What reason would it have to
> delay the extra candidate?
>
> Emil
>
> >
> > On 12 July 2014 16:28, Justin Uberti  wrote:
> >>
> >> Agreed, with a special case for the no-candidates trickle ICE situation.
> >>
> >> On Jul 11, 2014 5:20 PM, "Roman Shpount"  wrote:
> >>>
> >>> I would agree with:
> >>>
> >>> 1. Must fail if c=/m= line IP does not match any candidate. Must also
> >>> fail if rtcp attribute does not match any RTCP candidates.
> >>>
> >>> 2. Must fail if "ice-mismatch" attribute is present same as no ICE
> >>>
> >>> 3. Port 0 in m= line to disable the line must be understood
> >>>
> >>> 4. c= line with 0.0.0.0 must fail
> >>>
> >>> Does this make sense?
> >>> _____________
> >>> Roman Shpount
> >>>
> >>>
> >>
> >> _______________________________________________
> >> 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
> >
>
>
>
> --
> https://jitsi.org
>

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


The initial offer is sent with only host candidates and th=
e c=3D line gets mangled by Alice's gateway* to match her external IP. =
Alice's client then 'discovers' the external address using STUN=
 and sends the srflx candidate which happens to match the mangled c=3D line=
.


*an application gateway that claims to be 'SIP aware'=
; and modifies the SDP to match the externally visible IP address. I suppos=
e it may also modify the candidate line if it does a simple match/replace.<=
/div>



On 14 J=
uly 2014 09:56, Emil Ivov <emcho@jitsi.org> wrote:


On Mon, Jul 14, 2014 at 10:06 AM, Kevin Dempsey

<kevindempsey70@gmail.com> wrote:

> In Emil's example, Bob might later receive a trickled candidate:
> a=3Dcandidate:1 1 UDP 1130706431 *87.65.43.21* 5000 typ srflx raddr
> 192.168.0.1 rport 5000

> which, if it was in the initial offer, would mean there was no mismatc=
h.




How would that happen?



If you are thinking of a trickle ICE capable middle box then it

could/should simply do it all at once. What reason would it have to

delay the extra candidate?



Emil




>

> On 12 July 2014 16:28, Justin Uberti <juberti@google.com> wrote:

>>

>> Agreed, with a special case for the no-candidates trickle ICE situ=
ation.

>>

>> On Jul 11, 2014 5:20 PM, "Roman Shpount" <roman@telurix.com> wrote:

>>>

>>> I would agree with:

>>>

>>> 1. Must fail if c=3D/m=3D line IP does not match any candidate=
. Must also

>>> fail if rtcp attribute does not match any RTCP candidates.

>>>

>>> 2. Must fail if "ice-mismatch" attribute is present =
same as no ICE

>>>

>>> 3. Port 0 in m=3D line to disable the line must be understood<=
br>
>>>

>>> 4. c=3D line with 0.0.0.0 must fail

>>>

>>> Does this make sense?

>>> _____________

>>> Roman Shpount

>>>

>>>

>>

>> _______________________________________________

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

>








--

https://jitsi.org





--001a11c25f3c89f76604fe23a822--


From nobody Mon Jul 14 12:36:48 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB28B1A00C0 for ; Mon, 14 Jul 2014 12:36:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlR1ZdKjb9gY for ; Mon, 14 Jul 2014 12:36:44 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 174BC1A009C for ; Mon, 14 Jul 2014 12:36:43 -0700 (PDT)
Received: by mail-wi0-f177.google.com with SMTP id ho1so3136526wib.4 for ; Mon, 14 Jul 2014 12:36:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to:content-type; bh=hl82h+gb+GXbP0bObP9WEv6p1u10r8qq5AFlGBTSS7Q=; b=Acez8PmYvHhUmlgK32YkNm9IL21qs6uUgPijFZEzZ1xnvjyTe9Zkgb9eRZBaKso/GV c8CjevPxDzwkSpCbZWxGK1LHZFCxf2CVM7sEluF6vPSGxKGyCuEzrsOc0tPUC+zb4H0A S5B0cyi97PutOiRu+z9SPcbc6FvC9Lec+VXgByVvIpFnHKAcyiW86DSycAdrE4cGGcIs HMynbZA5uKhM5Iv3VZyN8/3Q+2hwn0ceToAsRVLM4kl4b+nMxgEc7k0Iwn0mT9QP+a4Z vpCSiNSQmwsaf2eBYRFe/2IGcFIzNtFKnmjfjE9+7E0F5bPMgd7dMlP170bG+dzX5pqP eQOA==
X-Received: by 10.194.60.240 with SMTP id k16mr22241935wjr.0.1405366602626; Mon, 14 Jul 2014 12:36:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.217.122.65 with HTTP; Mon, 14 Jul 2014 12:36:22 -0700 (PDT)
From: Bernard Aboba 
Date: Mon, 14 Jul 2014 12:36:22 -0700
Message-ID: 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7bacc1e420fdd204fe2c69b2
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cT1bP56a5Ef5LN7ntYHadoSWHhI
Subject: [rtcweb] Review of draft-ietf-rtcweb-security
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 14 Jul 2014 19:36:46 -0000

--047d7bacc1e420fdd204fe2c69b2
Content-Type: text/plain; charset=UTF-8

Section 4.1

   By contrast, consent to send network traffic is about preventing the

   user's browser from being used to attack its local network.


[BA] Not sure why the threat is limited to the browsers local network.

DDOS attacks against hosts on other networks are possible too, right?


   At minimum, then, it MUST NOT be possible for arbitrary sites

   to initiate calls to arbitrary locations without user consent....


   Thus, we

   need to ensure communications consent even if the site is not able to

   access the camera and microphone at all


[BA] Do the terms "user consent" and "communications consent" have different

meanings here?  For example, the former tends to suggest the need for

user intervention, while the latter might be satisfied by ICE consent.

As it stands in this section, I'm not sure what the requirement is,

exactly, although it seems important enough to merit a MUST NOT.


Section 4.1.1


   Unfortunately,

   the security implications of this functionality are much harder for

   users to intuitively analyze than for camera and microphone access.

   (See

   http://lists.w3.org/Archives/Public/public-webrtc/2013Mar/0024.html

   for a full analysis.)


[BA] Not sure why a link is being provided to a mailing list post.  Is the

intent to have a separate document focuses on screen sharing?  If so, then

this document should say this.  If not, then the material in the link

should be imported into the document.

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











Section 4.1


=C2=A0=C2=A0 By contrast, consent to send network traffic is =
about preventing the
=C2=A0 =C2=A0user's browser from =
being used to attack its local network.





[BA] Not sure why the threat is limited to the browsers local=
 network.


DDOS attacks against hosts on other networks are possible too=
, right?





=C2=A0=C2=A0 At minimum, then, it MUST NOT be possible for ar=
bitrary sites


=C2=A0=C2=A0 to initiate calls to arbitrary locations without=
 user consent....





=C2=A0=C2=A0 Thus, we


=C2=A0=C2=A0 need to ensure communications consent even if th=
e site is not able to


=C2=A0=C2=A0 access the camera and microphone at all





[BA] Do the terms "user consent" and "communic=
ations consent" have different


meanings here?=C2=A0 For example, the former tends to suggest=
 the need for


user intervention, while the latter might be satisfied by ICE=
 consent.


As it stands in this section, I'm not sure what the requi=
rement is,


exactly, although it seems important enough to merit a MUST N=
OT.





Section 4.1.1





=C2=A0=C2=A0 Unfortunately,


=C2=A0=C2=A0 the security implications of this functionality =
are much harder for


=C2=A0=C2=A0 users to intuitively analyze than for camera and=
 microphone access.


=C2=A0=C2=A0 (See


=C2=A0=C2=A0 http://lists.w3.org/Archives/Public/public-=
webrtc/2013Mar/0024.html


=C2=A0=C2=A0 for a full analysis.)





[BA] Not sure why a link is being provided to a mailing list =
post.=C2=A0 Is the


intent to have a separate document focuses on screen sharing?=
=C2=A0 If so, then


this document should say this.=C2=A0 If not, then the materia=
l in the link


should be imported into the document.


--047d7bacc1e420fdd204fe2c69b2--


From nobody Tue Jul 15 01:07:32 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6581B283D for ; Tue, 15 Jul 2014 01:07:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XB6GhiJsqaPm for ; Tue, 15 Jul 2014 01:07:28 -0700 (PDT)
Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 27D8F1B283B for ; Tue, 15 Jul 2014 01:07:28 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 556A91EB8497; Tue, 15 Jul 2014 10:07:27 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.120]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Tue, 15 Jul 2014 10:07:27 +0200
From: "Hutton, Andrew" 
To: Martin Thomson 
Thread-Topic: [rtcweb] Interim meeting - Transports Conclusions
Thread-Index: AQHPmr2GsihPMz0Ymk6O7Hm2IGXq4JuWTCuAgAqEi1A=
Date: Tue, 15 Jul 2014 08:07:26 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17E23C15@MCHP04MSX.global-ad.net>
References:  <9F33F40F6F2CD847824537F3C4E37DDF17DF1291@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF17E1E652@MCHP04MSX.global-ad.net> 
In-Reply-To: 
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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/YKX6MbtjgRCv1NzHRWE6LngsyJU
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Interim meeting - Transports Conclusions
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 15 Jul 2014 08:07:30 -0000

T246IDA4IEp1bHkgMjAxNCAxODoyNSBNYXJ0aW4gVGhvbXNvbiBXcm90ZToNCg0KDQo+IE9uIDgg
SnVseSAyMDE0IDA4OjAxLCBIdXR0b24sIEFuZHJldyA8YW5kcmV3Lmh1dHRvbkB1bmlmeS5jb20+
IHdyb3RlOg0KPiA+IGluIHJ0Y3dlYiB3ZSBuZWVkIGNvbnNlbnN1cyBvbiB3aGF0IHRvIHB1dCBp
biB0byB0aGUgdHJhbnNwb3J0cw0KPiBkcmFmdC4NCj4gDQo+IFRoYXQncyByaWdodC4gIE15IGhv
cGUgaXMgdGhhdCB3ZSBjYW4gZGVjaWRlIHRvIGFkb3B0DQo+IGRyYWZ0LXRob21zb24tcnRjd2Vi
LWFscG4gYW5kIHVzZSB0aGUgbGFiZWxzIHRoYXQgd2UgZGVmaW5lZCB0aGVyZS4NCg0KSSBhbHNv
IGhvcGUgd2UgY2FuIGRvIHRoaXMgbG9va3MgbGlrZSBkcmFmdC10aG9tc29uLXJ0Y3dlYi1hbHBu
IHdpbGwgYmUgYWRvcHRlZCBzbyB0aGVuIGFzc3VtaW5nIGRyYWZ0LWh1dHRvbi1odHRwYmlzLWNv
bm5lY3QtcHJvdG9jb2wgaXMgYWxzbyBhZG9wdGVkIHdlIGNhbiBhZGQgc29tZSB0ZXh0IHRvIC10
cmFuc3BvcnRzLSByZWZlcmVuY2luZyB0aGVzZSBkcmFmdHMgYW5kIGRlc2NyaWJpbmcgdGhlIHVz
ZSBvZiB0aGUgYWxwbiB0b2tlbnMgd2l0aCByZWdhcmQgdG8gbWlkZGxlYm94ZXMgYW5kIHRoZW4g
d2UgYXJlIGhvcGVmdWxseSBkb25lIHdpdGggLXRyYW5zcG9ydHMtLg0KDQpBbmR5DQo=


From nobody Tue Jul 15 05:08:04 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF571B2884 for ; Tue, 15 Jul 2014 05:07:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.379
X-Spam-Level: 
X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_111=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id butLjGuUdYxg for ; Tue, 15 Jul 2014 05:07:51 -0700 (PDT)
Received: from mail-wi0-f177.google.com (na3sys009aog120.obsmtp.com [74.125.149.140]) by ietfa.amsl.com (Postfix) with SMTP id BFD441B286C for ; Tue, 15 Jul 2014 05:07:50 -0700 (PDT)
Received: from mail-wi0-f177.google.com ([209.85.212.177]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKU8UZlk6ALLDGyqdALb8UqAQLFVY9Mn07@postini.com; Tue, 15 Jul 2014 05:07:50 PDT
Received: by mail-wi0-f177.google.com with SMTP id ho1so4186362wib.10 for ; Tue, 15 Jul 2014 05:07:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=a1USM5uCWRICid80YlXYXvamQW9qlhRW/2z+WwISSi8=; b=ag4eO6T5HB1f+XO6mMcgrM9KnAqRYxjy/YWWf1yatbGzhKyo6mL3k9w8UX1/3ldgy3 Rj7UmFawtQOsuAUUI+rVuj0xJRIybC42e4xbSVvu2XiSTgV8TUkgLHl5D8eOHupjIWBV JASBzRG3j+H6K/7R5ge9B0I4bPVtqoVXh4cEVQnl5tIiRA7I8KVsw+nas48Fk+FLxP24 /BGTUvtbN82hcQ8sblRNbSaE6IfVlsbFla6OsuNpixVI+8L5gLs6nDGl/eYfEP8R/QtK gwSu1GSJ5t8b1Qpl+GuCBWq8BKzdVkHiH/Fv5J0uIav89ePdISmz3QoKHJeT0Nf/YCas Z1Eg==
X-Gm-Message-State: ALoCoQkq1g7s+iZaS8BiYBYU6mzLJIomyqM3QDRFh/ZOpnxILI6htXr4oQ3nFIqoWzb7ZK+t/xIVKrTaGDMzGDQSo8OUiy6CdwkI7V53NYuf+SL4Xjma7fY0YNwyKB6qGfbvbPg5jqul
X-Received: by 10.180.207.48 with SMTP id lt16mr5232694wic.32.1405426069261; Tue, 15 Jul 2014 05:07:49 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.207.48 with SMTP id lt16mr5232682wic.32.1405426069159; Tue, 15 Jul 2014 05:07:49 -0700 (PDT)
Received: by 10.194.60.178 with HTTP; Tue, 15 Jul 2014 05:07:49 -0700 (PDT)
Date: Tue, 15 Jul 2014 13:07:49 +0100
Message-ID: 
From: Michael Procter 
To: "" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/aVBzDEHZFGRcpcBKif2Wxd1XUH8
Subject: [rtcweb] security-arch: Identity Assertions
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 15 Jul 2014 12:08:00 -0000

I've been reading the security-arch draft, and I think there is a part
that should be removed.  In section 5.6.4.2, the second paragraph
starts:

   Each identity attribute should be paired (and attests to) with an
   a=fingerprint attribute and therefore can exist either at the session
   or media level. Multiple identity attributes may appear at either level,
   though it is RECOMMENDED that implementations not do this, [...]

This conflicts with the next section which begins:

  The identity attribute is session level only.

The notion of pairing identity with fingerprint attributes also seems
to conflict with the third paragraph which contains:

   The a=identity attribute MUST include all fingerprint values that are
   included in a=fingerprint lines

I think the whole of the second paragraph can be removed without loss,
since the parts that don't conflict appear to be addressed in the
third paragraph of 5.6.4.2 anyway.

Regards,

Michael


From nobody Tue Jul 15 08:53:43 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF27E1B2886 for ; Tue, 15 Jul 2014 08:53:41 -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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jsh8_qL8IDDr for ; Tue, 15 Jul 2014 08:53:39 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4221B28BC for ; Tue, 15 Jul 2014 08:53:39 -0700 (PDT)
Received: from [130.209.247.112] (port=64835 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1X752v-00061b-99 for rtcweb@ietf.org; Tue, 15 Jul 2014 16:53:38 +0100
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Colin Perkins 
In-Reply-To: <5385C8AB.8080606@ericsson.com>
Date: Tue, 15 Jul 2014 16:53:33 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <43EF4063-F132-4A4B-BB54-871E93DF1401@csperkins.org>
References: <20140528112153.7351.96214.idtracker@ietfa.amsl.com> <5385C8AB.8080606@ericsson.com>
To: rtcweb@ietf.org
X-Mailer: Apple Mail (2.1878.6)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold =  On = 
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VUaSARexL461PySCYVkTxH8fhOU
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-15.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 15 Jul 2014 15:53:42 -0000

As far as I=92m aware, the only open issue with the RTP usage draft is =
whether it should make some recommendation regarding FEC. The draft =
currently states:

=93There are several block-based FEC schemes that are designed for use =
with RTP independent of the chosen RTP payload format.  At the time of =
this writing there is no consensus on which, if any, of these FEC =
schemes is appropriate for use in the WebRTC context.  Accordingly, this =
memo makes no recommendation on the choice of block-based FEC for WebRTC =
use.=94

but some people have expressed a desire that it recommend some FEC =
scheme. As I understand it, the possible FEC schemes are as follows:

- RFC 2733 =96 parity FEC; requires FEC use same SSRC as original media, =
so doesn=92t work with bundle; abuses RTP header fields for FEC, so =
can=92t be used with mixers

- RFC 5109 =96 parity FEC with uneven level protection (ULP); =
unnecessary complexity due to ULP; requires FEC use same SSRC as =
original media, so doesn=92t work with bundle

- SMPTE 2022-1 =96 extends RFC 2733 for 2d interleaved parity FEC; sets =
CC, CSRC, and timestamp to zero, so doesn=92t work with mixers; requires =
SSRC=3D0 and PT=3D96, so can=92t support >1 FEC stream per RTP session

- RFC 6015 =96 interleaved parity FEC; abuses RTP header fields for FEC, =
so can=92t be used with mixers; works with bundle

- RFC 6682 =96 Raptor FEC; works with bundle

There are IPR declarations on most of these, most have problems with =
bundle due to the way they use SSRCs, and some have problems with RTP =
mixers due to the way they abuse the CC/CSRC header fields to convey =
protection information. Accordingly, I don=92t see a particularly good =
choice for WebRTC, and since we can add FEC in a backwards compatible =
manner in a later revision of WebRTC, my proposal is that we leave it =
out. However, I=92m open to other suggestions.

Also, if there are other open issues with the rtp-usage draft that I=92ve =
missed, then please let me know.

Colin






On 28 May 2014, at 12:29, Magnus Westerlund =
 wrote:
> WG,
>=20
> This version contains some changes as result of last weeks discussion.
> Especially you who wasn't there should review this to see that you =
agree
> with the changes proposed.
>=20
> The changes are:
>=20
> - Multi-stream optimization are now a MAY support, MUST signal to use.
>=20
> - The T_rr_interval =3D 4 is now explained in
> draft-ietf-avtcore-rtp-multi-stream, so a reference has been added =
here.
>=20
> - Signalling of extensions has been clarified to be a MUST
>=20
> - The DoS potential from RTCP configuration that Martin Thomson =
noticed
> is now discussed and the general consideration that an WebRTC
> implementation needs safe guards among this is present. WG needs to
> consider if it needs more or are sufficient.
>=20
> Cheers
>=20
> Magnus
>=20
> On 2014-05-28 13:21, internet-drafts@ietf.org wrote:
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>> This draft is a work item of the Real-Time Communication in =
WEB-browsers Working Group of the IETF.
>>=20
>>        Title           : Web Real-Time Communication (WebRTC): Media =
Transport and Use of RTP
>>        Authors         : Colin Perkins
>>                          Magnus Westerlund
>>                          Joerg Ott
>> 	Filename        : draft-ietf-rtcweb-rtp-usage-15.txt
>> 	Pages           : 44
>> 	Date            : 2014-05-28
>>=20
>> Abstract:
>>   The Web Real-Time Communication (WebRTC) framework provides support
>>   for direct interactive rich communication using audio, video, text,
>>   collaboration, games, etc. between two peers' web-browsers.  This
>>   memo describes the media transport aspects of the WebRTC framework.
>>   It specifies how the Real-time Transport Protocol (RTP) is used in
>>   the WebRTC context, and gives requirements for which RTP features,
>>   profiles, and extensions need to be supported.
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/
>>=20
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-15
>>=20
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-15
>>=20
>>=20
>> Please note that it may take a couple of minutes from the time of =
submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>=20
>>=20
>=20
>=20
> --=20
>=20
> Magnus Westerlund
>=20
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> F=E4r=F6gatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb



--=20
Colin Perkins
http://csperkins.org/




From franklin.blek@gmail.com  Sat Jul 12 18:41:59 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301AC1B291F for ; Sat, 12 Jul 2014 18:41:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QvJmcjsPvI1 for ; Sat, 12 Jul 2014 18:41:56 -0700 (PDT)
Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FF851A00AD for ; Sat, 12 Jul 2014 18:41:56 -0700 (PDT)
Received: by mail-qa0-f42.google.com with SMTP id j15so2145405qaq.15 for ; Sat, 12 Jul 2014 18:41:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tnVD7xpP6WlDYQzqspHMB9inb9gW1wbpDglfVqsBs6k=; b=B1anHa88LAUr9h39vs0QexjsqdXxRsALU99YtJqk003qaDRk5PrCv0xP5KTa/pb/fQ kv3dpYcMBG2TNi/MbG2lvGR/4r9POW+4TtMD0AlZyhMmBshBvVN9k0fCTmvSjXAvD3mW Rl2IDwDvnt3aGXRPfDh5KMe26qgzmSDOehzAgrPaviS0YSsGcIYDctQcr2wW6Am7JMif sI2HziXU7l06s1UU/+a2IBzT+GlzSAHZyo27rTHjW9GKn17bFr9ssISI9tUWXRDfV/L1 lA8dlm/1KQayI85UIniNERlzS4pWr4r+acnNzpeKfBPzYPGzk4Tvti8GIqfnB27+0Ek5 Z/3w==
MIME-Version: 1.0
X-Received: by 10.224.152.5 with SMTP id e5mr9701413qaw.65.1405215715341; Sat, 12 Jul 2014 18:41:55 -0700 (PDT)
Received: by 10.140.101.69 with HTTP; Sat, 12 Jul 2014 18:41:55 -0700 (PDT)
In-Reply-To: <74.10.26169.C4457B35@epcpsbgx4.samsung.com>
References: <74.10.26169.C4457B35@epcpsbgx4.samsung.com>
Date: Sun, 13 Jul 2014 10:41:55 +0900
Message-ID: 
From: franklin blek 
To: kiran.guduru@samsung.com
Content-Type: multipart/related; boundary=047d7b2eda3b8c4a6204fe0947ee
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/I0fEtuu8sx2ygC6TkNe481uVrB8
X-Mailman-Approved-At: Tue, 15 Jul 2014 10:18:16 -0700
Cc: rtcweb@ietf.org, public-webrtc@w3.org
Subject: Re: [rtcweb] New Version Notification for draft-guduru-rtcweb-codec-preferences-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Jul 2014 01:50:48 -0000

--047d7b2eda3b8c4a6204fe0947ee
Content-Type: multipart/alternative; boundary=047d7b2eda3b8c4a5f04fe0947ed

--047d7b2eda3b8c4a5f04fe0947ed
Content-Type: text/plain; charset=UTF-8

Hi,
The draft seems to explain codec preferences in a good way.
I think this has a good potenitial to be a part of WebRTC1.0.



On Sat, Jul 5, 2014 at 10:26 AM, Kiran Kumar Guduru <
kiran.guduru@samsung.com> wrote:

>  Hi,
>
> A new version of codec preferences draft has been published, by modifying
> as per the review comments received.
>
> Please review and let me know your comments.
>
>
>
> Thanks & Regards,
>
> Kiran.
>
>
>
> ------- *Original Message* -------
>
> *Sender* : internet-drafts@ietf.org
>
> *Date* : Jul 02, 2014 18:28 (GMT+09:00)
>
> *Title* : New Version Notification for
> draft-guduru-rtcweb-codec-preferences-01.txt
>
>
>
> A new version of I-D, draft-guduru-rtcweb-codec-preferences-01.txt
> has been successfully submitted by Kiran Kumar Guduru and posted to the
> IETF repository.
>
> Name: draft-guduru-rtcweb-codec-preferences
> Revision: 01
> Title: WebRTC Codec Preferences
> Document date: 2014-07-02
> Group: Individual Submission
> Pages: 7
> URL:
> http://www.ietf.org/internet-drafts/draft-guduru-rtcweb-codec-preferences-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-guduru-rtcweb-codec-preferences/
> Htmlized:
> http://tools.ietf.org/html/draft-guduru-rtcweb-codec-preferences-01
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-guduru-rtcweb-codec-preferences-01
>
> Abstract:
>    WebRTC specifies to implement a minimum set of required codecs to
>    ensure guaranteed interoperability between WebRTC peers.  WebRTC
>    allows browser implementers to support vendor specific codecs apart
>    from mandatory codecs.  This document specifies the way for
>    JavaScript applications to give preferences for media codecs in
>    WebRTC context out of the available codecs in browser for creating
>    the offer / answer.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>
>
>

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


Hi,


The draft seems to explain codec preferences in a good way.


I think this has a good potenitial to=C2=A0be a part of=C2=A0WebRTC1.0=
.




=C2=A0


On Sat, Jul 5, 2014 at 10:26 AM, Kiran Kumar Gud=
uru <kiran.guduru@samsung.com> wrote:






Hi,


A new version of codec preferences draft has been published, by modifyin=
g as per the review comments received.


Please review and let me know your comments.


=C2=A0


Thanks & Regards,


Kiran.


=C2=A0


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


Sender : internet-drafts@ietf.org<internet-drafts@ietf.org>


Date : Jul 02, 2014 18:28 (GMT+09:00)


Title : New Version Notification for draft-guduru-rtcweb-codec-pr=
eferences-01.txt


=C2=A0

A new version of I-D, draft-guduru-rtcweb-codec-preference=
s-01.txt
has been successfully submitted by Kiran Kumar Guduru and poste=
d to the
IETF repository.

Name: draft-guduru-rtcweb-codec-prefere=
nces

Revision: 01
Title: WebRTC Codec Preferences
Document date: 2014-07-0=
2
Group: Individual Submission
Pages: 7
URL:=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http://www.ietf.org/internet-drafts/draft-guduru-rtcweb-codec-p=
references-01.txt

Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc/draft-guduru-rtcweb-codec-preferen=
ces/
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/draft-guduru-rtcweb-codec-preferences-01

Diff:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://www.ietf.org/rfcdiff?url2=3Ddraft-guduru-rtc=
web-codec-preferences-01

Abstract:
=C2=A0=C2=A0 WebRTC specif=
ies to implement a minimum set of required codecs to

=C2=A0=C2=A0 ensure guaranteed interoperability between WebRTC peers.=C2=A0=
=C2=A0WebRTC
=C2=A0=C2=A0 allows browser implementers to support vendor =
specific codecs apart
=C2=A0=C2=A0 from mandatory codecs.=C2=A0=C2=A0Thi=
s document specifies the way for
=C2=A0=C2=A0 JavaScript applications to=
 give preferences for media codecs in

=C2=A0=C2=A0 WebRTC context out of the available codecs in browser for crea=
ting
=C2=A0=C2=A0 the offer / answer.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0


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

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

The IETF Secretar=
iat



=C2=A0


=C2=A0













--047d7b2eda3b8c4a5f04fe0947ed--
--047d7b2eda3b8c4a6204fe0947ee
Content-Type: image/gif; name="201407050656727_QKNMBDIF.gif"
Content-Disposition: inline; filename="201407050656727_QKNMBDIF.gif"
Content-Transfer-Encoding: base64
Content-ID: 
X-Attachment-Id: c52c5aec3d8c59b0_0.1

R0lGODlhCAKQAMQAAAAAAP///8k6OspMTNRiYtt0dOSOjumiovLExPfZ2fvt7f/+/uvr69TU1Lm5
uYyMjG9vb0dHRzMzMyoqKgICAv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEA
ABUALAAAAAAIApAAAAX/ICOOZGmeaKqubOu+cCzPdG3feK7vfO//uYBwSCwaj8ikcslsOp/QqHRK
rVqv2Kx2y+16v1YReEwum8/otHrNbhcX8Lh8Tq/b73al2M3v+/+AgYKDVniGh4h1egyEjY6PkJGS
k0OJlpd5SXsBDQ6engwNjFKilHoNSaVYqkisTK5CoUqdo02waLJMubGogg6Nt1S/a3IIeAoJmHAJ
CnTIipq1EBETFBERDRHDUdqmSQ8PSd1GENzbR+NN6UPgqRPYr+Hrae1MDhFE94MUfA3hRvOKlHPC
z8xAIXIG4EFQAJGBOQWMzWEIDckmIfqEBFR3zhuWgk82DhGJrmOAekcy/zJpR5IMSiUqA8T8A5LN
yyc1l+QEU9MSxUMKD/2cs6iIyggQKExAxSCCtVoBmlKgIC/pBEZSIzBw8I/ryWr/hDSYRjUpvq9U
ozpdGiBp2rZTyzUAO9BqLyHt3IZt22Cs03Jm0YbzS2HgA2sTfj0AixfxNqlsszLqtjgtuAfDMA+p
BlgpqgdJh82d8ACpZ7VPiUA4HNlp2tVKHVT7NbewWKUR9kpNy4Azvt6F8SGdIBg1W71C7CY/rTru
ycr/kiYlAm620+hxm4o9K5ax5Las+04gvTschL5kD8LFBmFCZ9twp8NlO6S21uJfE7dNygD6+kpx
NGTAAQMQkIwCBAxggP+AySTw0AEJPmTAAAU4SIABBiQDIYUKDCVHUflwd81JgJWomlz8UMMABCay
OFdyDzBAgXh3OTBjA1T1JsqNS5VG4lxbEVeaCEut1hQ+i/VHHDsPACkbEdrYuGNfFDggI41SXnml
jVbyiGWV7CDZYjnaXDmXP+CcNWOY/ly12En3xeLiiKDtZ+dISOLDIicpCucmPuTlFkBiMu61J47g
HZnoiFWK4KWPoDkppJuTKkmdVjomieiQ8uHl5o38DKkjW3Vu5gCOK5pIp1YuHpqiJzNeWV+VNjIi
ao+shkoplPLE6OWVbyLlKI04bpPQAgU0dICAByiQLLLGUDSAMQMkkMD/tAgMoICzCChQLbIHeBgH
iEMc9Ys+a8pIhBg2BiCoumsiqh8F/dUVVkYFaVPqaj6KIBsjvQCcGL0yCTcMfc8ByQmUnpzVTaj2
ZqTvQIntCw7F2/TLSLyvWgyOjEGG6O7BaBbB0rn4pFtTN/qw++pzBb8Y85KrrctIuwT7mHPKeNmr
8b8Lj7OU0HdFxUnF/7yMKJMFC1GQwA7sqV93GMmKKMtIhuPyyBKfw49KUHdzNckjDUYijKXKo5i9
AfQUh0IRLSBtM8tCK3dD3yazgEI/xd3ggOLCQS5GIqLc9lRTEWHfy2037jR4Lx6G+L1qasQV4jlS
E2N8TK01MOHuYp6x/3mFFR2lw7+EijlmqNej7+quP6b5xkN0DHuvNZdrsOU3ndw05isbvvjIMN9j
I+LanPXS8AWhC3pBkk8V4+ych474PaIPARnSj49TUzv4GpcYkDXFBNLL+rQz/OmWE/H1Wdsb3332
3QkaPVUvUba64wi9bbe0cKBI3CgCobjt7W5wiNuECECAcDWEDoNrWvucJxYiTO1l8MLK19xTjnoU
LXwj82BUQtGeqPiDXnsaGcH0MY6iqa8/BLNc1xonwq7FToSx0x4JiUMwdenrH58JB2jWpDviDYor
e4EZ1vhnOsNdkHjgS14stqK8vTyxeTz7HV6AOMKxECcUh2mKaIxYtP8U/rB7w/heOMJnxl9wUGQy
AVlU0Je1QSWNa6hznwTb6D0yKq5g/KpgPdQGs4XxLwDHGiDeAtgQRS6AGcs6wAH7hoBl0c2BFTnC
RSRIPBaucUlOs1WKOigcIZ5lPKgAmqBA57goXcVdoNEaVU4pv2KxSFH9QthlaDmShrVvg5NhneVe
VCxVYoY4xRpCzXxoSq69MjftkBEoQeejTSXRd56UyTSXmLOXRbFtnynHmkjjPlHCsi2lRKfjjLnM
WQqhYr/BVVQQJrYq1QNiJ1GjBJUGptAUgV4gs9/u0heObuKxfbWTYD250sFQxfMuhLqHwnLzoiex
7JkFxQgi/efIAkj/ckHgWsCyEkCAZgxokg+MyAEegiBMQjAaRilc03DklHO0xz30okY1UEFTIjpF
meOZJgi7cVNkIiZGQcWHjaiRG+BMY57UUM/HksqwGY5nRUFV6C+KutWstiWo26ApOXuKCqJm1XVJ
bNl4wNS7WQrPGmDqZdNuyh/KrBFJ71jTYsZjqPHwR6z4GM07+FdUPs2Oqr2JKlTdkw/EQPOOvckr
de76uKW+Y4072SuKnFJWwx0GNH7NqS+N+M7EnMWyTR3PTxPLWHYc9avjSc5sjFjYQV2FH4mMVkNI
ysCGZCtZAiJAAQy0AAZS0lvDxVDgFhDBJpzKCH0xSi22ApUidAIK/9eNxXMxcpfsnsRW3NluSoqm
BytxwiT5gIp342iErdyFutA1CcLGOwvylsu+0MVvfGsR3fyuq2i7sO5jxCtemXzQvutNCXbPUSrr
vte8reCpfjUJYbF05ML2ha+F84Ff71I3HIh4RhysVQyJLKBDzZgDig3RXI9MYTGHQa+Ln+CXGdsY
DIuR8Y2x0B+PiEAZQA6ykO/AJB0bYchITrIcFNAsJTs5yDvOgieiTGUt/BgTzLhElp9siS0X48R6
C7KXtZxiMSNgzGM2hIjn4OU1TyTMSXYzi1NRXezWeRBGhgkYaHNn66q3zyaUQp4DrQmeArrQTbgy
HB5yCAMmwtFcbv+0if13AEkKudJAxnSQfwtpSN/hIct19HIN0EAlg/qBiDiCP0grhZtoQTNLWJFO
qLATLYQqiSVhWBJm0oRaxxQmu3tCOXitSQYcS9KX8HSkM23pIGsaE89WRrQDNOk7BMUOyqZDtoF8
bUscwXeEaAkrk+BrJpT7CucuwjpIQmwstHvcUHhfoo29aAqJtECWJhBxC7DAZAyoQAcqAIfs1u9H
ChxDzoJDwkccoQSSesQLGoAkLYShBBQgxRlS1sQbfm9+N4jj1xJusx+ZoH0T6OKPLJBHi8FASTpr
4P82EG9XqiEKEcAYG5p4xCVEIQedWOASt9syJKTvBBT95SjHULX/Ir5Se9+bQxOqEEsFnvSij0sy
siGNaVqTGhY9JRtb7Q/pyDkfF1ZmbVWqTUOXovbupOUvZV9OpwqZNb7KvSDKGWJYq8GW3FhDI4ep
HPjsXh53WWUyilHKXlrmGsw00ysjeY7d10NFvnCiHE7VE3rgHrqnKtMasuE8a3RD75SfWebaIqnR
CYAsZT3kWXXD0AJkr9KLQ2j2BnBWQ4i7Ujk0sKV761YcstUsbWVrWxE5KUkPiOnfe9RbHZpWcZu1
8ptfa+SlrlvQq3/moMfh5seXPe2VdfGKR0T12Tp9t4xfLW9ZC1sCesjyRd1I8jurWeJ/fe6z9f5m
ydzk14IAFJF//60nUqhmJ7c0J2KCgGQCAWJkI76SMFfxJEPyJK7VCUJyH+QRKEg1PeEwPvSyGP6g
FRSYK5P1OEnSLpziUCHzJhbUTIXRFAXlgIJya0dUK4dCHCqyJ9pwJqhSRK7CQvyQOyg4gSyIFCxk
ODxoMFkyIyuoOLQSK/TigzE0QsfSe7NXaYwmSR2lW3vTIHDDEJZmINqCQLJ3cwzHSAfEcovmUrUn
Ug+hEJWGAKx3N1gIfnXIEMuXhUt2YtoHB5W2hye1DHnofin3PxoHLXdYSYwGOClFLQi0LXIThsPX
SF4YN3lDiT8RFH7zc5LEN3gDhog4LhyjRIajMlCUJlIEDkBTVv//oEsUUzIWmISziA2vZCXZNChg
xycnSEN3VE/npIs3gRU6k0opY4y+KDNWsjWr1DFsAzpbww/WsIsJdU/EsxVJ+DvgdVAj0w3qokc2
9IxWSGkDUI4SF21diEDXFoYGFBFBQRGq120/AUDF8EBz+IjFZTdyGC7mSCGaFhHZYo4RYY8jp2/P
EhT3CIjN5iHrOIqYplKWplL96IaQCI8JInBCh0Dp2JCOtIYKVCClBopreEAdyVznY4q/gzmdhBQw
JkSkcx7WMxWjwzuU1TRRgjlSVESuIZN9xDS+iEbzcz1t9Q5ZREHOw4rccTRwZUS2MzlFNDyJ4R7t
okfWmA7ZaJT/TIg6PZlQNrQ/U3SFlqYh+TaKjlSG3gItBnRzZfgTF8JoAZSHi1SPCklJ01eG+/gT
27KIeNkhBMlwyUCPCSlSC/lA69cMZ+lID1lJEamYy4BA+ohAaEiSJiZAl0gthqmJD8SJlYRymCaS
ZomZpKhBKElBQUMboAd6MANGQzNGPnlGtciN/nJalddCTNmLNtg4fUSby8MWWLlOPIOUVfNE3tgx
XFRETzQNuUEN/1RISuNL3AQ67NONv/CNXNk6xfmV/kNSzeBRy0eHZHmJklQ3b3gtuKd79VZt37Jy
3TaJyWAgdAkhjLaPXwiH1xJ91KIhcdgMpfaWCRSXnamfI6ct/+63cuLphYm5fAGoneBCl55JN5So
hulIoJbomJrZe8AnkhI6ioIjUKOZThZ1MDqYM2nyTlzxG1X4JtbkNK5IPHolTsOSPiZaL/lEHcN2
m/h0GHAyR2KXD0vCKOZRUD/6kwA1IwaFFDnagxhVRAYFYzaiHj9JQx0EAdnkI4LyVNGpLyYIjqgz
UWGhaMVVUqTGQIuWIMaQjvBIIenZLQxUagiiIIS5npPIQM2wnnTIQKeWQMZwfXAgnyf3LfqGhn1a
cy3ne3bKeggZniBZkHaacgKXDIjJhd0SpmgoqY4ZN8YVXBdSLfT3nYyaphSKp8jVll96po2qocxF
VvlUGm9VU/9G9FMlBDOIpVNSFVQu6SlX9VWXw1n5gSI06FeLVRM09VPWyFr80BS+ehNBVUKI8UrL
SjvtoFmwlRTZsFadBVtCpSehRSW+kkQ2ClUzog9LNSKClZXtIx05MR4zVFvYqXDClwCTJnyJsGJv
Boh0Y49uKQfuegd6WG2WsGJGBwfEdWLwCmZ1MLB1IGfLEGbyiggGm692sLAkFmQLewgLW7EG+1Ia
xgn4lbFOUGAF9hwfu2HlghUV1l/nxV35QGFLgGEwUQv0sg0vmwrdRV7olWCKM2FOwLGExgtLoBlL
oz0Vpjgd4aXLhgcQQiA4F5mXsFxAhiALUodFG7VSO7VAFgj/rlZly6lHWCsMs+SkUUC0VDsHcxhA
/IoI/+pkRtdkYbu2bNu2gTBlW4sE1xS3wnC1ULAJuxBgQgtdgIZEYJC3OGsEnxC0W6C3WsAKnTC4
h8azMPExXICNcFu4gdtegwYgIwZnbftIZXYMmMu5dUBiZbtpSztkz5Bmn7stnXuwqZsHm6ASxLZU
ACFj17AYXhsGHWQenNRr16CrWzBsSbkF6TAN1XANk/tuXwFai9uz2xCut6oJtUsOudsEItgKezEH
F5K5jwSpiDBtC4FqctCZTwandRAuIwlklEkH9wotTKtwDzJyLNa64fW7WwQFPjJPlduxSZluSAAS
DZYF+msF//NgvL9Gbr1AhFNglSKCa3A0awe8SkbwEvg6XNibmMu2XNy7ttu2tN47B+K7vo55CSNU
RNQEHaMxPdLDF150EAjzXP5BGEMUWGSBHWwBFhczjZjnFPfhd3HyONBZQtAha2qhlHKRHusxFkIM
eKlRH3y3efAReFMjwilceJmHGjvcNqNQCt8hFVGaGLJhG3vVCyrBEiWkHIyhHFpcxHLBGUhcxYOi
HW7XJJO3UQppABIRc+5qaZUUB/8omAnickD3UX8zc/wGcCSnIA7XQAdgccD1cwPXpiA1YirHhYV8
cS9HXCRlyODij3KKLFlIyC93jgxkcfVGXHZ8sBHCIJdcfv89R2oVV6dB53Ozd8mVtnGG7CAH9yHw
W0SagkLn4SpcA1AJVQQycipLISU4glSdkCMhuCsiCA7FpCcm8nZ7wb/itIxSeCZnw4FNSCW+xIFt
0ysWpBjacM1nwiUDXCupwotGMiJ7kkLJQVHKNCa9wRWvxIFzsTmcVIOKwcw9siu3BILd7IHfHIwY
UQ6vdESo4iKWW1xGx2iwVyGc2GyaJoclRZ6yR56KpADm53rTd3/Bx2TNIoAgRYADYp7ft36fGFIe
VTe953yf6H+vl9IPjXskR1LFJ1IldXszjb7UZ4krx53YIqAAKXHo94gQkrYd3UD8Z4iCk8sjjIJa
czOvMhP/mRUxleNMMEI0BNU46MJT0ji/tXMNO+U4FlMzFLUkxpNH7yMzOgPWFdQfOTkxJHrO8CPV
VpyjqEijp4GKK1QyyhhsMmENOsXDWh1sS9HXXG2LeJFFL1EzNaOMO2q5y4cgeAqZhanHliafBySJ
2eKQ2ssQ3mmAa6hpqjefZ1mGdUOIbUiSEyfaqAuXHolzMu2FnE2JD2ogJZkQ9YqWrY1SeBrajvjb
GreHK0WXTV0LrltHP7k+o1U70xXZwNlKo5UmorPV8naS0DPNnxDM9yNMRog8M/Q+GUFBLyE512BD
/xDAp3UWzPM8KtleewI8hwQ+OElasuEJd5Evw8A+O1kl/zkh3utN1lb0DowVExAcQBRSqog5IN47
0YK5p5MMmhQM2oTpn2OY2f24hkPxE+BLUivnLL8XkOUYl3EDvo6UyrYtdAPphXTwjpbo4ZldqQJI
kJREQC5F4ZV93Eqsy3fUDmQ31b+bDrFk1YQ93apaQdatjXMk4FqrtSJUKMSREbH5SwXzmtmtxMaI
3gglwhlxRc9TH+UCSqSJCs0ji3Vt3/Kr3ySajQtT5olt5W49F58gb3F04AuKACd14gpSkDHu4JEp
4Z8dEbB9qKIN4Y3p4pWokAf0l/yGuqS2l7H94KC5nymelqD9wcdGmYwehzL+E8GtvhoX2jiekSFc
O71gP/89XlDmFJ1hjhXjcxU6MlSwggryFOt1JG8ceuXBrLXG5C7NGE7h/TsrquvapBFx7QlGdWEB
ftc4WqUeOk1xVSeC8qGwdE/hhOZGAD2BJW/1K1rndN3D7tZE+DDDEk2o4D+q3ZECt7m919kOjtpw
E56JWJaOmtKCWZ8BIkneuXKPvKftmdI3x5cnddr4Gekm7oXw/ph1g9G0DWf8boloCEA13n7uyXre
MuOSXu90aQyl7ilMZSupHq2ixWvtcR2y5R6VJ91Zh/Ksxas+blqGtSbEfkg8bK2N0QuLwVlWBfN7
xaxubVvuAfPEw1V0ffJ/5Vgxfw42ElQAA1e0cVb/kPP/a9Iew8BrT7NWpumABJ7GsWVb6cP0TP5O
d1En0PpZ7QCI3qstHZnakJwsmq0QYToh0bfIBLIsBrqmc6qQBGKO3SdwebqmDb6mKX1yDXQtwxWe
wvUtminpoxj32vLoCoEgZOrZ+Ar4imhzknSpv72mjAb43TcgiC+nDMpcm+RetjC5FlY0NhtT6yVe
HlZhOksKOkYLFlGylRuy6YVdAEaz+PWxrl+zFYb7SPD7KCuyUWH7VGCyJosJg7hkoZuw+ApnEctm
z+8MZxYHCPtInSuvHRJm7rq5WgZn1z98q8tkKrb98DqxI/auZeawy/D8ktTxjSDAdFv/9n8EhkBq
4I+9//wPAos4kqV5oql4KKr7wqlyLAHDBLm+873/A4M5xkNoPCKTyiWz6XxCo9Kd65CIYbPaLbfr
/YJdNkZYlGiV0yTEtYSInU8JBLocV8feWb25ruKLAOJxCboUqtxxJZosdi3GCR6eFNo05DQ44EA5
TD01aB4xWOrcpB3QDJYZEKAuHLwNxBQUKgwUtH0l0MymjryexGYFr7Se/A6LIPcKwxxn8cYYlECT
/FJ7nVbTKMcqSKso1zhE2FBEjD5RdDo9FCGN75Quz2td84bvFZgWL1974ae4R2+gCH+pAE57Y3BL
NhP4EOgDZyIAPHhS1K3L6MPiEDK+BhC4oqCArRYGDv+AnIMKwaldKAu0eGkA14IEBAZ8K7DKFyp9
NkvWvPltxE9pKEOuSIkTaNESM0/d3IVzgYGUrqoiOAkSwc03I0G+IsBqJlWrUFk5ZSq04EtXKX8i
1XcWVVWkZatqW1DgZZ2jCZbC1Ot2ajWrXwNrJcB1wJvEixUS08tXcNnAcHWl1HfYpF8SM7/aTTq1
6q1VBsj69bs34kgSe20V3Fn3yoECYmlkW5pT72ird8NRJBeBAoQh5GyQazCBeI7j7XYQN4dDOYUJ
DR5wCoA9AITq6LR3d0C9OMUJE9x1t679QQRNED4Nb29jOYTjHYmGPECAqrTTevef9hdbubn0lwII
MEb/AisKoMVYX6jEspdkCywo4QgLVsiCCCOxMIBLFLJgYUEsEXDgfvrpApN+rgRWgD62zaCPfwIG
OIt+M5xYIoLVwKQTiAxuU+BeQLK4QCw37libiSx6gwyBE244pIcTxjLAGaHZpAuA/Unj4n8x6vVi
ibUZGdmUEh7ZozRoKSklf296SeYINso1lJFXJvAXAggqMBIb+ZU45CxIHWAnThwaSYeSKyJ54jYG
IHpkfjBxxSReJQSnnXo5qPdAcecxcF4AGD2nAwVFRFCEqOx5yul1EzDgwAQ7sIcDqKkGMIEDDlBA
RHuyrgdBEcpxVxwExhYXgX1j+PLNNlcIaGEsitUy/8M2xBQqgmL4BaKPMg1FSAO0+y0AEbflvgiI
QK5YQa65c7IEIbpQ5tfTG9mY22e5R+6SFSqKgeuaV392Wya7er0hEpn8JkNvArwIyJPBDY048bVW
1lSNs3fWFOG9NJjLC77emlkyLwcu0AKYAmEc7RvvjkimviO03PC7Nm7Myyz+bUvzFeYGYyHA8ub2
M8kh//twwsBVtOyxue46a6akupMD1TbYUKs6wArrqg7PARscsRQFgGuu12FHTqsUWMKAOr1qt6w8
B9NcNzRHniTXtew2RM27QJcQsE1oITiA4RHNO689sBBT+OECBxyyHjbae7C5P5F08CzQUN4wvCP8
Tf+y5vfe5CXDZZJkOGN35xUMxQhbXKZ+17w+jMeWp4t77K5fSztIXrJs98uIIzzSgtUQwPrN8QqM
cJbcFBz05MzLvjfgIau+uh5Mk8NRAMo1sPVx8Fxtag7PPVCdsme3OhwF72e3HkXvvx+B9+7D347b
ZXNC//uj5sB7c2vINlR2uzL95SQH4122KMSHSs3rW/IymgHeNbNyuSt3n+OdBf3QuTJJTlvUExnI
9NEzhm1OD0PzXMXmAEHAja4WRqtew6BxBdZJjHfN02EszlCbVhDQSAaE3ciIWMLdmSxhf5ohy4bI
C5gVTwEJ2AlRYnSt5QVRZ28ggH9IEAwYQmOFNPz/4tE0eMPtTaRpPJjA08JGvvNVDYDrAV+mjqUr
/l2CVkWwyA0skgn75fE5qYIbRr4nRwF6JCgYnBCZfCSnm5SMXQZCECAwhqbASWNH2wIabQx1w37t
0EydhJy8zEUmAfXtYxGMCQpZ4pPTOcko0rDk3rIxCwiajm5pStkAZmAUJ9WyGOsqWomo0gqbLFJC
jVRlCItISyRmq1C4zF24ivRE4u2MBrXAD2dAGJFZILNSWiyLIKakQNe9UpcL/FAsTKmZXkazG7jI
lPe4Q4HssK1sRcin2awGx7CtTzlSY085QFGqfK7tBmwjqNuIUIQHTOA4uAIWruoTj0RSpSsdI8kN
/8ViFznlJjJH6VkgQFJMZfzFRUeyxbZegjHQmbQF11jFjg7mUpp8sJ2a8ShuKlfEVXDRSiipDR14
qs4RMIij+xJLC3RIU9twcT+wTBlUpZFUSOYwMiOgKQ8zahuarCJBKbUkM3P3U7FccoEpSx7GPCob
xfTQFmRN3IhSipatJg8pYlleRhP01JeFg6Un3ZBRA5abvDa1Y5Cq6lpto9MR0HNZ8/uaeWDFHfP0
U47PqSwEpGYO45iHPHA8nzkQGlrknPY54XNH+IbDCYFG9KJuqMOB0HDLOigwBbrQFk1qIokNAaK2
SKUDI35brt4C1w95QC4iaJKnNTC3BMI1g3HZcP9cGFgXdISIbrkOQdzkeuG5LphuufyQ3ZR99wUH
Qu6ehqvcQNThvA30Isomwd3hFjcQNJGEEFqlA0zsoAHfAUImgiCeIMQKFALewYERXOAhDJhZsgDE
Kt5LgloYwDYE2TCHO+zhD4M4xK4gad1EPBEgQDR+GllxJ+b2Ag354r4bOoWFTWzjG+M4xzouQ3tN
wA8bG1jFLB4yFG7QA1HEI8JENoKQEaxkIHxiyQaWsg+Q/L0m88DKQ9ayk5fMCS4nAcwQ3ggUFkyK
J1P5yGhWsxKw/AQkRxkJYjaCkXVQHO/VM81AKGQQ7ixZIQBSzzzgM5X9PL8/2zlTRM7zRhC9DnX/
lGoJkdajDwg9BNFWuTiTnrSgG01nTcfRCJbehHCwjGkdMFoIdfZnqjsdhVG7egmwHjKfOT1oRQ+5
1Qx2dEZsfQRf+3rUuoaHr2P9BF3rWdfC5jUQVt0d+0WUOQ3QNH14ANE7jqc56UuVeXAwSG5b1jmo
2ra3kcMcTUnn2dM2t3yE5Z0dvGfawzk1RE/1vc4eqzuiqPa02diDb/vTnpvqjrSXI596x1He50a4
Pc/xHvOUygFVe7as5n2+5cSRAcNRj8alw530cZw+yal22TqLavPYWz5lA0XH2w1yWd3ze8tRj9oS
PnNLfHs66kv4zmV+boykxxIYF/h3MM6eoT+H/+AZtzi6h1WfUz373sPx1GfXzR0BP70466YOet73
qVOpluQ53wE53K2r5XDC7DD/cnxwECrilN0S6Uv3Zxk+DokHMNRVVvA9eWUJtpGvf+hw26ty9QCN
7/Pw/sbVqUKVrH2ONuWQP1aoMsHPB4RvV2VHVtnUtiz7+Z3wpGAb+HjlbQjYSvHY6RUoTIV6xmuK
CLOqVagagKtUEZ6OAWQb4d0mHutkfhwMOFb4tP3fvueT96TfVNzAU6znr4+gwtI4OW61zwfPD/PW
6drYcvC0p60vArAi6B0JCuk4lp8ckoea29BveVUdHvYQlb2mXkV/ykocVsBqh3JiJTXvo56u+P9e
6ZFe41mH361W7VkE6CkfJlSfePQK7VkHRKGN4SHeqIwbdHRe2YyfcAhHBz7f98VfqTWUPmVe7h3g
OWBEZv3AqgHQAmreqFjCd/iX9p2P+jUHJzzHCuog5MnP1bwNDhzYDMIe+cygOgDS/cQgHp0PeQgL
DMpcE6ZaPr1RoHGczI3DsDjfx6GaREmcE0IesamK5bWe+OSgf3XNDY6BDJYDHpEPDrDH2LwRg0nN
E87K05hK2yBhD2ZK25if/PxX1uDgHNVh1YyNsMghDlqhAzIh84mhP/GfZX0H3IgHGqZNwIHecfAg
DHLiOUhNgU2Hrojh2PwhIPoTIIFNqcmPEbb/IdwQFCBNh/yBITwIINyoWhkqWiZqSqCNVgCNzyCi
og8Go2b54A7KkZ1Vh6iYYSHtIa7xDxSSFv1cohv+4hT6IgDhzz11nHn8Hq7M3ftUDQyWijE+oqcQ
lAaKo/9UjcaByqj4DzUekv34zyB2YeTpntW84zASW/3g4KbxIzFaRKQF5OrRjyL6TwxmY/w8IgAl
HXFMIqWth0VsoibmYCdWpP3IzcaJYs350SBOWjOmIh6FpP+8zTUCUnooo3aoI7EJC7ORAi5a5Cew
yte4A3Z8IjDyIQ/+YOTxJEZU4sGFofq5XTMqITQCoiVAoRth5A/4pCJmhyXgof0gZQQIC2vt/9oZ
guEL1tz3EEeomSH/lMp33EC/HSPOccIc3t1xGBmhWUTX2NGt5ZE+euJUMqQhqscctsNA1mNEqiUO
NKMhwUOgfcdCnt/3EIEtHtJ1zCJFPiNj6mJjXqQfDR956GJe3iQxaqBciuQe0ePfmaTEAWVd5hE8
hE8a3iI6euE49B8XXsKsAMvlydEw6uQO4lwxQh4gpUqrhEpQ6lPzJeHnLSEvyoq3TWOgXZ5FxJnV
FEHXQJom2t5r3ZMAqma4haMX9l/taSUgLkfrZSf/rGY/dc3+TNSs/GZvWhRCFQdb8t5dnpsOjOdm
BgdA9WM4Ss36AKHQxVE+KaPcpWfzKaDnzf8HOhDmepzjHeWgCcLKf2LiEm7irPieRbIe2wBS8G0l
bJbPKfJhYGaocOwReS5nqelmSg6nPi0gJZ6mDnBjapZdRDHfZcXctVnWbAojH3ZWRNkmAMFWOYjf
06QoVw6HWTrjY/LiZZlHLmYHjMaKF0IHi/rlfOzoodkoRInfclbWVeJRjaJerujKVjbfGm3pgdbo
//moqLRWzJUnbKlNtHkmHYaWJuRTgJUWJ2gmZ81KYaJoaNXpaMFoHO3pLiafk/pbaYbKkx5fVUKi
4mFWgFUpkaKeRF7kgmqp+AVnDF7bnZmDjbqNoSIpZpqPZmpmmb5WZZWacuzop8BKmCraOc7/WkfE
A/b1wK5sBDoAmCes2SXET4KRAvbhahTMKpQ1WYNZTazE6n+pGCYomJvxQK/uKrzp3bKeWZPFymCi
GZcZaxCYWRQOqxAAK4Gt2bUG2HdUKw8A66xuq60aWIT16pVtAnf6wLWm67siqxRE65kdma4WWLp6
n961ILsaW792mlf6KxB0Fr8GLJOxYMEibMIqbJoNrJwR7MJCbK9FrHbU6sR+j75abMZq7MbSSsW+
JMeCbMiK7MiSbMmaLBO44Mmq7MqybMu67MvK68PC7MzSbM3a7M0qbMri7M7ybM/67M+irMwC7dAS
bdEarcrq7NEq7dIybdMWbNI6bdRK7dRS/+2bCW3VYm3Wam3U6qwE7IDXAgHYBoHXiq0EmO3X8oDZ
qq3YCkHZrq0OgO3anm0AsK0P1C3coi3czm0OxO3b8u3Xym3Y7q3bsu3dBu7fhm3b9oDh6q3a4i3d
+i3d8u3bxm3aPq7kjm3aRu7dQm7hNm7eJm7nDq4TRK7dYi7g+i3hgu7lli3qHu7klm4SOC7r7u3p
/gDnrqHlPu7rGu7ski3inq7n6m7jUu7wIi7n4u7k3i7otu7xsu7lQu/z2u7iZi7wzq71bu7iym3t
Tm/vXm/wAq/10m7g1m3zTm/wpq70gq/zii/1Gu/Ytm7ysu/yDq/50u/5Iu/2yu/+ou7qXv+U+4Zv
++Zt5VauAOPv/XYv7Bbw+w4w9ZrvAwtw4b5u/f6t/gaw5vqu+kIwA5evAgOw8IouBg9u7YJwBH/w
7hLvBmOuCvsv+m4v+/6u6a6w6GawCE+w/kpw7Oou4aavBa/vD2cZd8Zw5zKv+xKwCbsu966u5wrv
C58v5AIu2qpw8z6wElfvDFdw/wIwFv8wD3vvDdtuB0MvFVPwBZdwF39w+iLx+rJwCn8vF2PxEFsu
BOdwEYev/C7BAmfx58qwC1tx7rYv45qxB6tu9MquHQNxGDMBGSPxBuOwFV/vAtuv/0qyBhuy4hpw
345uAYtxIityEl/y9xYy9kayAk/yII//8e46Lu6Wbymjchc/Mg1PcANbMuwi8imzagDL8SfT8i5P
wRDrMRzzMhJ0cB2rsitHQSWbsSBPsfoegRj3rRHjbTDz7hxf8hZfcR+38TNvMQhzMv6+sDKDMzLf
cRPgcCOPLxrvXR638Dd7cSTHsjVf8O2esw3PcgszMPP6cBKf7Sg/sQw3synbsw4XLDALLh6Trgbv
Mz9zb+m6MzHz8TwbQT3L8h8bsiivsRfvqz2/LzPvMQJD9PyaMh6TNDdnMzbnczmH7kpntDOj9Ehz
dExrb+wyMumCcRl7Mj7rtC47L0JL9DwLMku/9E5rcy3/swsyc1AT70dT9D9T8jAbcEgT/7VTU3VT
Gy8uw+9M6zM5v3RQK7VSv3Ix260Tc7AbjzAyW/VQL/M093Fbwy9ZV/Q7W/QykzVGR/RRtx5Yp7QU
X3NfY3JYL7Ja/3RVK4E3F/ZgIzb/ovQpn/EB7/VP+/JFS/YV+/Qjk208y/Nj+7RjD3Zlx7NeTzXu
MkAL8PNf/3VTp7Vbw3Vqt/NCU/RrLzRlx7by6u1JCzYrzzJcw/RYEzQHnzVvi/Js169wa0T+1rVw
o/Y+s/Zb33NotyBpb210S/d0G+1o1wB1Y3d2azfMWvd2e/d3gzfHdnd4k3d5m3esjfd5q/d6s/cU
jLcTa/Lo3rJAQzZV+/Vmi/BEV+9X2/92URuBAAC4AOgAgA94gBd4EBB4AAS4gSu4gB9Bgjd4gUM4
hPsAhR84ECx4hu9Ahlu4Eiz4hROxX/P2Ejc3Udv1Y9+3UI9zidc356Y3LUtxQ7u05AY3W/fvKtM3
Z4v4Uusyjuu4P39xP+94gnN4DhC5gx+5kSP5kit5kz+4g0d4lCd5g394lEs4g/dAh284lDt5lnO4
loO4Nsd2QO+0RW+zjBtx9tKzbv/4VcdvlUE3DJ8wQ89tNct5JzP2ZG/14TbxVb8yF+c5TmM4k0v5
klf5lCM6of83lCd6lW95l2M5lXu5EHw5pQv4hFc6gfuwYhu1LIcuK7u0HiMvUKu4Xp//MSNH9osb
NA1HryNjMArTOE579UzntkqL9CeLtQdHNWdb9ZEfOqEnupMH+6L7OoNP+aNbuYd/OZczAYFbuKM7
umbLeh5L8JyjbxQ/cTBD9myjdhkf8ZHFefe+8bhL76gfr4/Xsp238xKncgLzeCCvsZ4jAbQzOpYX
e6MbO7P/wK9feZgLu6Ev+xIse6TzgLNz+bCHeGdr9TET90STsEnvsFuD9GGH8LkLObhftwVru7i7
MnzD+i5XMSQ/vJ+PMVf3OU+Lc5BHtsDrO7Ij/BMkOZh3OaS3vMwPvMwjeMAXupOHPCL395DFdzgD
9Ij/vGV/NBsfPSmEe5qrcSc89Hxn/zut0/QbqzaMn3ZfUzFmTwHCD7ylbznOV3i9X7mGN7vO57yX
Y3q873rbjrnWJ/PQD7XRT7wco/oTv/htL3Zpf7y7I70WT/xU8zSsu3GnC/q8F7m/DzvOg/2+iz2y
z7zitzyVR3vYLzo77/rGr72J67etC74tc/w64Hm5J30uK7zD13U3v/mNX7zHqzglC73eNzaQD7R8
e73jd73kH/vtJ7u/F7zOEzymV/qk277ZDzraH37C6/j95jCL2zcQ1zPrQ79gOzM0Y3us80DK5PXP
l/WfZ7b2c7zGu73mQzVhb37z737aOz7lz7zw9/7Zpz/7L/76oz+x+z6z43zQ3/Pvrv/6IWcuCEiB
KAajiZ7pWq5o2b7uHM9unZLuojC5BAy2hMIbEfgr2mRLpg3XjD6lqhcxCr1ZjzOB9ytIgcdNL2oM
Npm76HWg7Waf4ba2mE51wcPLbN8Jc+RXRQNoIjiY2CdoxPXXhMPjk0dZaXmJmam5ydnp+QkaKjpK
Wmp6KiWJusra6voKGys7S1tLqmqbq7vL2+v7CxwcgCtcbHyMnKy8fNvD/AwdLT1NDUssFZQzckW4
nX2YOeQ4pEU5uKXdXYW4sqeG9sZnmpYXd2f/jh9v1x6mL/evnrx3ZQYKzBSHXz55awLe+0JwIUQ2
bszAizenosF9F+vwucbuD5SRLMD/lTz0TV0NcY7QKVFXbh3KloXu9ItoMyM9jmQeWpyYZg/DhhDJ
7Izy0+jGORwxSjyqBw9TnDp7OqWicapWOVcPOrWHjyhVnku3LiGK55pJlkp0xEzXtlwMGHJT4ljp
JO8UkyrubuFmVuzNsQH1afyJMyvGpAMZF6QatOziogYRI62M2ezXjQ4HXwXrz45gShdBR306mHFk
rJkjqu1bci4jlYQCjYMbO503wHzvzja09vc5skA5U04tNWdT5YoRH3V8NnQ/ywCP2+xM3PTYzVEV
ek7Y0ePTiVw/h5862vzjy6ddOzs5FzjfbuTWysUtf7hu/TSQ6O0fEmsPBcYHduNp/6feZFYRt153
UPm04GSV/KNYTgY2aBpoFU7YmGTRVaiaTgS6o9UaPCiwwF9x9aZbbfDN15tdetFlzm/GiNahVRce
ViB59MAD3WZhCUUQdaetdqBkQg2FVo7nCdTkktwtx1prnCSFXEQXTtcjCgygWFMS2iDC30y8vbUX
mVmsRCYLjKhp5kvZkdeeFCQOSKWWxRUZWnN0kiZdYX1KV+eVe0bHpXcLbSced1LaOaiihuqJyY/y
fJkimpeMdCaMe0ES5iOe+IUNopBeImiTN4nF6qCJ/VmVn12tap1nBSnUaoOodgmejl3OasmWDvZE
omBD4srrpWBqGpJ+pLa4WzZ4Uf8x3LOQ2OhpgIUyumujjqkqYj6L9rpUhkNNGSuhtgLLFbm6cqsc
lQjulF6V65qqWYk+GpdluAFgGic3pDqrBZyfenqwigJTy/BJXsWb6JJPcrloow5SVK6VTNVLa5JG
4luex792S5iHHD8G3sPwOjTkvcoBTO1s2iqsCZs0/RfzzdGm9N/MEM/JypYsK1mWpNd5+HPI77p8
mdGFOo1echlNDfSwD+ar2Z3lwVxN115/DXbY0XAtdtlmn4122qSQrXbbbr8Nd9psx0133XbfLczc
eO/Nd99+r71stAjjDG3CMOU2U+GFv6mwf40j7NuKKs7Y6X4z7uf44SesCRPPirj/ia3DNeqs+Hyc
s1R6zz6nrjl8L30uKi1cDxwmYM6GHheNMiVOuIvZJuybpprzZq3D9eWl+/HbyGAbXc/WZzuoB7Ml
p/Cmx05C7tLzPnj38Qn+O4vGQz55964wMEn4JJFfquj2bS4+bPG/Ja31zb+ouB/KF5+E49+4Jb/d
yQ+A9nkeOuRTsOltr2Dr856Y4pO9hcVPf4f7nuXGFxy78AyBvTtf+sCnuwu67wm4K+AET1iI462O
gOIAh/8kSD/QbRCDLoJefkyIGwP+bobzQ94CrfAD0Z0OgQSMCfU+1UDahG9362tgEmeBvhh2Dmdl
cuBu1pG55KkOiE8UYRd9WJfM/1kieuLTYhnr17/OZTFOWwxii2A3xvwxgRxFQN0Ns8UmIRqxEf6D
0f9qFyoopo9xU4ScGH+InyIisYMAstG0mnczC6LEep3Aix3L6ELLVbGQcVReD3f2OgFS0Ydm9IYA
N5lJPy4OEM1inxpRGYooNoyGrAtY9WgEwFZ+EpSwpKQMK3et1dkSjnuEjQUVyUs/ilFNdOwZI6fg
yVI185Ss3CAzmXc5Z+5SeNFsXStkqT7QUa6XNXGe9FSYhy8ukHQj3FnsKkFMDJrzevwJYQedGM5G
hvJ9v/zjNNGJQsMxEVo6FCU/uWezXIAzme7E4ori2chUMtSUVCwhIlf5TCWiie1TLYGoG+FHn1cK
jAvxtKQv04Q4ac7RoW9c4ztDGghm7ZOhtwnYQWGxUP7V0p7tVKn5AvnTzVHwpZIkKvCAyroqIhOk
PX1pLefYpvYJFKlMpeo903lRQDbVmzz1YP+qt1VvDhOrY3VqgLLIUeKdaYXA9B0fXyec0G01rWBN
Klk54VFf5tV89cyqEeXKSHKCYqF/K6xhD4vYJRA2sYxtrGPrttjHSnaylPVaZCuL2cxqNm8f3Kxn
PwtaQYZ2tKQtbSnQh9rUqna1rG2ta18L29jKdra0ra1tb4vb3Op2t7ztrW9/C9zgCne4xP1tCAAA
Ow==
--047d7b2eda3b8c4a6204fe0947ee--


From nobody Tue Jul 15 15:15:49 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48941A010A for ; Tue, 15 Jul 2014 15:15:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEuy9LrNFmPw for ; Tue, 15 Jul 2014 15:15:44 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 698351A00B9 for ; Tue, 15 Jul 2014 15:15:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6437; q=dns/txt; s=iport; t=1405462544; x=1406672144; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=QF/9ckkKSJOa+abHhOqsgvJndl/53syY3nwZtCd0TvY=; b=nLTjOBehPUld10sxsxn7czXqXr9wE6n2qFLEyQ1nSzaTgUdKye9xRcJ/ nBzYwGuc+w96IkrSYBwJRhcMPo6JsyQLOJzmq+Vt8b+1djWpncfPBXkKh S8wfrCE7ilHDrCM4XLGAVTx9Eyh5s7NBP8MwqpUppkGDuROiGExKe4C6X U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AowIAD2nxVOtJV2Y/2dsb2JhbABZgw5SUwQEwWsKhm9TAYESFnWEAwEBAQQBAQEJYhcCAgIBCA4DAwECAScHGwwLFAkIAgQBEgmIOQgFyjoXBI8UESkGhD0FiieQcYFLklqDRGyBRQ
X-IronPort-AV: E=Sophos;i="5.01,668,1400025600"; d="scan'208";a="340280077"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 15 Jul 2014 22:15:43 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6FMFhrK027780 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Jul 2014 22:15:43 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Tue, 15 Jul 2014 17:15:43 -0500
From: "Mo Zanaty (mzanaty)" 
To: Colin Perkins , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-15.txt
Thread-Index: AQHPoHpRIAnDxzsOp0y58qQa2VxLcQ==
Date: Tue, 15 Jul 2014 22:15:42 +0000
Message-ID: 
References: <20140528112153.7351.96214.idtracker@ietfa.amsl.com> <5385C8AB.8080606@ericsson.com> <43EF4063-F132-4A4B-BB54-871E93DF1401@csperkins.org>
In-Reply-To: <43EF4063-F132-4A4B-BB54-871E93DF1401@csperkins.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.3.140616
x-originating-ip: [10.82.236.95]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EmxL9jRcltcXeYqBn3JzJZwdmTM
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-15.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 15 Jul 2014 22:15:46 -0000

There is also RFC 6865 Reed Solomon FEC.

Since there are many encoding schemes (parity/LDPC, Raptor/Q, Reed
Solomon), many encoding-dependent variants (1d/2d interleaved, ULP,
staircase, triangle, etc.) and parameters (n,k,etc.), several RTP
packetization and multiplexing options, and several SDP expressions, it
seems premature to make any sort of FEC recommendation without some more
detailed work and discussion.

So I agree with the current draft text.

Mo

-----Original Message-----
From: Colin Perkins 
Date: Tuesday, July 15, 2014 at 11:53 AM
To: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-15.txt

As far as I=B9m aware, the only open issue with the RTP usage draft is
whether it should make some recommendation regarding FEC. The draft
currently states:

=B3There are several block-based FEC schemes that are designed for use with
RTP independent of the chosen RTP payload format.  At the time of this
writing there is no consensus on which, if any, of these FEC schemes is
appropriate for use in the WebRTC context.  Accordingly, this memo makes
no recommendation on the choice of block-based FEC for WebRTC use.=B2

but some people have expressed a desire that it recommend some FEC scheme.
As I understand it, the possible FEC schemes are as follows:

- RFC 2733 =AD parity FEC; requires FEC use same SSRC as original media, so
doesn=B9t work with bundle; abuses RTP header fields for FEC, so can=B9t be
used with mixers

- RFC 5109 =AD parity FEC with uneven level protection (ULP); unnecessary
complexity due to ULP; requires FEC use same SSRC as original media, so
doesn=B9t work with bundle

- SMPTE 2022-1 =AD extends RFC 2733 for 2d interleaved parity FEC; sets CC,
CSRC, and timestamp to zero, so doesn=B9t work with mixers; requires SSRC=
=3D0
and PT=3D96, so can=B9t support >1 FEC stream per RTP session

- RFC 6015 =AD interleaved parity FEC; abuses RTP header fields for FEC, so
can=B9t be used with mixers; works with bundle

- RFC 6682 =AD Raptor FEC; works with bundle

There are IPR declarations on most of these, most have problems with
bundle due to the way they use SSRCs, and some have problems with RTP
mixers due to the way they abuse the CC/CSRC header fields to convey
protection information. Accordingly, I don=B9t see a particularly good
choice for WebRTC, and since we can add FEC in a backwards compatible
manner in a later revision of WebRTC, my proposal is that we leave it out.
However, I=B9m open to other suggestions.

Also, if there are other open issues with the rtp-usage draft that I=B9ve
missed, then please let me know.

Colin






On 28 May 2014, at 12:29, Magnus Westerlund
 wrote:
> WG,
>=20
> This version contains some changes as result of last weeks discussion.
> Especially you who wasn't there should review this to see that you agree
> with the changes proposed.
>=20
> The changes are:
>=20
> - Multi-stream optimization are now a MAY support, MUST signal to use.
>=20
> - The T_rr_interval =3D 4 is now explained in
> draft-ietf-avtcore-rtp-multi-stream, so a reference has been added here.
>=20
> - Signalling of extensions has been clarified to be a MUST
>=20
> - The DoS potential from RTCP configuration that Martin Thomson noticed
> is now discussed and the general consideration that an WebRTC
> implementation needs safe guards among this is present. WG needs to
> consider if it needs more or are sufficient.
>=20
> Cheers
>=20
> Magnus
>=20
> On 2014-05-28 13:21, internet-drafts@ietf.org wrote:
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts
>>directories.
>> This draft is a work item of the Real-Time Communication in
>>WEB-browsers Working Group of the IETF.
>>=20
>>        Title           : Web Real-Time Communication (WebRTC): Media
>>Transport and Use of RTP
>>        Authors         : Colin Perkins
>>                          Magnus Westerlund
>>                          Joerg Ott
>> 	Filename        : draft-ietf-rtcweb-rtp-usage-15.txt
>> 	Pages           : 44
>> 	Date            : 2014-05-28
>>=20
>> Abstract:
>>   The Web Real-Time Communication (WebRTC) framework provides support
>>   for direct interactive rich communication using audio, video, text,
>>   collaboration, games, etc. between two peers' web-browsers.  This
>>   memo describes the media transport aspects of the WebRTC framework.
>>   It specifies how the Real-time Transport Protocol (RTP) is used in
>>   the WebRTC context, and gives requirements for which RTP features,
>>   profiles, and extensions need to be supported.
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/
>>=20
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-15
>>=20
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-15
>>=20
>>=20
>> Please note that it may take a couple of minutes from the time of
>>submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>=20
>>=20
>=20
>=20
> --=20
>=20
> Magnus Westerlund
>=20
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> F=E4r=F6gatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb



--=20
Colin Perkins
http://csperkins.org/



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


From martin.ekblom@icewarp.com  Wed Jul 16 03:20:54 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F111B27F8 for ; Wed, 16 Jul 2014 03:20:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFxcRsOaAq0Y for ; Wed, 16 Jul 2014 03:20:52 -0700 (PDT)
Received: from server.icewarp.com (server.icewarp.com [217.31.57.169]) (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 8B9A61B2B09 for ; Wed, 16 Jul 2014 03:20:50 -0700 (PDT)
Received: from icewarp.com [82.113.48.146] ([127.0.0.1]) by server.icewarp.com (IceWarp 11.1.0.0 (2014-07-07) x64) with ASMTP id 201407161220066695; Wed, 16 Jul 2014 12:20:06 +0200
Date: Wed, 16 Jul 2014 12:20:44 +0200
To: rtcweb@ietf.org,  "Justin Uberti" 
From: "Martin Ekblom" 
Message-ID: <435de87e335b8a0bfa6f843db575873b@icewarp.com>
X-Mailer: IceWarp Mailer 11.1.0.0 (2014-07-07) x64-Desktop
X-Priority: 3
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_435de87e335b8a0bfa6f843db575873b"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QDnCKJotS-swHXKFL1WwuBxCUcU
X-Mailman-Approved-At: Wed, 16 Jul 2014 09:34:08 -0700
Subject: Re: [rtcweb] About the current JSEP-06 draft
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 16 Jul 2014 10:26:51 -0000

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

Hi Justin,

I entirely agree with you. Each media stream will have it's own m=3D line a=
nd extra m=3D lines with recvonly directional attributes should be added fo=
r extra streams wanted. This allows for accepting more streams than sending=
, which is entirely in line with the SDP RFCs.

However, the current JSEP draft misses one small fine point. Reversely, it =
should also (MUST if you read the relevant RFC) allow for sending more stre=
ams than it wants to receive, ie the opposite case of the above, and then s=
end m=3D lines with the directional attribute set to sendonly. RFC 3264 is =
very clear with this: 'If the offerer wishes to only send media on a stream=
 to its peer, it MUST mark the stream as sendonly with the "a=3Dsendonly" a=
ttribute.'

Also as part of the SDP offer/answer exchange the medias that both agents a=
gree not to use should have the m=3D line set to inactive, ie when the offe=
rer states that it wants to receive a media stream with directional attribu=
te recvonly and the answerer indicates that it is unable to send that media=
 by setting the directional attribute to inactive (this media stream will n=
ot be sent in any direction). The ordering and the number of media lines sh=
ould not change during the offer/answer exchange.

Thus I suggest the following changes. Add an item to the list in 4.1.2 (pre=
ferably in the middle):

To convey the intention of sending a media type which is not
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 expected in return (e.g., a video presentati=
on which does not wish
=C2=A0=C2=A0=C2=A0 =C2=A0 to receive video).

Section 5.2.3.2. would be changed as follows:

If the "OfferToReceiveVideo" constraint is specified, with a value of
=C2=A0=C2=A0 "N", the offer MUST include N non-rejected m=3D sections with =
media
=C2=A0=C2=A0 type "video", even if fewer than N video MediaStreamTracks hav=
e been
=C2=A0=C2=A0 added to the PeerConnection. This allows the offerer to receiv=
e
=C2=A0=C2=A0 video, including multiple independent streams, even when not s=
ending
=C2=A0=C2=A0 it; accordingly, the directional attribute on the video m=3D s=
ections
=C2=A0=C2=A0 without associated MediaStreamTracks MUST be set to recvonly. =
If
=C2=A0=C2=A0 this constraint is specified in the case where at least N vide=
o
=C2=A0=C2=A0 MediaStreamTracks have already been added to the PeerConnectio=
n, or N
=C2=A0=C2=A0 non-rejected m=3D sections with media type "video" would other=
wise be
=C2=A0=C2=A0 generated, the offer MUST set the directional attribute to sen=
donly
=C2=A0=C2=A0 for the MediaStreamTracks in the video m=3D section for the re=
maining
=C2=A0=C2=A0 MediaStreamTracks of type video beyond N. The directional attr=
ibute
=C2=A0=C2=A0 for MediaStreamTracks of type video not set to sendonly or rec=
vonly
=C2=A0=C2=A0 SHOULD be set to sendrecv unless inactive. For backwards compa=
tibility,=20
=C2=A0=C2=A0 a value of "true" is interpreted as equivalent to N=3D1 and a =
value of=20
=C2=A0=C2=A0 "false" is interpreted as equivalent to N=3D0.

The change in the paragraph above is mostly clarifying what previously was =
left unexplained with the words "it has no effect" and not touching on how =
to interpret a value of false. Section 5.2.3.1. would need to be changed in=
 a similar way.

These changes would be make it comply with RFC 3264 and 4566 and also be in=
 line with the somewhat unclear w3c spec on WebRTC.

Regards,
Martin Ekblom
Front-end Developer
www.icewarp.com
=C2=A0

-----Original Message-----
From: "Justin Uberti" 
To: rtcweb@ietf.org, martin.ekblom@icewarp.com
Date: 14/07/2014 04:20
Subject: About the current JSEP-06 draft

=C2=A0=C2=A0=C2=A0Adding rtcweb@ietf.org, the right mailing list for this.

This behavior (of OfferToReceiveAudio/Video) was added to be conformant wit=
h Unified Plan, where each media stream requires its own m=3D line, and the=
refore the offerer needs the ability to advertise additional m=3D lines if =
it needs to receive more media streams than it is offering.


I agree that the w3c spec's handling of this topic could be clarified.
=C2=A0
=C2=A0
On Wed, Jul 2, 2014 at 2:37 AM, Martin Ekblom  w=
rote:
Hi,

I believe there is a conceptual misunderstanding in section 5.2.3.1. and 5.=
2.3.2. It seems to contradict the requirements of RFC 3264 / 4566 (SDP offe=
rs and answers) and not be in line with the WebRTC draft. I would like to c=
ontribute to improve or clarify this section, or in case I'm mistaken confi=
rm this.

Is this the appropriate mailing list to disuss this?

Regards,
Martin Ekblom
Front-end Developer
www.icewarp.com


=C2=A0
=C2=A0
=C2=A0
=C2=A0

=C2=A0
=C2=A0


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



Hi Justin,

I entirely agree with=
 you. Each media stream will have it's own m=3D line and extra m=3D lines w=
ith recvonly directional attributes should be added for extra streams wante=
d. This allows for accepting more streams than sending, which is entirely i=
n line with the SDP RFCs.

However, the current JSEP draft misses one=
 small fine point. Reversely, it should also (MUST if you read the relevant=
 RFC) allow for sending more streams than it wants to receive, ie the oppos=
ite case of the above, and then send m=3D lines with the directional attrib=
ute set to sendonly. RFC 3264 is very clear with this: '=
If the offerer wishes to only send media on a stream to its peer, i=
t MUST mark the stream as sendonly with the "a=3Dsendonly" attribute.'

Also as part of the SDP offer/answer exchang=
e the medias that both agents agree not to use should have the m=3D line se=
t to inactive, ie when the offerer states that it wants to receive a media =
stream with directional attribute recvonly and the answerer indicates that =
it is unable to send that media by setting the directional attribute to ina=
ctive (this media stream will not be sent in any direction). The ordering a=
nd the number of media lines should not change during the offer/answer exch=
ange.

Thus I suggest the following changes. Add an item to the list =
in 4.1.2 (preferably in the middle):

=
To convey the intention of sending a media type which is not
  =
;    expected in return (e.g., a video presentation which do=
es not wish
      to receive video).

Section 5.2.3.2. would be changed as follows:
If the "OfferToReceiveVideo" constraint is spe=
cified, with a value of
   "N", the offer MUST include N non-r=
ejected m=3D sections with media
   type "video", even if fewe=
r than N video MediaStreamTracks have been
   added to the Pee=
rConnection. This allows the offerer to receive
   video, incl=
uding multiple independent streams, even when not sending
   i=
t; accordingly, the directional attribute on the video m=3D sections
&nb=
sp;  without associated MediaStreamTracks MUST be set to recvonly. If<=
br>   this constraint is specified in the case where at least N v=
ideo
   MediaStreamTracks have already been added to the PeerC=
onnection, or N
   non-rejected m=3D sections with media type =
"video" would otherwise be
   generated, the offer MUST set=
 the directional attribute to sendonly
   for the MediaStreamT=
racks in the video m=3D section for the remaining
   MediaStre=
amTracks of type video beyond N. The directional attribute
 &nb=
sp; for MediaStreamTracks of type video not set to sendonly or recvonly
=
   SHOULD be set to sendrecv unless inactive. For backwards compa=
tibility,
   a value of "tr=
ue" is interpreted as equivalent to N=3D1 and a value of
  =
 "false" is i=
nterpreted as=
 equivalent to N=3D0.

The change in =
the paragraph above is mostly clarifying what previously was left unexplain=
ed with the words "it has no effect" and not touching on how to interpret a value of fal=
se. Section 5.2.3.1. would need to be changed in a similar way.

Thes=
e changes would be make it comply with RFC 3264 and 4566 and also be in lin=
e with the somewhat unclear w3c spec on WebRTC.

Regards,
Martin Ekblom
Front-end Developer
www.icewarp.com
 




-----Original Message-----
From: "Justin Uberti" <juberti@google.com>
To: rtcweb@ietf.org, martin.ekblom@icewarp.com
Date: 14/07/2014 04:20<=
br>Subject: About the current JSEP-06 draft

 <=
div class=3D"gmail_quote">
 
 
Adding rtcweb@ietf.org, the right mailing list for this.



This behavior (of OfferToReceiveAudio/Video) was added to be conforman=
t with Unified Plan, where each media stream requires its own m=3D line, an=
d therefore the offerer needs the ability to advertise additional m=3D line=
s if it needs to receive more media streams than it is offering.





I agree that the w3c spec's handling of this topic could be clarified.=

 


 
O=
n Wed, Jul 2, 2014 at 2:37 AM, Martin Ekblom <martin.ekblom@icewa=
rp.com> wrote:
Hi,

I=
 believe there is a conceptual misunderstanding in section 5.2.3.1. and 5.2=
.3.2. It seems to contradict the requirements of RFC 3264 / 4566 (SDP offer=
s and answers) and not be in line with the WebRTC draft. I would like to co=
ntribute to improve or clarify this section, or in case I'm mistaken confir=
m this.

Is this the appropriate mailing list to disuss this?

=
Regards,
Martin Ekblom
Front-end Developer
www.icewarp.com




 


 
 


 


 


 



--b1_435de87e335b8a0bfa6f843db575873b--


From nobody Wed Jul 16 11:45:42 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF911A0175 for ; Wed, 16 Jul 2014 11:45:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlcNqoXSZGzx for ; Wed, 16 Jul 2014 11:45:36 -0700 (PDT)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA851A017F for ; Wed, 16 Jul 2014 11:45:35 -0700 (PDT)
Received: by mail-wi0-f174.google.com with SMTP id d1so6634220wiv.7 for ; Wed, 16 Jul 2014 11:45:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=8l+cZeNiGAVMdjfGpDVtrOTPskGnCP79ZnaAsY4D1+I=; b=ew1DSeIFu4zk3o0Vq+hQhg/FkfXUi6AyY4hIgGuAIjX70tcEtD+d1mtWKtt7a91CDM QYF8xaIK+I6MWQQtOwCNI9SE4dSMzDuUdN/8GfTUZSVAs7v2msSiBg2+gn2cA9p/fSaw bU+c7sVTt18onetmPPQ6+xAICo/N61UE1XsFcCtVFJ0XF/tyisBtbGlgF4zoOJLvUYo1 gMVrzprvpE9bxcol8KyeL/VbjTGKbzHY/G1M1uljE8Su8BELd2IFoFcKdWmb+OuAuaH4 /+guA2SZGy+DYRdmg5NKe+6SCdiUXp+aUkSl5yzpzaMhr6mt/RAZgnYU0amawhoNuP6B 5Ikg==
X-Gm-Message-State: ALoCoQlJXCeC0dp9pBBtCdc7NY4lsY/AUsxivGE90pTzDIpgSdQuoPdVwX2G9sa0I0W/7kzUfPkW
X-Received: by 10.180.20.228 with SMTP id q4mr15793986wie.74.1405536328753; Wed, 16 Jul 2014 11:45:28 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx.google.com with ESMTPSA id dj2sm59427436wib.11.2014.07.16.11.45.27 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jul 2014 11:45:27 -0700 (PDT)
Received: by mail-wi0-f172.google.com with SMTP id n3so6703297wiv.11 for ; Wed, 16 Jul 2014 11:45:27 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.92.177 with SMTP id cn17mr39013131wjb.71.1405536327516;  Wed, 16 Jul 2014 11:45:27 -0700 (PDT)
Received: by 10.217.131.17 with HTTP; Wed, 16 Jul 2014 11:45:27 -0700 (PDT)
Date: Wed, 16 Jul 2014 14:45:27 -0400
Message-ID: 
From: Roman Shpount 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7beb91aa854e6604fe53edc2
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/iYKrNuitTv-Lks7ePZOCJrusWy8
Subject: [rtcweb] Rate for telephone-events in combination with OPUS
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 16 Jul 2014 18:45:39 -0000

--047d7beb91aa854e6604fe53edc2
Content-Type: text/plain; charset=UTF-8

Should we specify two telephone-events payloads, one with 8000 rate to be
used with PCMU/PCMA and another with 48000 rate to be used with OPUS?

>From what I can see, based on RFC 7160, if OPUS codec is used
telephone-events should either be transmitted with the rate 48Khz or use a
different SSRC. On the other hand if PCMU/PCMA is selected then DTMF should
be transmitted using 8000 clock or use a different SSRC. Using different
SSRC is problematic since it will create synchronization issues with audio
playback (things like record your name and press pound will stop working)
apart from other webrtc related issues. I think the only solution that
makes sense is to advertise two telephone-events payloads and use the
appropriate one based on the selected transmit codec, similar to CN.
_____________
Roman Shpount

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


Should we specify two telephone-events payloads, one with =
8000 rate to be used with PCMU/PCMA and another with 48000 rate to be used =
with OPUS?

From what I can see, based on=C2=A0RFC 7160, if OPU=
S codec is used telephone-events should either be transmitted with the rate=
 48Khz or use a different SSRC. On the other hand if PCMU/PCMA is selected =
then DTMF should be transmitted using 8000 clock or use a different SSRC. U=
sing different SSRC is problematic since it will create synchronization iss=
ues with audio playback (things like record your name and press pound will =
stop working) apart from other webrtc related issues. I think the only solu=
tion that makes sense is to advertise two telephone-events payloads and use=
 the appropriate one based on the selected transmit codec, similar to CN.

_____________
Roman Shpount




--047d7beb91aa854e6604fe53edc2--


From nobody Wed Jul 16 20:13:39 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3EB1A04E7 for ; Wed, 16 Jul 2014 20:13:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.929
X-Spam-Level: 
X-Spam-Status: No, score=-3.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhGFlKz2LBAl for ; Wed, 16 Jul 2014 20:13:36 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (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 CC7BE1A04FA for ; Wed, 16 Jul 2014 20:13:36 -0700 (PDT)
Received: from [172.17.0.43] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 208E1F28CF for ; Wed, 16 Jul 2014 20:13:35 -0700 (PDT)
Message-ID: <53C73F5E.9020407@mozilla.com>
Date: Wed, 16 Jul 2014 20:13:34 -0700
From: "Timothy B. Terriberry" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/O_r1BeEklsCuN8txTqupv_kphN8
Subject: Re: [rtcweb] Rate for telephone-events in combination with OPUS
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Jul 2014 03:13:38 -0000

Roman Shpount wrote:
> will stop working) apart from other webrtc related issues. I think the
> only solution that makes sense is to advertise two telephone-events
> payloads and use the appropriate one based on the selected transmit
> codec, similar to CN.

That's what we agreed to on this list in June 2012 [1].

[1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04598.html


From nobody Wed Jul 16 20:14:14 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D31E1A0545 for ; Wed, 16 Jul 2014 20:14:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level: 
X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xm-51qByU5Md for ; Wed, 16 Jul 2014 20:14:12 -0700 (PDT)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7C0E1A053B for ; Wed, 16 Jul 2014 20:14:11 -0700 (PDT)
Received: by mail-oi0-f47.google.com with SMTP id x69so570598oia.34 for ; Wed, 16 Jul 2014 20:14:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kMksDNvpEHuSEvwSDh81itXIbdLph1jbBSi1QALDw30=; b=jSgYfmDSdc7QNQuOkEmE9dnHjR6f38fGi56Kgicxuwats+XTxJ5XvLYuzA6S/IFkXK XMvPDkh7nVTHno1qE+hAiZZiyVmSb4LSRalCvuOCXzifjH18V29uRDYLyySq6OkbAieD Ia2huw8VEB5XNsX9/g+yvb1N3cCc0jkK9t7c9xMrGAS+YBe7VQKRU1oWQb3/7sKLCFpM 3GY33UNSU1/RdcQRSCDLblJULxPdJThVPKd9orTGkBwW/HNa5KaUJmN2ok97tewVA2Wy 4UG7JHnXcKcD2+9Y1s1hq5w2MA4Sr0KYAw0tssnFkawPVaYfOreOhlEvSCnRsQtjN7lM UoMw==
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:content-type; bh=kMksDNvpEHuSEvwSDh81itXIbdLph1jbBSi1QALDw30=; b=VRYV6XjPkJuko6i20+Jx1KNrZL6etpTKEo9M0ZPoJYrTYb8CLxTFDbpTOQbSak6urF WrtlUyumKKfMoyNqNSg881LxzK+Z9kv8jbnBmejC/GXldBRWtMKnxbXHDKSgYmBZr7OD 8THfrxo8iiz5M+t4J5P8UWuCyhAY9un1XBXbndwlC4Oq9dD7wcw0EndAUyWqpr0/Bhao SrTG9VO/DmrMWBn8gtgjARvxyXmUWhI5Rbz8qk03IK9GLzfBQ6chLTqR2HQpdg+tCR7G 8gFTGYBPle6jjcZOmqZfQNVvXMn01iNZTlkiNUQZ3ilVJ+zqyT1YIvgsLink9OLCO+ah K8rQ==
X-Gm-Message-State: ALoCoQleLNxEvVEo1WCg79rkb5GYtek+4kKAvTnWk5YjvGd7BaKg1lBTUK0kT8lkVYCGHIzDI510
X-Received: by 10.182.102.197 with SMTP id fq5mr39514700obb.3.1405566851241; Wed, 16 Jul 2014 20:14:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.251.230 with HTTP; Wed, 16 Jul 2014 20:13:51 -0700 (PDT)
In-Reply-To: 
References: 
From: Justin Uberti 
Date: Wed, 16 Jul 2014 23:13:51 -0400
Message-ID: 
To: Roman Shpount 
Content-Type: multipart/alternative; boundary=089e012949b6e0832604fe5b0836
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/w6TBaxiJ8Wh1YFFHCOyNrWTQ0fY
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Rate for telephone-events in combination with OPUS
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Jul 2014 03:14:13 -0000

--089e012949b6e0832604fe5b0836
Content-Type: text/plain; charset=UTF-8

Yes, this is my understanding as well.


On Wed, Jul 16, 2014 at 2:45 PM, Roman Shpount  wrote:

> Should we specify two telephone-events payloads, one with 8000 rate to be
> used with PCMU/PCMA and another with 48000 rate to be used with OPUS?
>
> From what I can see, based on RFC 7160, if OPUS codec is used
> telephone-events should either be transmitted with the rate 48Khz or use a
> different SSRC. On the other hand if PCMU/PCMA is selected then DTMF should
> be transmitted using 8000 clock or use a different SSRC. Using different
> SSRC is problematic since it will create synchronization issues with audio
> playback (things like record your name and press pound will stop working)
> apart from other webrtc related issues. I think the only solution that
> makes sense is to advertise two telephone-events payloads and use the
> appropriate one based on the selected transmit codec, similar to CN.
> _____________
> Roman Shpount
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

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


Yes, this is my understanding as well.


On Wed, Jul 16, 2014 at 2:4=
5 PM, Roman Shpount <roman@telurix.com> wrote:



Should we specify two telep=
hone-events payloads, one with 8000 rate to be used with PCMU/PCMA and anot=
her with 48000 rate to be used with OPUS?



From what I can see, based on=C2=A0RFC 7160, if OPUS codec is used=
 telephone-events should either be transmitted with the rate 48Khz or use a=
 different SSRC. On the other hand if PCMU/PCMA is selected then DTMF shoul=
d be transmitted using 8000 clock or use a different SSRC. Using different =
SSRC is problematic since it will create synchronization issues with audio =
playback (things like record your name and press pound will stop working) a=
part from other webrtc related issues. I think the only solution that makes=
 sense is to advertise two telephone-events payloads and use the appropriat=
e one based on the selected transmit codec, similar to CN.




_____________
Roman =
Shpount




_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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





--089e012949b6e0832604fe5b0836--


From nobody Wed Jul 16 20:16:35 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D751A04F6 for ; Wed, 16 Jul 2014 20:16:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level: 
X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qb3ggeB9nGgR for ; Wed, 16 Jul 2014 20:16:30 -0700 (PDT)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C1F71A04E7 for ; Wed, 16 Jul 2014 20:16:29 -0700 (PDT)
Received: by mail-ie0-f176.google.com with SMTP id tr6so1983070ieb.21 for ; Wed, 16 Jul 2014 20:16:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0d0IYKRkng9kj0DGGXDGbPH8mwtF6kBMAX0qtm1M4+g=; b=LV3Z6S2t1x3vsNvunvvn1lyrN87YmSNgPMDBVtsfXQVPILkplgVWT3SKnGRpauBTZM LSPAeqdjqoIOrATbUpHgnD38Q9TDhbLMlhGTh2DnyQFIMS5vEHEOSryTzWAzKAOzLrK4 Uzn/7PuTrmiMAt2HKDd06jXfGUlNWPvW0M877/6UPGOcir5HbqBBW8dAf5W4q4ygBy5X SZQq7ZxDuxiBBWSLWu2zU2CwIEDA5STLoqJ/3AoWof7h7osBt6qY3dmjOandQ79GtprJ 4SuzOtsh9H+Ul67fxEjt7tGdUkw8R7Z4FWXRQA3M/lZEvfgquSJRxYXxXaxk0Va4h2dS Jlwg==
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:content-type; bh=0d0IYKRkng9kj0DGGXDGbPH8mwtF6kBMAX0qtm1M4+g=; b=cUUUeOQ4y1D1/4zPY1Q2Uio5Kx1a0MumNTOAoXnnRfKTr11G5XsnRSW99TteFzbZge dlWkIIJSuU/yO4z1+Opt96l7FUvo/f12FSZwupJZbLLUFOia4fG4RtSmUftBYC9bfAZG NotsvMtHtPbVdvPeCBp4BeU9Gib6/Pz31WTCkFQU246QCJy000ajxL3SIf8DjCGoLrbC X7Iuv/zMW/hVxNzDsIbws40XXjwXLSy5WtNqePKSgEzwyEBxxUZs1ZzG1M/dz2GTnwg9 kqabs9Ifj6EE78YD7gg+ixekniBlLSL7PpuMkXeJERiTGrNRmDwvK8jLr72pGs2dFUbQ riHA==
X-Gm-Message-State: ALoCoQm+4V9ELE8oAKucrm91IHCpI2E2sdcMaSbN32G2bi8ZG/ceixi5mcUU0fR1VQ/o0UyAN/GJ
X-Received: by 10.60.161.136 with SMTP id xs8mr17319881oeb.42.1405566989142; Wed, 16 Jul 2014 20:16:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.251.230 with HTTP; Wed, 16 Jul 2014 20:16:08 -0700 (PDT)
In-Reply-To: 
References: <20140528112153.7351.96214.idtracker@ietfa.amsl.com> <5385C8AB.8080606@ericsson.com> <43EF4063-F132-4A4B-BB54-871E93DF1401@csperkins.org> 
From: Justin Uberti 
Date: Wed, 16 Jul 2014 23:16:08 -0400
Message-ID: 
To: "Mo Zanaty (mzanaty)" 
Content-Type: multipart/alternative; boundary=089e01183a1818b9b804fe5b1159
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/J1-n4VYuiRZDVOEPCVEjU3cBMQA
Cc: "rtcweb@ietf.org" , Colin Perkins 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-15.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Jul 2014 03:16:33 -0000

--089e01183a1818b9b804fe5b1159
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

In DC we talked about making a baseline FEC proposal using 5109. Other
variants could be added in the future, but 5109 would be MTI.

I still need to write up said proposal though, including explaining how it
works with BUNDLE (it can do so fairly easily)


On Tue, Jul 15, 2014 at 6:15 PM, Mo Zanaty (mzanaty) 
wrote:

> There is also RFC 6865 Reed Solomon FEC.
>
> Since there are many encoding schemes (parity/LDPC, Raptor/Q, Reed
> Solomon), many encoding-dependent variants (1d/2d interleaved, ULP,
> staircase, triangle, etc.) and parameters (n,k,etc.), several RTP
> packetization and multiplexing options, and several SDP expressions, it
> seems premature to make any sort of FEC recommendation without some more
> detailed work and discussion.
>
> So I agree with the current draft text.
>
> Mo
>
> -----Original Message-----
> From: Colin Perkins 
> Date: Tuesday, July 15, 2014 at 11:53 AM
> To: "rtcweb@ietf.org" 
> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-15.txt
>
> As far as I=C2=B9m aware, the only open issue with the RTP usage draft is
> whether it should make some recommendation regarding FEC. The draft
> currently states:
>
> =C2=B3There are several block-based FEC schemes that are designed for use=
 with
> RTP independent of the chosen RTP payload format.  At the time of this
> writing there is no consensus on which, if any, of these FEC schemes is
> appropriate for use in the WebRTC context.  Accordingly, this memo makes
> no recommendation on the choice of block-based FEC for WebRTC use.=C2=B2
>
> but some people have expressed a desire that it recommend some FEC scheme=
.
> As I understand it, the possible FEC schemes are as follows:
>
> - RFC 2733 =C2=AD parity FEC; requires FEC use same SSRC as original medi=
a, so
> doesn=C2=B9t work with bundle; abuses RTP header fields for FEC, so can=
=C2=B9t be
> used with mixers
>
> - RFC 5109 =C2=AD parity FEC with uneven level protection (ULP); unnecess=
ary
> complexity due to ULP; requires FEC use same SSRC as original media, so
> doesn=C2=B9t work with bundle
>
> - SMPTE 2022-1 =C2=AD extends RFC 2733 for 2d interleaved parity FEC; set=
s CC,
> CSRC, and timestamp to zero, so doesn=C2=B9t work with mixers; requires S=
SRC=3D0
> and PT=3D96, so can=C2=B9t support >1 FEC stream per RTP session
>
> - RFC 6015 =C2=AD interleaved parity FEC; abuses RTP header fields for FE=
C, so
> can=C2=B9t be used with mixers; works with bundle
>
> - RFC 6682 =C2=AD Raptor FEC; works with bundle
>
> There are IPR declarations on most of these, most have problems with
> bundle due to the way they use SSRCs, and some have problems with RTP
> mixers due to the way they abuse the CC/CSRC header fields to convey
> protection information. Accordingly, I don=C2=B9t see a particularly good
> choice for WebRTC, and since we can add FEC in a backwards compatible
> manner in a later revision of WebRTC, my proposal is that we leave it out=
.
> However, I=C2=B9m open to other suggestions.
>
> Also, if there are other open issues with the rtp-usage draft that I=C2=
=B9ve
> missed, then please let me know.
>
> Colin
>
>
>
>
>
>
> On 28 May 2014, at 12:29, Magnus Westerlund
>  wrote:
> > WG,
> >
> > This version contains some changes as result of last weeks discussion.
> > Especially you who wasn't there should review this to see that you agre=
e
> > with the changes proposed.
> >
> > The changes are:
> >
> > - Multi-stream optimization are now a MAY support, MUST signal to use.
> >
> > - The T_rr_interval =3D 4 is now explained in
> > draft-ietf-avtcore-rtp-multi-stream, so a reference has been added here=
.
> >
> > - Signalling of extensions has been clarified to be a MUST
> >
> > - The DoS potential from RTCP configuration that Martin Thomson noticed
> > is now discussed and the general consideration that an WebRTC
> > implementation needs safe guards among this is present. WG needs to
> > consider if it needs more or are sufficient.
> >
> > Cheers
> >
> > Magnus
> >
> > On 2014-05-28 13:21, internet-drafts@ietf.org wrote:
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> >>directories.
> >> This draft is a work item of the Real-Time Communication in
> >>WEB-browsers Working Group of the IETF.
> >>
> >>        Title           : Web Real-Time Communication (WebRTC): Media
> >>Transport and Use of RTP
> >>        Authors         : Colin Perkins
> >>                          Magnus Westerlund
> >>                          Joerg Ott
> >>      Filename        : draft-ietf-rtcweb-rtp-usage-15.txt
> >>      Pages           : 44
> >>      Date            : 2014-05-28
> >>
> >> Abstract:
> >>   The Web Real-Time Communication (WebRTC) framework provides support
> >>   for direct interactive rich communication using audio, video, text,
> >>   collaboration, games, etc. between two peers' web-browsers.  This
> >>   memo describes the media transport aspects of the WebRTC framework.
> >>   It specifies how the Real-time Transport Protocol (RTP) is used in
> >>   the WebRTC context, and gives requirements for which RTP features,
> >>   profiles, and extensions need to be supported.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/
> >>
> >> There's also a htmlized version available at:
> >> http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-15
> >>
> >> A diff from the previous version is available at:
> >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-15
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> >>submission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >> _______________________________________________
> >> rtcweb mailing list
> >> rtcweb@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >>
> >>
> >
> >
> > --
> >
> > Magnus Westerlund
> >
> > ----------------------------------------------------------------------
> > Services, Media and Network features, Ericsson Research EAB/TXM
> > ----------------------------------------------------------------------
> > Ericsson AB                 | Phone  +46 10 7148287
> > F=C3=A4r=C3=B6gatan 6                 | Mobile +46 73 0949079
> > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> > ----------------------------------------------------------------------
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> --
> Colin Perkins
> http://csperkins.org/
>
>
>
> _______________________________________________
> 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
>

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


In DC we talked about making a baseline FEC proposal using=
 5109. Other variants could be added in the future, but 5109 would be MTI.<=
div>
I still need to write up said proposal though, including=
 explaining how it works with BUNDLE (it can do so fairly easily)





On Tue,=
 Jul 15, 2014 at 6:15 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:



There is also RFC 6865 Reed Solomon FEC.



Since there are many encoding schemes (parity/LDPC, Raptor/Q, Reed

Solomon), many encoding-dependent variants (1d/2d interleaved, ULP,

staircase, triangle, etc.) and parameters (n,k,etc.), several RTP

packetization and multiplexing options, and several SDP expressions, it

seems premature to make any sort of FEC recommendation without some more
detailed work and discussion.



So I agree with the current draft text.



Mo




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

From: Colin Perkins <csp@csperkins.=
org>

Date: Tuesday, July 15, 2014 at 11:53 AM

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

Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-15.txt



As far as I=C2=B9m aware, the only open issue with the RTP usage draft is
whether it should make some recommendation regarding FEC. The draft

currently states:



=C2=B3There are several block-based FEC schemes that are designed for use w=
ith

RTP independent of the chosen RTP payload format. =C2=A0At the time of this=


writing there is no consensus on which, if any, of these FEC schemes is

appropriate for use in the WebRTC context. =C2=A0Accordingly, this memo mak=
es

no recommendation on the choice of block-based FEC for WebRTC use.=C2=B2


but some people have expressed a desire that it recommend some FEC scheme.<=
br>
As I understand it, the possible FEC schemes are as follows:



- RFC 2733 =C2=AD parity FEC; requires FEC use same SSRC as original media,=
 so

doesn=C2=B9t work with bundle; abuses RTP header fields for FEC, so can=C2=
=B9t be

used with mixers



- RFC 5109 =C2=AD parity FEC with uneven level protection (ULP); unnecessar=
y

complexity due to ULP; requires FEC use same SSRC as original media, so

doesn=C2=B9t work with bundle



- SMPTE 2022-1 =C2=AD extends RFC 2733 for 2d interleaved parity FEC; sets =
CC,

CSRC, and timestamp to zero, so doesn=C2=B9t work with mixers; requires SSR=
C=3D0

and PT=3D96, so can=C2=B9t support >1 FEC stream per RTP session



- RFC 6015 =C2=AD interleaved parity FEC; abuses RTP header fields for FEC,=
 so

can=C2=B9t be used with mixers; works with bundle



- RFC 6682 =C2=AD Raptor FEC; works with bundle



There are IPR declarations on most of these, most have problems with

bundle due to the way they use SSRCs, and some have problems with RTP

mixers due to the way they abuse the CC/CSRC header fields to convey

protection information. Accordingly, I don=C2=B9t see a particularly good
choice for WebRTC, and since we can add FEC in a backwards compatible

manner in a later revision of WebRTC, my proposal is that we leave it out.<=
br>
However, I=C2=B9m open to other suggestions.



Also, if there are other open issues with the rtp-usage draft that I=C2=B9v=
e

missed, then please let me know.



Colin













On 28 May 2014, at 12:29, Magnus Westerlund

<magnus.westerlund@eri=
csson.com> wrote:

> WG,

>

> This version contains some changes as result of last weeks discussion.=


> Especially you who wasn't there should review this to see that you=
 agree

> with the changes proposed.

>

> The changes are:

>

> - Multi-stream optimization are now a MAY support, MUST signal to use.=


>

> - The T_rr_interval =3D 4 is now explained in

> draft-ietf-avtcore-rtp-multi-stream, so a reference has been added her=
e.

>

> - Signalling of extensions has been clarified to be a MUST

>

> - The DoS potential from RTCP configuration that Martin Thomson notice=
d

> is now discussed and the general consideration that an WebRTC

> implementation needs safe guards among this is present. WG needs to
> consider if it needs more or are sufficient.

>

> Cheers

>

> Magnus

>

> On 2014-05-28 13:21, inter=
net-drafts@ietf.org wrote:

>>

>> A New Internet-Draft is available from the on-line Internet-Drafts=


>>directories.

>> This draft is a work item of the Real-Time Communication in

>>WEB-browsers Working Group of the IETF.

>>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 : Web Real-Time Communication (WebRTC): Media

>>Transport and Use of RTP

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : C=
olin Perkins

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0Magnus Westerlund

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0Joerg Ott

>> =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-ie=
tf-rtcweb-rtp-usage-15.txt

>> =C2=A0 =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 44<=
br>
>> =C2=A0 =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
: 2014-05-28

>>

>> Abstract:

>> =C2=A0 The Web Real-Time Communication (WebRTC) framework provides=
 support

>> =C2=A0 for direct interactive rich communication using audio, vide=
o, text,

>> =C2=A0 collaboration, games, etc. between two peers' web-brows=
ers. =C2=A0This

>> =C2=A0 memo describes the media transport aspects of the WebRTC fr=
amework.

>> =C2=A0 It specifies how the Real-time Transport Protocol (RTP) is =
used in

>> =C2=A0 the WebRTC context, and gives requirements for which RTP fe=
atures,

>> =C2=A0 profiles, and extensions need to be supported.

>>

>>

>> The IETF datatracker status page for this draft is:

>> https://datatracker.ietf.org/doc/draft-ietf-rtcwe=
b-rtp-usage/

>>

>> There's also a htmlized version available at:

>> http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usag=
e-15

>>

>> A diff from the previous version is available at:

>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf=
-rtcweb-rtp-usage-15

>>

>>

>> Please note that it may take a couple of minutes from the time of<=
br>
>>submission

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

>>

>> Internet-Drafts are also available by anonymous FTP at:

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

>>

>> _______________________________________________

>> rtcweb mailing list

>> rtcweb@ietf.org

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

>>

>>

>

>

> --

>

> Magnus Westerlund

>

> ----------------------------------------------------------------------=


> Services, Media and Network features, Ericsson Research EAB/TXM

> ----------------------------------------------------------------------=


> Ericsson AB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =
Phone =C2=A0+46=
 10 7148287

> F=C3=A4r=C3=B6gatan 6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 | Mobile +46 73 0949079

> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com

> ----------------------------------------------------------------------=


>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

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







--

Colin Perkins

http://csperkins.org/







_______________________________________________

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





--089e01183a1818b9b804fe5b1159--


From nobody Wed Jul 16 20:20:56 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3221A0505 for ; Wed, 16 Jul 2014 20:20:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level: 
X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmq5rYdNdgLp for ; Wed, 16 Jul 2014 20:20:52 -0700 (PDT)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D0FE1A04F6 for ; Wed, 16 Jul 2014 20:20:52 -0700 (PDT)
Received: by mail-ie0-f174.google.com with SMTP id rp18so2017440iec.19 for ; Wed, 16 Jul 2014 20:20:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SCN2xwP5EroUHH098kUrLgo1TjRpuKNNn5w1FZAhA0U=; b=nJQhciApTJY1TIE9l5VUBrcWUANq1DxeW+vB6QXEYxRhe+cuuw2Ptg3t9sUmx8WaE7 ZIrjRrK2Hjcs3w0Dp+SOctMUxkglt8sZbMl147zqeTpiD4cHsUJ9liMnktDzy6+Hc9bL rCuCc5Vt4144MYy19GRTRr6ZYCVSDBzliQ+RcUKeF7L30EEHCjsNXca4fTiYma1bByxp yNnVNlyUntPBA/QHITTWUw7DhmAA1DouZlMCnc1/qwOIOig4FvScCcHUuz9DdAt5QGbW /S9NJMy01+pBvD5SmzqK4RQymtqKTAUh09QJ7CulEz5C8gBb3qHXouWjrXLKetwmvIZ7 M7LA==
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:content-type; bh=SCN2xwP5EroUHH098kUrLgo1TjRpuKNNn5w1FZAhA0U=; b=gsvQ+icp4c095+sXYjjd7v4S2gb/FQp4nHYRmVrvnuaPslFRMY0xT79d/7LS6c98Sf 8TSCebGGbiJ1VWTb0/YF0I+npwrDe7ckOwwzDoBIclNh84KqTv+c1B/S4KNSOIHcuNWB SZI15JsEvKquNgOAm9ekviUYYOjlwkQKksBWh7Xq4GOYYKx95lwsm3azFNSaz3Bv6z/1 V5vq2xjfxBQh+PgA2+ZswiZ7X6VQ9eGt6CVhLR19kr/g6kU/iMHk+5rDJs+JSV7bZ2i9 q17HNT49AhjloyqfFEr3X+15kfiRAOroNgiesNh6Wqr0g+4iKWg3cCrR//wfjR2c74xO Yq7Q==
X-Gm-Message-State: ALoCoQnggtI3MZg9AelqqG+3vg5gTKfGlScGLH7xtnSkOJghCbx8kx5TKQq0ZFl3vLoMl0MzLbiv
X-Received: by 10.60.146.228 with SMTP id tf4mr32650218oeb.37.1405567251668; Wed, 16 Jul 2014 20:20:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.251.230 with HTTP; Wed, 16 Jul 2014 20:20:31 -0700 (PDT)
In-Reply-To: <5385C8AB.8080606@ericsson.com>
References: <20140528112153.7351.96214.idtracker@ietfa.amsl.com> <5385C8AB.8080606@ericsson.com>
From: Justin Uberti 
Date: Wed, 16 Jul 2014 23:20:31 -0400
Message-ID: 
To: Magnus Westerlund 
Content-Type: multipart/alternative; boundary=047d7b5d98efbe7b8e04fe5b20ff
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/S-0a4xCON-96hg1or1wL4w3xkPc
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-15.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Jul 2014 03:20:54 -0000

--047d7b5d98efbe7b8e04fe5b20ff
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

One thing that has come up while discussing JSEP is the need to specify
handling of DTX in the RTP usage document. JSEP allows applications to ask
for DTX, so this needs to be supported in all implementations to give
deterministic behavior.

While Opus has the ability to support DTX internally, we also need to make
sure this works with other codecs, including G.711. As a result, I think
the RTP usage draft needs to specify RFC 3389 support as
mandatory-to-implement, so that applications can deterministically enable
DTX in all cases.


On Wed, May 28, 2014 at 7:29 AM, Magnus Westerlund <
magnus.westerlund@ericsson.com> wrote:

> WG,
>
> This version contains some changes as result of last weeks discussion.
> Especially you who wasn't there should review this to see that you agree
> with the changes proposed.
>
> The changes are:
>
> - Multi-stream optimization are now a MAY support, MUST signal to use.
>
> - The T_rr_interval =3D 4 is now explained in
> draft-ietf-avtcore-rtp-multi-stream, so a reference has been added here.
>
> - Signalling of extensions has been clarified to be a MUST
>
> - The DoS potential from RTCP configuration that Martin Thomson noticed
> is now discussed and the general consideration that an WebRTC
> implementation needs safe guards among this is present. WG needs to
> consider if it needs more or are sufficient.
>
> Cheers
>
> Magnus
>
> On 2014-05-28 13:21, internet-drafts@ietf.org wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >  This draft is a work item of the Real-Time Communication in
> WEB-browsers Working Group of the IETF.
> >
> >         Title           : Web Real-Time Communication (WebRTC): Media
> Transport and Use of RTP
> >         Authors         : Colin Perkins
> >                           Magnus Westerlund
> >                           Joerg Ott
> >       Filename        : draft-ietf-rtcweb-rtp-usage-15.txt
> >       Pages           : 44
> >       Date            : 2014-05-28
> >
> > Abstract:
> >    The Web Real-Time Communication (WebRTC) framework provides support
> >    for direct interactive rich communication using audio, video, text,
> >    collaboration, games, etc. between two peers' web-browsers.  This
> >    memo describes the media transport aspects of the WebRTC framework.
> >    It specifies how the Real-time Transport Protocol (RTP) is used in
> >    the WebRTC context, and gives requirements for which RTP features,
> >    profiles, and extensions need to be supported.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-15
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-15
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
>
>
> --
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> F=C3=A4r=C3=B6gatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

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


One thing that has come up while discussing JSEP is the ne=
ed to specify handling of DTX in the RTP usage document. JSEP allows applic=
ations to ask for DTX, so this needs to be supported in all implementations=
 to give deterministic behavior.



While Opus has the ability to support DTX internally, we als=
o need to make sure this works with other codecs, including G.711. As a res=
ult, I think the RTP usage draft needs to specify RFC 3389 support as manda=
tory-to-implement, so that applications can deterministically enable DTX in=
 all cases.





On Wed,=
 May 28, 2014 at 7:29 AM, Magnus Westerlund <magnus.westerl=
und@ericsson.com> wrote:



WG,



This version contains some changes as result of last weeks discussion.

Especially you who wasn't there should review this to see that you agre=
e

with the changes proposed.



The changes are:



- Multi-stream optimization are now a MAY support, MUST signal to use.



- The T_rr_interval =3D 4 is now explained in

draft-ietf-avtcore-rtp-multi-stream, so a reference has been added here.


- Signalling of extensions has been clarified to be a MUST



- The DoS potential from RTCP configuration that Martin Thomson noticed

is now discussed and the general consideration that an WebRTC

implementation needs safe guards among this is present. WG needs to

consider if it needs more or are sufficient.



Cheers



Magnus




On 2014-05-28 13:21, internet-d=
rafts@ietf.org wrote:

>

> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.

> =C2=A0This draft is a work item of the Real-Time Communication in WEB-=
browsers Working Group of the IETF.

>

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 Web Real-Time Communication (WebRTC): Media Transport and Use of RTP

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Coli=
n Perkins

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 Magnus Westerlund

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 Joerg Ott

> =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-ietf-=
rtcweb-rtp-usage-15.txt

> =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 44

> =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 2=
014-05-28

>

> Abstract:

> =C2=A0 =C2=A0The Web Real-Time Communication (WebRTC) framework provid=
es support

> =C2=A0 =C2=A0for direct interactive rich communication using audio, vi=
deo, text,

> =C2=A0 =C2=A0collaboration, games, etc. between two peers' web-bro=
wsers. =C2=A0This

> =C2=A0 =C2=A0memo describes the media transport aspects of the WebRTC =
framework.

> =C2=A0 =C2=A0It specifies how the Real-time Transport Protocol (RTP) i=
s used in

> =C2=A0 =C2=A0the WebRTC context, and gives requirements for which RTP =
features,

> =C2=A0 =C2=A0profiles, and extensions need to be supported.

>

>

> The IETF datatracker status page for this draft is:

> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rt=
p-usage/

>

> There's also a htmlized version available at:

> http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-15=


>

> A diff from the previous version is available at:

> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtc=
web-rtp-usage-15

>

>

> Please note that it may take a couple of minutes from the time of subm=
ission

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

>

> Internet-Drafts are also available by anonymous FTP at:

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

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

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

>

>






--



Magnus Westerlund



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

Services, Media and Network features, Ericsson Research EAB/TXM

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

Ericsson AB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Phone=
 =C2=A0+46 10 7=
148287

F=C3=A4r=C3=B6gatan 6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | Mobile +4=
6 73 0949079

SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com

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




_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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





--047d7b5d98efbe7b8e04fe5b20ff--


From nobody Wed Jul 16 20:48:30 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414FF1A04E7 for ; Wed, 16 Jul 2014 20:48:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENdU6jCAzAxt for ; Wed, 16 Jul 2014 20:48:25 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E6241A03D7 for ; Wed, 16 Jul 2014 20:48:25 -0700 (PDT)
Received: by mail-wi0-f172.google.com with SMTP id n3so7187796wiv.17 for ; Wed, 16 Jul 2014 20:48:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jokJDzlCUFqbLeC0Xhj3CeC/lgy8mLRESORzE2DmxeE=; b=a66LSI/QNQYRv1z+J5v9TH4teyotxpI5VT8KqNgIeZAuj1X8qxzbxQTPEfvet5NdcE bJBgN2zTkgGGpYV+NMP8uvc0UpU4fFDH+E/IrepINRTynJ6RvFRlyZXadK1YsbK6N3Se ezYrVj+pNTtJOFNDgfCRyCrmlvMJ0fRsfVH5OnOuTHdjdgHeUErtwQgslWinKNM2gwEf H4+ER2ZZcESpHPL2XPH6GLTlyFc2jO1rKpl6Yw/gWyah8Mi82wZkEDlKn5MlbhH02B5L pi3gj+BcE0543GUhcYbiJcIxuX2G2BXyV3Wu767HpbljvD+FiJPChpebyzBWNCevrYZ/ QRVg==
X-Gm-Message-State: ALoCoQm47baF6dPV7/1iEpXsn5F5NfUXF7FeW0e95s/h5768zA2iWAGoiOwIHriUYeZP948FpwVk
X-Received: by 10.194.76.212 with SMTP id m20mr41183580wjw.30.1405568903797; Wed, 16 Jul 2014 20:48:23 -0700 (PDT)
Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by mx.google.com with ESMTPSA id mv3sm63720268wic.21.2014.07.16.20.48.22 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jul 2014 20:48:22 -0700 (PDT)
Received: by mail-we0-f177.google.com with SMTP id w62so1686551wes.8 for ; Wed, 16 Jul 2014 20:48:22 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.19.138 with SMTP id f10mr19001169wie.38.1405568902559; Wed, 16 Jul 2014 20:48:22 -0700 (PDT)
Received: by 10.217.131.17 with HTTP; Wed, 16 Jul 2014 20:48:22 -0700 (PDT)
Received: by 10.217.131.17 with HTTP; Wed, 16 Jul 2014 20:48:22 -0700 (PDT)
In-Reply-To: 
References:  
Date: Wed, 16 Jul 2014 23:48:22 -0400
Message-ID: 
From: Roman Shpount 
To: Justin Uberti 
Content-Type: multipart/alternative; boundary=bcaec53d550d24fee204fe5b83e9
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VhC-j29Dl44VuC1Y-uKAsnElVDw
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Rate for telephone-events in combination with OPUS
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Jul 2014 03:48:27 -0000

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

So, I guess the fact that neither Chrome no Firefox do this is an oversight
or an unimplemented feature.
On Jul 16, 2014 11:14 PM, "Justin Uberti"  wrote:

> Yes, this is my understanding as well.
>
>
> On Wed, Jul 16, 2014 at 2:45 PM, Roman Shpount  wrote:
>
>> Should we specify two telephone-events payloads, one with 8000 rate to be
>> used with PCMU/PCMA and another with 48000 rate to be used with OPUS?
>>
>> From what I can see, based on RFC 7160, if OPUS codec is used
>> telephone-events should either be transmitted with the rate 48Khz or use a
>> different SSRC. On the other hand if PCMU/PCMA is selected then DTMF should
>> be transmitted using 8000 clock or use a different SSRC. Using different
>> SSRC is problematic since it will create synchronization issues with audio
>> playback (things like record your name and press pound will stop working)
>> apart from other webrtc related issues. I think the only solution that
>> makes sense is to advertise two telephone-events payloads and use the
>> appropriate one based on the selected transmit codec, similar to CN.
>> _____________
>> Roman Shpount
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>

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


So, I guess the fact that neither Chrome no Firefox do this =
is an oversight or an unimplemented feature.


On Jul 16, 2014 11:14 PM, "Justin Uberti&qu=
ot; <juberti@google.com> wr=
ote:


Yes, this is my understanding as well.


On Wed, Jul 16, 2014 at 2:4=
5 PM, Roman Shpount <roman@telurix.com> wrote:




Should we specify two telep=
hone-events payloads, one with 8000 rate to be used with PCMU/PCMA and anot=
her with 48000 rate to be used with OPUS?




From what I can see, based on=C2=A0RFC 7160, if OPUS codec is used=
 telephone-events should either be transmitted with the rate 48Khz or use a=
 different SSRC. On the other hand if PCMU/PCMA is selected then DTMF shoul=
d be transmitted using 8000 clock or use a different SSRC. Using different =
SSRC is problematic since it will create synchronization issues with audio =
playback (things like record your name and press pound will stop working) a=
part from other webrtc related issues. I think the only solution that makes=
 sense is to advertise two telephone-events payloads and use the appropriat=
e one based on the selected transmit codec, similar to CN.





_____________
Roman Shpount




_______________________________________________

rtcweb mailing list

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







--bcaec53d550d24fee204fe5b83e9--


From nobody Wed Jul 16 20:58:07 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02431A0564 for ; Wed, 16 Jul 2014 20:58:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EY2yxEb4baxP for ; Wed, 16 Jul 2014 20:58:03 -0700 (PDT)
Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0415D1A0547 for ; Wed, 16 Jul 2014 20:58:02 -0700 (PDT)
Received: by mail-we0-f178.google.com with SMTP id w61so1805513wes.23 for ; Wed, 16 Jul 2014 20:58: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:content-type; bh=VtLPxYmX3Pf1+qX+1mRdwXQTdukRo9Kt0wOozP5tCu4=; b=OB0/ivNMZBpLIbdjxd61q/exkXB6k3XAfeUNqv8GqN81ajrquzoI8niMUY5ZoLXtDq 6+QL0AugKsR0wKtqtUW99hRlBGvU7JSNalYn9nXYYN7rjY6DVzOtkqyBx9fynAi1DZtT b64M8K23M+38M/TFzoO0MJu9DD78XPQ4OJzYL6Zaoft4zu+FisWUzaysrF9vCF+uSf+H nkKMLDENsvo4ewKq3WPJaCdKlyNHfIgMT1HSAuBUvg7be2xZI6mUh/JhfEGfXYOSJdTC SRLuEd6QiZadq97aNNy4Ha4kA7/JXGp38wpnNVdfmtHpWt1dhz+Pboc4WT5NsO/otK9U R0sQ==
X-Received: by 10.194.7.167 with SMTP id k7mr40362964wja.11.1405569481421; Wed, 16 Jul 2014 20:58:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.217.122.65 with HTTP; Wed, 16 Jul 2014 20:57:41 -0700 (PDT)
In-Reply-To: 
References: <20140528112153.7351.96214.idtracker@ietfa.amsl.com> <5385C8AB.8080606@ericsson.com> 
From: Bernard Aboba 
Date: Wed, 16 Jul 2014 20:57:41 -0700
Message-ID: 
To: Justin Uberti 
Content-Type: multipart/alternative; boundary=047d7b5d2f70a5bbe404fe5ba528
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wENKipzJhJ2XQjg7YFtNzeBnQ60
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-15.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Jul 2014 03:58:06 -0000

--047d7b5d2f70a5bbe404fe5ba528
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Currently RFC 3389 isn't mentioned in either the RTP Usage document or in
the Audio document.  That seems strange.


On Wed, Jul 16, 2014 at 8:20 PM, Justin Uberti  wrote:

> One thing that has come up while discussing JSEP is the need to specify
> handling of DTX in the RTP usage document. JSEP allows applications to as=
k
> for DTX, so this needs to be supported in all implementations to give
> deterministic behavior.
>
> While Opus has the ability to support DTX internally, we also need to mak=
e
> sure this works with other codecs, including G.711. As a result, I think
> the RTP usage draft needs to specify RFC 3389 support as
> mandatory-to-implement, so that applications can deterministically enable
> DTX in all cases.
>
>
> On Wed, May 28, 2014 at 7:29 AM, Magnus Westerlund <
> magnus.westerlund@ericsson.com> wrote:
>
>> WG,
>>
>> This version contains some changes as result of last weeks discussion.
>> Especially you who wasn't there should review this to see that you agree
>> with the changes proposed.
>>
>> The changes are:
>>
>> - Multi-stream optimization are now a MAY support, MUST signal to use.
>>
>> - The T_rr_interval =3D 4 is now explained in
>> draft-ietf-avtcore-rtp-multi-stream, so a reference has been added here.
>>
>> - Signalling of extensions has been clarified to be a MUST
>>
>> - The DoS potential from RTCP configuration that Martin Thomson noticed
>> is now discussed and the general consideration that an WebRTC
>> implementation needs safe guards among this is present. WG needs to
>> consider if it needs more or are sufficient.
>>
>> Cheers
>>
>> Magnus
>>
>> On 2014-05-28 13:21, internet-drafts@ietf.org wrote:
>> >
>> > A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> >  This draft is a work item of the Real-Time Communication in
>> WEB-browsers Working Group of the IETF.
>> >
>> >         Title           : Web Real-Time Communication (WebRTC): Media
>> Transport and Use of RTP
>> >         Authors         : Colin Perkins
>> >                           Magnus Westerlund
>> >                           Joerg Ott
>> >       Filename        : draft-ietf-rtcweb-rtp-usage-15.txt
>> >       Pages           : 44
>> >       Date            : 2014-05-28
>> >
>> > Abstract:
>> >    The Web Real-Time Communication (WebRTC) framework provides support
>> >    for direct interactive rich communication using audio, video, text,
>> >    collaboration, games, etc. between two peers' web-browsers.  This
>> >    memo describes the media transport aspects of the WebRTC framework.
>> >    It specifies how the Real-time Transport Protocol (RTP) is used in
>> >    the WebRTC context, and gives requirements for which RTP features,
>> >    profiles, and extensions need to be supported.
>> >
>> >
>> > The IETF datatracker status page for this draft is:
>> > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/
>> >
>> > There's also a htmlized version available at:
>> > http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-15
>> >
>> > A diff from the previous version is available at:
>> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-15
>> >
>> >
>> > Please note that it may take a couple of minutes from the time of
>> submission
>> > until the htmlized version and diff are available at tools.ietf.org.
>> >
>> > Internet-Drafts are also available by anonymous FTP at:
>> > ftp://ftp.ietf.org/internet-drafts/
>> >
>> > _______________________________________________
>> > rtcweb mailing list
>> > rtcweb@ietf.org
>> > https://www.ietf.org/mailman/listinfo/rtcweb
>> >
>> >
>>
>>
>> --
>>
>> Magnus Westerlund
>>
>> ----------------------------------------------------------------------
>> Services, Media and Network features, Ericsson Research EAB/TXM
>> ----------------------------------------------------------------------
>> Ericsson AB                 | Phone  +46 10 7148287
>> F=C3=A4r=C3=B6gatan 6                 | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> 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
>
>

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


Currently=C2=A0RFC 3389 isn't mentioned in either=
 the RTP Usage document or in the Audio document.=C2=A0 That seems strange.=



O=
n Wed, Jul 16, 2014 at 8:20 PM, Justin Uberti <juberti@google.com>=
 wrote:



One thing that has come up =
while discussing JSEP is the need to specify handling of DTX in the RTP usa=
ge document. JSEP allows applications to ask for DTX, so this needs to be s=
upported in all implementations to give deterministic behavior.





While Opus has the ability to support DTX internally, we als=
o need to make sure this works with other codecs, including G.711. As a res=
ult, I think the RTP usage draft needs to specify RFC 3389 support as manda=
tory-to-implement, so that applications can deterministically enable DTX in=
 all cases.






On Wed, May 28, 2014 at 7:29 AM, Magnus We=
sterlund <magnus.westerlund@ericsson.com> wrote=
:





WG,



This version contains some changes as result of last weeks discussion.

Especially you who wasn't there should review this to see that you agre=
e

with the changes proposed.



The changes are:



- Multi-stream optimization are now a MAY support, MUST signal to use.



- The T_rr_interval =3D 4 is now explained in

draft-ietf-avtcore-rtp-multi-stream, so a reference has been added here.


- Signalling of extensions has been clarified to be a MUST



- The DoS potential from RTCP configuration that Martin Thomson noticed

is now discussed and the general consideration that an WebRTC

implementation needs safe guards among this is present. WG needs to

consider if it needs more or are sufficient.



Cheers



Magnus




On 2014-05-28 13:21, internet-drafts@ietf.org wrote:

>

> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.

> =C2=A0This draft is a work item of the Real-Time Communication in WEB-=
browsers Working Group of the IETF.

>

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 Web Real-Time Communication (WebRTC): Media Transport and Use of RTP

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Coli=
n Perkins

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 Magnus Westerlund

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 Joerg Ott

> =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-ietf-=
rtcweb-rtp-usage-15.txt

> =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 44

> =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 2=
014-05-28

>

> Abstract:

> =C2=A0 =C2=A0The Web Real-Time Communication (WebRTC) framework provid=
es support

> =C2=A0 =C2=A0for direct interactive rich communication using audio, vi=
deo, text,

> =C2=A0 =C2=A0collaboration, games, etc. between two peers' web-bro=
wsers. =C2=A0This

> =C2=A0 =C2=A0memo describes the media transport aspects of the WebRTC =
framework.

> =C2=A0 =C2=A0It specifies how the Real-time Transport Protocol (RTP) i=
s used in

> =C2=A0 =C2=A0the WebRTC context, and gives requirements for which RTP =
features,

> =C2=A0 =C2=A0profiles, and extensions need to be supported.

>

>

> The IETF datatracker status page for this draft is:

> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rt=
p-usage/

>

> There's also a htmlized version available at:

> http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-15=


>

> A diff from the previous version is available at:

> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtc=
web-rtp-usage-15

>

>

> Please note that it may take a couple of minutes from the time of subm=
ission

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

>

> Internet-Drafts are also available by anonymous FTP at:

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

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

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

>

>






--



Magnus Westerlund



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

Services, Media and Network features, Ericsson Research EAB/TXM

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

Ericsson AB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Phone=
 =C2=A0+46 10 7148287

F=C3=A4r=C3=B6gatan 6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | Mobile +46 73 0949079

SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com

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




_______________________________________________

rtcweb mailing list

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






_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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





--047d7b5d2f70a5bbe404fe5ba528--


From nobody Thu Jul 17 06:38:10 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20261A0B04 for ; Thu, 17 Jul 2014 06:38:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiF5HiMjup5d for ; Thu, 17 Jul 2014 06:38:04 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF281A03A8 for ; Thu, 17 Jul 2014 06:38:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20352; q=dns/txt; s=iport; t=1405604283; x=1406813883; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qw+MkUZ77lcOhh6ToxUTitym5fXfssxx9dzGUJWgfTk=; b=N/DvhLWdNOCl78ZpYOYMC8YJGOdlO3rpLhCj7gcxO1UB493IGz79Qh7V bWMPpcD9WJCnoHwxdGECROhRjTBGyjS6Y34V+P9064KBdlp/aEWnDJB66 ceIJC468UKjo19VjBRZHvbB/BhDAZJiS27z2xm1DAd1LBf7BGfiSz3eRI 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: As0LAE3Rx1OtJV2S/2dsb2JhbABZgw5SUwSwPZE2gVcBCYZvUwGBBRZ2hAMBAQEEAQEBCWILDAICAgEIDgMDAQIBJwcbDAsUCQgCBA4FCYg5CAXGHhcEjyURDQQHBgOCLlMkgRgFhHAChTiQdYFMkmCDRGw
X-IronPort-AV: E=Sophos; i="5.01,678,1400025600"; d="scan'208,217"; a="61646128"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-5.cisco.com with ESMTP; 17 Jul 2014 13:38:02 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6HDc2iv004888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jul 2014 13:38:02 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Thu, 17 Jul 2014 08:38:02 -0500
From: "Mo Zanaty (mzanaty)" 
To: Justin Uberti 
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-15.txt
Thread-Index: AQHPoW2JoQuG4RWdAkWIBa1kY9OfkpukRc6F
Date: Thu, 17 Jul 2014 13:38:02 +0000
Message-ID: <95102B78-C77E-4718-AEFB-24EEB46F13C2@cisco.com>
References: <20140528112153.7351.96214.idtracker@ietfa.amsl.com> <5385C8AB.8080606@ericsson.com> <43EF4063-F132-4A4B-BB54-871E93DF1401@csperkins.org> , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_95102B78C77E4718AEFB24EEB46F13C2ciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/geZlMHi5KKV5FjP01kk2S_mebWc
Cc: "rtcweb@ietf.org" , Colin Perkins 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-15.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Jul 2014 13:38:08 -0000

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

5109 uses the old FEC semantics in SDP which were deprecated by FEC-FR. No =
FEC-FR encoding id has been defined yet for XOR parity with ULP. So there w=
ould be a bit more work to do.

As Colin points out though, ULP gives very little (if any) bang for lots of=
 bucks, so reusing LDPC (XOR without ULP, which is already in FEC-FR) is pe=
rhaps a better alternative.

Some (including myself) also feel XOR is often ineffective for most real-wo=
rld loss patterns. It is only useful for isolated single-packet loss, which=
 is indeed useful for very highly multiplexed links like transcontinental /=
 transoceanic paths. But it is mostly ineffective for low stat-mux environm=
ents like access links, especially wireless which often exhibits consecutiv=
e losses. (For this reason, we use RS which is complex but provides optimal=
 repair.)

Mo

On Jul 16, 2014, at 11:16 PM, "Justin Uberti" > wrote:

In DC we talked about making a baseline FEC proposal using 5109. Other vari=
ants could be added in the future, but 5109 would be MTI.

I still need to write up said proposal though, including explaining how it =
works with BUNDLE (it can do so fairly easily)


On Tue, Jul 15, 2014 at 6:15 PM, Mo Zanaty (mzanaty) > wrote:
There is also RFC 6865 Reed Solomon FEC.

Since there are many encoding schemes (parity/LDPC, Raptor/Q, Reed
Solomon), many encoding-dependent variants (1d/2d interleaved, ULP,
staircase, triangle, etc.) and parameters (n,k,etc.), several RTP
packetization and multiplexing options, and several SDP expressions, it
seems premature to make any sort of FEC recommendation without some more
detailed work and discussion.

So I agree with the current draft text.

Mo

-----Original Message-----
From: Colin Perkins >
Date: Tuesday, July 15, 2014 at 11:53 AM
To: "rtcweb@ietf.org" >
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-15.txt

As far as I=B9m aware, the only open issue with the RTP usage draft is
whether it should make some recommendation regarding FEC. The draft
currently states:

=B3There are several block-based FEC schemes that are designed for use with
RTP independent of the chosen RTP payload format.  At the time of this
writing there is no consensus on which, if any, of these FEC schemes is
appropriate for use in the WebRTC context.  Accordingly, this memo makes
no recommendation on the choice of block-based FEC for WebRTC use.=B2

but some people have expressed a desire that it recommend some FEC scheme.
As I understand it, the possible FEC schemes are as follows:

- RFC 2733 =AD parity FEC; requires FEC use same SSRC as original media, so
doesn=B9t work with bundle; abuses RTP header fields for FEC, so can=B9t be
used with mixers

- RFC 5109 =AD parity FEC with uneven level protection (ULP); unnecessary
complexity due to ULP; requires FEC use same SSRC as original media, so
doesn=B9t work with bundle

- SMPTE 2022-1 =AD extends RFC 2733 for 2d interleaved parity FEC; sets CC,
CSRC, and timestamp to zero, so doesn=B9t work with mixers; requires SSRC=
=3D0
and PT=3D96, so can=B9t support >1 FEC stream per RTP session

- RFC 6015 =AD interleaved parity FEC; abuses RTP header fields for FEC, so
can=B9t be used with mixers; works with bundle

- RFC 6682 =AD Raptor FEC; works with bundle

There are IPR declarations on most of these, most have problems with
bundle due to the way they use SSRCs, and some have problems with RTP
mixers due to the way they abuse the CC/CSRC header fields to convey
protection information. Accordingly, I don=B9t see a particularly good
choice for WebRTC, and since we can add FEC in a backwards compatible
manner in a later revision of WebRTC, my proposal is that we leave it out.
However, I=B9m open to other suggestions.

Also, if there are other open issues with the rtp-usage draft that I=B9ve
missed, then please let me know.

Colin






On 28 May 2014, at 12:29, Magnus Westerlund
> wro=
te:
> WG,
>
> This version contains some changes as result of last weeks discussion.
> Especially you who wasn't there should review this to see that you agree
> with the changes proposed.
>
> The changes are:
>
> - Multi-stream optimization are now a MAY support, MUST signal to use.
>
> - The T_rr_interval =3D 4 is now explained in
> draft-ietf-avtcore-rtp-multi-stream, so a reference has been added here.
>
> - Signalling of extensions has been clarified to be a MUST
>
> - The DoS potential from RTCP configuration that Martin Thomson noticed
> is now discussed and the general consideration that an WebRTC
> implementation needs safe guards among this is present. WG needs to
> consider if it needs more or are sufficient.
>
> Cheers
>
> Magnus
>
> On 2014-05-28 13:21, internet-drafts@ietf.org wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>>directories.
>> This draft is a work item of the Real-Time Communication in
>>WEB-browsers Working Group of the IETF.
>>
>>        Title           : Web Real-Time Communication (WebRTC): Media
>>Transport and Use of RTP
>>        Authors         : Colin Perkins
>>                          Magnus Westerlund
>>                          Joerg Ott
>>      Filename        : draft-ietf-rtcweb-rtp-usage-15.txt
>>      Pages           : 44
>>      Date            : 2014-05-28
>>
>> Abstract:
>>   The Web Real-Time Communication (WebRTC) framework provides support
>>   for direct interactive rich communication using audio, video, text,
>>   collaboration, games, etc. between two peers' web-browsers.  This
>>   memo describes the media transport aspects of the WebRTC framework.
>>   It specifies how the Real-time Transport Protocol (RTP) is used in
>>   the WebRTC context, and gives requirements for which RTP features,
>>   profiles, and extensions need to be supported.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-15
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-15
>>
>>
>> Please note that it may take a couple of minutes from the time of
>>submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>
>
> --
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> F=E4r=F6gatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb



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



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

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


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







5109 uses the old FEC semantics in SDP which were deprecated by FEC-FR=
. No FEC-FR encoding id has been defined yet for XOR parity with ULP. So th=
ere would be a bit more work to do.







As Colin points out though, ULP gives very little (if any) bang for lo=
ts of bucks, so reusing LDPC (XOR without ULP, which is already in FEC-FR) =
is perhaps a better alternative.







Some (including myself) also feel XOR is often ineffective for most re=
al-world loss patterns. It is only useful for isolated single-packet loss, =
which is indeed useful for very highly multiplexed links like transcontinen=
tal / transoceanic paths. But it
 is mostly ineffective for low stat-mux environments like access links, esp=
ecially wireless which often exhibits consecutive losses. (For this reason,=
 we use RS which is complex but provides optimal repair.)







Mo




On Jul 16, 2014, at 11:16 PM, "Justin Uberti" <juberti@google.com> wrote:








In DC we talked about making a baseline FEC proposal using=
 5109. Other variants could be added in the future, but 5109 would be MTI.






I still need to write up said proposal though, including explaining ho=
w it works with BUNDLE (it can do so fairly easily)









On Tue, Jul 15, 2014 at 6:15 PM, Mo Zanaty (mzan=
aty) 
<mzanaty@cisco.co=
m> wrote:



There is also RFC 6865 Reed Solomon FEC.



Since there are many encoding schemes (parity/LDPC, Raptor/Q, Reed

Solomon), many encoding-dependent variants (1d/2d interleaved, ULP,

staircase, triangle, etc.) and parameters (n,k,etc.), several RTP

packetization and multiplexing options, and several SDP expressions, it

seems premature to make any sort of FEC recommendation without some more
detailed work and discussion.



So I agree with the current draft text.



Mo







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

From: Colin Perkins <csp@csperkins.=
org>

Date: Tuesday, July 15, 2014 at 11:53 AM

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

Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-15.txt



As far as I=B9m aware, the only open issue with the RTP usage draft is

whether it should make some recommendation regarding FEC. The draft

currently states:



=B3There are several block-based FEC schemes that are designed for use with=


RTP independent of the chosen RTP payload format.  At the time of this=


writing there is no consensus on which, if any, of these FEC schemes is

appropriate for use in the WebRTC context.  Accordingly, this memo mak=
es

no recommendation on the choice of block-based FEC for WebRTC use.=B2



but some people have expressed a desire that it recommend some FEC scheme.<=
br>
As I understand it, the possible FEC schemes are as follows:



- RFC 2733 =AD parity FEC; requires FEC use same SSRC as original media, so=


doesn=B9t work with bundle; abuses RTP header fields for FEC, so can=B9t be=


used with mixers



- RFC 5109 =AD parity FEC with uneven level protection (ULP); unnecessary
complexity due to ULP; requires FEC use same SSRC as original media, so

doesn=B9t work with bundle



- SMPTE 2022-1 =AD extends RFC 2733 for 2d interleaved parity FEC; sets CC,=


CSRC, and timestamp to zero, so doesn=B9t work with mixers; requires SSRC=
=3D0

and PT=3D96, so can=B9t support >1 FEC stream per RTP session



- RFC 6015 =AD interleaved parity FEC; abuses RTP header fields for FEC, so=


can=B9t be used with mixers; works with bundle



- RFC 6682 =AD Raptor FEC; works with bundle



There are IPR declarations on most of these, most have problems with

bundle due to the way they use SSRCs, and some have problems with RTP

mixers due to the way they abuse the CC/CSRC header fields to convey

protection information. Accordingly, I don=B9t see a particularly good

choice for WebRTC, and since we can add FEC in a backwards compatible

manner in a later revision of WebRTC, my proposal is that we leave it out.<=
br>
However, I=B9m open to other suggestions.



Also, if there are other open issues with the rtp-usage draft that I=B9ve
missed, then please let me know.



Colin













On 28 May 2014, at 12:29, Magnus Westerlund

<magnus.westerlund@eri=
csson.com> wrote:

> WG,

>

> This version contains some changes as result of last weeks discussion.=


> Especially you who wasn't there should review this to see that you agr=
ee

> with the changes proposed.

>

> The changes are:

>

> - Multi-stream optimization are now a MAY support, MUST signal to use.=


>

> - The T_rr_interval =3D 4 is now explained in

> draft-ietf-avtcore-rtp-multi-stream, so a reference has been added her=
e.

>

> - Signalling of extensions has been clarified to be a MUST

>

> - The DoS potential from RTCP configuration that Martin Thomson notice=
d

> is now discussed and the general consideration that an WebRTC

> implementation needs safe guards among this is present. WG needs to
> consider if it needs more or are sufficient.

>

> Cheers

>

> Magnus

>

> On 2014-05-28 13:21, inter=
net-drafts@ietf.org wrote:

>>

>> A New Internet-Draft is available from the on-line Internet-Drafts=


>>directories.

>> This draft is a work item of the Real-Time Communication in

>>WEB-browsers Working Group of the IETF.

>>

>>        Title          =
; : Web Real-Time Communication (WebRTC): Media

>>Transport and Use of RTP

>>        Authors         : C=
olin Perkins

>>                   &nb=
sp;      Magnus Westerlund

>>                   &nb=
sp;      Joerg Ott

>>      Filename        : draft-ie=
tf-rtcweb-rtp-usage-15.txt

>>      Pages           : 44<=
br>
>>      Date            =
: 2014-05-28

>>

>> Abstract:

>>   The Web Real-Time Communication (WebRTC) framework provides=
 support

>>   for direct interactive rich communication using audio, vide=
o, text,

>>   collaboration, games, etc. between two peers' web-browsers.=
  This

>>   memo describes the media transport aspects of the WebRTC fr=
amework.

>>   It specifies how the Real-time Transport Protocol (RTP) is =
used in

>>   the WebRTC context, and gives requirements for which RTP fe=
atures,

>>   profiles, and extensions need to be supported.

>>

>>

>> The IETF datatracker status page for this draft is:

>> 
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/

>>

>> There's also a htmlized version available at:

>> 
http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-15

>>

>> A diff from the previous version is available at:

>> 
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-15

>>

>>

>> Please note that it may take a couple of minutes from the time of<=
br>
>>submission

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

>>

>> Internet-Drafts are also available by anonymous FTP at:

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

>>

>> _______________________________________________

>> rtcweb mailing list

>> rtcweb@ietf.org

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

>>

>>

>

>

> --

>

> Magnus Westerlund

>

> ----------------------------------------------------------------------=


> Services, Media and Network features, Ericsson Research EAB/TXM

> ----------------------------------------------------------------------=


> Ericsson AB                 | =
Phone  +46 10 7148287

> F=E4r=F6gatan 6                =
; | Mobile 
+46 73 0949079

> SE-164 80 Stockholm, Sweden | mailto: 
magnus.westerlund@ericsson.com

> ----------------------------------------------------------------------=


>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

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







--

Colin Perkins

http://csperkins.org/







_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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


















--_000_95102B78C77E4718AEFB24EEB46F13C2ciscocom_--


From nobody Thu Jul 17 08:02:57 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93601B27BA for ; Thu, 17 Jul 2014 08:02:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 o6dsm8XUzftS for ; Thu, 17 Jul 2014 08:02:47 -0700 (PDT)
Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 464E31A033A for ; Thu, 17 Jul 2014 08:02:45 -0700 (PDT)
Received: by mail-vc0-f169.google.com with SMTP id hu12so4909678vcb.28 for ; Thu, 17 Jul 2014 08:02:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YLvB+b/BpCkpL05lbUhX50XiqMkkHYV+mw65fGX3q6w=; b=jsl1obyNnRcREhAh2tiKBmQSyzYVEx+KwkyoxrHbBV1SVPTtZ67xtjZksysSoVGX55 1W/UhBv4VFmJ8Id6nfg2v/OhJWt41X2s+e3O+CS25M1w/Xl842/E5udOHbu8vRCjZgd8 bXa5vVz4rtIRE4gNwM5TVLGbtanDbap+SOUzZosIIdIs+ii298CRfdFoI0VMaCE3TpHh tCqkYadGsvbi9LL3GfHw/Y45erP3a00jxu3QzT/wwb3vZrn8ImJHvAz1YoDk1bZdRSVB OKrCZNuvc2JRm/8rmY+tChF9CMV2lF+AlfYkK9Hdgl39mBYopM1LejqcJhqvLDOwgP5H +zeQ==
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:content-type; bh=YLvB+b/BpCkpL05lbUhX50XiqMkkHYV+mw65fGX3q6w=; b=Efi0exdPlR5hNKDLdO9FEnZjinvc1y2rhrZXb//S/UJJofU2m9a6uPBNJd0OC5If1M +Jv3pdxVOtjEQWig7+idmwItacumcESgY/AnPcCmubjPURmRhO479MWuyOaQHvtrNuPe mM/PfsZ4dUYfeDKA5YsONBkCHMIn5p8yK6brh554d2QMvGSF1MSSyMT3dARh/bt+KzBl uRUQtxB/qlTvP248dMzWm4s2bBy3t8mcV6YkVQM+TSvJPJnY4/NaWGjxQii+RoVtYaH0 0hv4ACiVQq8U6CqgZ3y/nxeKouQK4C5u+5qI/wvQBLcv8hyjXqSgXrOJvQiwp4yB0+Oo vTdQ==
X-Gm-Message-State: ALoCoQncRMQF82dKdrU6PuMtyeKJ1ihgRvwqvPk4cTr3VVc9NvDcB33ZxjDuKdq6xZr1NUGcjcdv
X-Received: by 10.52.7.163 with SMTP id k3mr15819712vda.58.1405609364331; Thu, 17 Jul 2014 08:02:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.66.242 with HTTP; Thu, 17 Jul 2014 08:02:24 -0700 (PDT)
In-Reply-To: 
References:   
From: Justin Uberti 
Date: Thu, 17 Jul 2014 11:02:24 -0400
Message-ID: 
To: Roman Shpount 
Content-Type: multipart/alternative; boundary=bcaec50164afdac52a04fe64eead
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XpT4dmrXfecSGgDF3xlYNOAh1HU
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Rate for telephone-events in combination with OPUS
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Jul 2014 15:02:51 -0000

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

For Chrome, we just haven't gotten to it yet. I think there is an open bug
on it.


On Wed, Jul 16, 2014 at 11:48 PM, Roman Shpount  wrote:

> So, I guess the fact that neither Chrome no Firefox do this is an
> oversight or an unimplemented feature.
>  On Jul 16, 2014 11:14 PM, "Justin Uberti"  wrote:
>
>> Yes, this is my understanding as well.
>>
>>
>> On Wed, Jul 16, 2014 at 2:45 PM, Roman Shpount  wrote:
>>
>>> Should we specify two telephone-events payloads, one with 8000 rate to
>>> be used with PCMU/PCMA and another with 48000 rate to be used with OPUS?
>>>
>>> From what I can see, based on RFC 7160, if OPUS codec is used
>>> telephone-events should either be transmitted with the rate 48Khz or use a
>>> different SSRC. On the other hand if PCMU/PCMA is selected then DTMF should
>>> be transmitted using 8000 clock or use a different SSRC. Using different
>>> SSRC is problematic since it will create synchronization issues with audio
>>> playback (things like record your name and press pound will stop working)
>>> apart from other webrtc related issues. I think the only solution that
>>> makes sense is to advertise two telephone-events payloads and use the
>>> appropriate one based on the selected transmit codec, similar to CN.
>>> _____________
>>> Roman Shpount
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>>
>>

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


For Chrome, we just haven't gotten to it yet. I think =
there is an open bug on it.


On Wed, Jul 16, 2014 at 11:48 PM, Roman Shpount <roman=
@telurix.com> wrote:



So, I guess the fact that nei=
ther Chrome no Firefox do this is an oversight or an unimplemented feature.=






On Jul 16, 2014 11:14 PM, "Justin Uberti&qu=
ot; <juberti@goo=
gle.com> wrote:




Yes, this is my understanding as well.


On Wed, Jul 16, 2014 at 2:4=
5 PM, Roman Shpount <roman@telurix.com> wrote:






Should we specify two telep=
hone-events payloads, one with 8000 rate to be used with PCMU/PCMA and anot=
her with 48000 rate to be used with OPUS?






From what I can see, based on=C2=A0RFC 7160, if OPUS codec is used=
 telephone-events should either be transmitted with the rate 48Khz or use a=
 different SSRC. On the other hand if PCMU/PCMA is selected then DTMF shoul=
d be transmitted using 8000 clock or use a different SSRC. Using different =
SSRC is problematic since it will create synchronization issues with audio =
playback (things like record your name and press pound will stop working) a=
part from other webrtc related issues. I think the only solution that makes=
 sense is to advertise two telephone-events payloads and use the appropriat=
e one based on the selected transmit codec, similar to CN.







_____________
Roman Shpount




_______________________________________________

rtcweb mailing list

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










--bcaec50164afdac52a04fe64eead--


From nobody Thu Jul 17 08:55:32 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542591B27BB for ; Thu, 17 Jul 2014 08:55:25 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmvDXxWoy9mY for ; Thu, 17 Jul 2014 08:55:18 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 94F7D1A0176 for ; Thu, 17 Jul 2014 08:55:17 -0700 (PDT)
Received: from [172.17.0.17] (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6HFtDEO066083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Jul 2014 10:55:14 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be [172.17.0.17]
References:    
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-4D44AD5B-1443-4AA7-9900-8C5E30B1F190
Content-Transfer-Encoding: 7bit
Message-Id: 
X-Mailer: iPad Mail (11D257)
From: Adam Roach 
Date: Thu, 17 Jul 2014 10:55:15 -0500
To: Justin Uberti 
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/P9Mdsl5lSAZ5zIgP3Z14AB3Nim4
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Rate for telephone-events in combination with OPUS
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Jul 2014 15:55:25 -0000

--Apple-Mail-4D44AD5B-1443-4AA7-9900-8C5E30B1F190
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Same with Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=3D964282

> On Jul 17, 2014, at 10:02, Justin Uberti  wrote:
>=20
> For Chrome, we just haven't gotten to it yet. I think there is an open bug=
 on it.
>=20
>=20
>> On Wed, Jul 16, 2014 at 11:48 PM, Roman Shpount  wrote=
:
>> So, I guess the fact that neither Chrome no Firefox do this is an oversig=
ht or an unimplemented feature.
>>=20
>>> On Jul 16, 2014 11:14 PM, "Justin Uberti"  wrote:
>>> Yes, this is my understanding as well.
>>>=20
>>>=20
>>>> On Wed, Jul 16, 2014 at 2:45 PM, Roman Shpount  wrot=
e:
>>>> Should we specify two telephone-events payloads, one with 8000 rate to b=
e used with PCMU/PCMA and another with 48000 rate to be used with OPUS?
>>>>=20
>>>> =46rom what I can see, based on RFC 7160, if OPUS codec is used telepho=
ne-events should either be transmitted with the rate 48Khz or use a differen=
t SSRC. On the other hand if PCMU/PCMA is selected then DTMF should be trans=
mitted using 8000 clock or use a different SSRC. Using different SSRC is pro=
blematic since it will create synchronization issues with audio playback (th=
ings like record your name and press pound will stop working) apart from oth=
er webrtc related issues. I think the only solution that makes sense is to a=
dvertise two telephone-events payloads and use the appropriate one based on t=
he selected transmit codec, similar to CN.
>>>> _____________
>>>> Roman Shpount
>>>>=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

--Apple-Mail-4D44AD5B-1443-4AA7-9900-8C5E30B1F190
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit



On Jul 17, 2014, at 10:02, Justin Uberti <juberti@google.com> wrote:

For Chrome, we just haven't gotten to it yet. I think there is an open bug on it.


On Wed, Jul 16, 2014 at 11:48 PM, Roman Shpount <roman@telurix.com> wrote:



So, I guess the fact that neither Chrome no Firefox do this is an oversight or an unimplemented feature.





On Jul 16, 2014 11:14 PM, "Justin Uberti" <juberti@google.com> wrote:




Yes, this is my understanding as well.


On Wed, Jul 16, 2014 at 2:45 PM, Roman Shpount <roman@telurix.com> wrote:






Should we specify two telephone-events payloads, one with 8000 rate to be used with PCMU/PCMA and another with 48000 rate to be used with OPUS?






From what I can see, based on RFC 7160, if OPUS codec is used telephone-events should either be transmitted with the rate 48Khz or use a different SSRC. On the other hand if PCMU/PCMA is selected then DTMF should be transmitted using 8000 clock or use a different SSRC. Using different SSRC is problematic since it will create synchronization issues with audio playback (things like record your name and press pound will stop working) apart from other webrtc related issues. I think the only solution that makes sense is to advertise two telephone-events payloads and use the appropriate one based on the selected transmit codec, similar to CN.







_____________
Roman Shpount




_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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










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

--Apple-Mail-4D44AD5B-1443-4AA7-9900-8C5E30B1F190--


From nobody Thu Jul 17 09:18:35 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FFD1B27BF for ; Thu, 17 Jul 2014 09:18:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 XkHSqcjJ4obE for ; Thu, 17 Jul 2014 09:18:03 -0700 (PDT)
Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B79CA1A0271 for ; Thu, 17 Jul 2014 09:18:02 -0700 (PDT)
Received: by mail-vc0-f174.google.com with SMTP id la4so5056490vcb.19 for ; Thu, 17 Jul 2014 09:18:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Zc60HgIiJgnhjmxkS3t32uX8mFE2s2Ms/q6rF7BinYw=; b=Wfn1opp9P1elSXbiOvirPwgL6zd3ssbRYj5L2geDNlMAvYMZ985V2Splj1NvUJRaki IDsDJFniCZclKUtCTsPyhraL4dsN3IPJrphh8vxG0M3kIfGT6e9bsXDq1URjS4iv21Al qcPFHLZWhd1jtjKqsv8Uu0KKTNDO0eD/kUzX1Fx4Wi2SEZ/qq1oUx1/HXGIddTpAQMlY RDyIq8TC3iRSV0cVIsSOy1y3jQVLGS98z400X+9rPGbSMI6M5Iyj+ELP9mG+/IoFb//y /ct4m+kktKKT/SFyqAFgQ8yA/qveZ57JJrnrFvkCjXhIdAiW5dP9uDpKd+KY7BBXvkHq EKxA==
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:content-type; bh=Zc60HgIiJgnhjmxkS3t32uX8mFE2s2Ms/q6rF7BinYw=; b=S6DHU3KfQt/FEdbLxU1LnDc6DPA+3Vl49NeP+zZnVgHdla7qRoC4xhNcR5JEWXcMpl uyHznGVC/AN7SmZbO396MvJRMtOFAZaHQA7TyqUPMrgdr0qpOz79QKyyI5LsyQFgvZst NjtHYtmmHZqLH8y3r7+hjXDo6Qr124lPy/B9L1sHOGtSd+WQctSdkR/MoN0cK1ZEkmG0 HDc9m7Rs1u/5xqCwR6QTzEVHALbnKR5AYkark4Tj4QJzm6l1jcpaul53twKSuv/hX83F 14sfwZwxYbCHZ45Zcrjlesof6zAfeiEHi7//rb5QcaHclJiZ7fpvQEpnWSFaJUIXlGDb stvQ==
X-Gm-Message-State: ALoCoQlE1TnP4O0MEk3RWYL7TFqSb3AD95xBTQHy9XQ2t42IQsIlbxhAyVbRntkuZ/1DMxsREYUq
X-Received: by 10.52.24.68 with SMTP id s4mr21467800vdf.37.1405613881275; Thu, 17 Jul 2014 09:18:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.66.242 with HTTP; Thu, 17 Jul 2014 09:17:41 -0700 (PDT)
In-Reply-To: 
References:     
From: Justin Uberti 
Date: Thu, 17 Jul 2014 12:17:41 -0400
Message-ID: 
To: Adam Roach 
Content-Type: multipart/alternative; boundary=20cf3071cfde15e8b804fe65fc5e
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wri55v0hrATE9diVXf3sMsStWnQ
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Rate for telephone-events in combination with OPUS
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Jul 2014 16:18:05 -0000

--20cf3071cfde15e8b804fe65fc5e
Content-Type: text/plain; charset=UTF-8

Chrome: https://code.google.com/p/webrtc/issues/detail?id=2795


On Thu, Jul 17, 2014 at 11:55 AM, Adam Roach  wrote:

> Same with Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=964282
>
> On Jul 17, 2014, at 10:02, Justin Uberti  wrote:
>
> For Chrome, we just haven't gotten to it yet. I think there is an open bug
> on it.
>
>
> On Wed, Jul 16, 2014 at 11:48 PM, Roman Shpount  wrote:
>
>> So, I guess the fact that neither Chrome no Firefox do this is an
>> oversight or an unimplemented feature.
>>  On Jul 16, 2014 11:14 PM, "Justin Uberti"  wrote:
>>
>>> Yes, this is my understanding as well.
>>>
>>>
>>> On Wed, Jul 16, 2014 at 2:45 PM, Roman Shpount 
>>> wrote:
>>>
>>>> Should we specify two telephone-events payloads, one with 8000 rate to
>>>> be used with PCMU/PCMA and another with 48000 rate to be used with OPUS?
>>>>
>>>> From what I can see, based on RFC 7160, if OPUS codec is used
>>>> telephone-events should either be transmitted with the rate 48Khz or use a
>>>> different SSRC. On the other hand if PCMU/PCMA is selected then DTMF should
>>>> be transmitted using 8000 clock or use a different SSRC. Using different
>>>> SSRC is problematic since it will create synchronization issues with audio
>>>> playback (things like record your name and press pound will stop working)
>>>> apart from other webrtc related issues. I think the only solution that
>>>> makes sense is to advertise two telephone-events payloads and use the
>>>> appropriate one based on the selected transmit codec, similar to CN.
>>>> _____________
>>>> Roman Shpount
>>>>
>>>> _______________________________________________
>>>> 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
>
>

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




On Thu, Jul 17, 2014 at 11:55 AM, Adam Roach <adam@nostrum.com><=
/span> wrote:







On Jul 17, 2014, at 10:02, Justin Uberti &l=
t;juberti@google.co=
m> wrote:

For Chrome, we just haven't gotten to it yet. I think there is an op=
en bug on it.





On Wed, Jul 1=
6, 2014 at 11:48 PM, Roman Shpount <roman@telurix.com> wrote=
:




So, I guess the fact that nei=
ther Chrome no Firefox do this is an oversight or an unimplemented feature.=








On Jul 16, 2014 11:14 PM, "Justin Uberti&qu=
ot; <juberti@goo=
gle.com> wrote:






Yes, this is my understanding as well.


On Wed, Jul 16, 2014 at 2:4=
5 PM, Roman Shpount <roman@telurix.com> wrote:








Should we specify two telep=
hone-events payloads, one with 8000 rate to be used with PCMU/PCMA and anot=
her with 48000 rate to be used with OPUS?








From what I can see, based on=C2=A0RFC 7160, if OPUS codec is used=
 telephone-events should either be transmitted with the rate 48Khz or use a=
 different SSRC. On the other hand if PCMU/PCMA is selected then DTMF shoul=
d be transmitted using 8000 clock or use a different SSRC. Using different =
SSRC is problematic since it will create synchronization issues with audio =
playback (things like record your name and press pound will stop working) a=
part from other webrtc related issues. I think the only solution that makes=
 sense is to advertise two telephone-events payloads and use the appropriat=
e one based on the selected transmit codec, similar to CN.









_____________
Roman Shpount




_______________________________________________

rtcweb mailing list

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










___________________=
____________________________
rtcweb mailing list
=
rtcweb@ietf.org<=
/a>


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



--20cf3071cfde15e8b804fe65fc5e--


From nobody Thu Jul 17 09:36:28 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0731B27DE for ; Thu, 17 Jul 2014 09:35:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.179
X-Spam-Level: 
X-Spam-Status: No, score=-0.179 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 ioobq5Ss1P7z for ; Thu, 17 Jul 2014 09:35:38 -0700 (PDT)
Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0BF11B27CC for ; Thu, 17 Jul 2014 09:35:37 -0700 (PDT)
Received: by mail-vc0-f181.google.com with SMTP id lf12so4929942vcb.26 for ; Thu, 17 Jul 2014 09:35:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KUpveQ40piWk0XvlZZzwpUulD5cLhv6xk3ypKf6SOLc=; b=oEayqJ0tgrgKOIVSNCLvf8fJ5VOVbQVopScL/I924hSDDWFh/o19q//7srRbzNNWmE cAhNZy93mfw6nIkS8UJyOqdmXIobSUc6At42NeybvzufaJ1iPbM3KxLMqy7KyiDOiSTB HGwPxRoFVdsbJs00lY+zJB6Z3ti/UpHsDTTFnF5Nhnr5HTlLlBl31eytjk7qYp4X1gN8 99JhtDk9jXPagSnNLgxOuUKEJn7+4LfQNx4uEKTU95v38TzGaJ6knYyAGEOvLbWMp1yJ JEWQEYUMf4JfhotxpCPLfhLOdyvwi9wQxnfORdP2PU/lhXlQ8QNDPEvHTKc5EP7kHd1s QncA==
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:content-type; bh=KUpveQ40piWk0XvlZZzwpUulD5cLhv6xk3ypKf6SOLc=; b=QyVEdFynlicqPAx6kZ3dVjxo37gvb9nY88MCEKBIZTujfsy3MrhTqilGKlbiQ9EmrQ o9Ugi/1t3aTP3BXMcl/Me6GtYT/ah5KMUn8TPfpYyspQ1uPGyN4B191Bh5XN2FAyGbbB m+viXDaz0Yyj5/CD/RXypd4Z5JQ6skpB5zpqO30qUsaKWGwyMCSYsXyk9sRXK+JBcJkq VMngLc3Qm7u3Al6DVpD8iqUYxcPEi2gL8c4nkVaastMsNpZT4VAtmFrCA8KFj7s8n8RA SlQ13gFmhrxSz+0Y5QfxtNpzqPMpoGQeek4HBy60YKR2xYuHsUTPol6sExTxYjmfec+C 9IxA==
X-Gm-Message-State: ALoCoQl8b/sguO6pR+YKcgKgeDPH5zbH5nU1BYF00VSzO744cr9WbEMWAQP1abBRnwqTmXwHTCSA
X-Received: by 10.220.200.71 with SMTP id ev7mr28024510vcb.24.1405614934048; Thu, 17 Jul 2014 09:35:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.66.242 with HTTP; Thu, 17 Jul 2014 09:35:13 -0700 (PDT)
In-Reply-To: <435de87e335b8a0bfa6f843db575873b@icewarp.com>
References: <435de87e335b8a0bfa6f843db575873b@icewarp.com>
From: Justin Uberti 
Date: Thu, 17 Jul 2014 12:35:13 -0400
Message-ID: 
To: Martin Ekblom 
Content-Type: multipart/alternative; boundary=089e011845ead5e55f04fe663afa
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0lj7cCeE0fZLyLAOYOy43B1Qo-M
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] About the current JSEP-06 draft
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Jul 2014 16:35:40 -0000

--089e011845ead5e55f04fe663afa
Content-Type: text/plain; charset=UTF-8

To make sure I understand, can you verify the examples I give below?

1 MST + no options: (unchanged)
m=video X
a=sendrecv
a=msid:foo

1 MST + N=0: (new)
m=video X
a=sendonly
a=msid:foo

1 MST + N=1: (unchanged)
m=video X
a=sendrecv
a=msid:foo

1 MST + N=2: (unchanged)
m=video X
a=sendrecv
a=msid:foo
m=video Y
a=recvonly

Based on this, I would also change the meaning of OfferToReceiveVideo:true
to mean max(1, # of MSTs), since I think the N=1 behavior would be
unexpected in the 2 MST case.


On Wed, Jul 16, 2014 at 6:20 AM, Martin Ekblom 
wrote:

> Hi Justin,
>
> I entirely agree with you. Each media stream will have it's own m= line
> and extra m= lines with recvonly directional attributes should be added for
> extra streams wanted. This allows for accepting more streams than sending,
> which is entirely in line with the SDP RFCs.
>
> However, the current JSEP draft misses one small fine point. Reversely, it
> should also (MUST if you read the relevant RFC) allow for sending more
> streams than it wants to receive, ie the opposite case of the above, and
> then send m= lines with the directional attribute set to sendonly. RFC 3264
> is very clear with this: 'If the offerer wishes to only send media on a
> stream to its peer, it MUST mark the stream as sendonly with the
> "a=sendonly" attribute.'
>
> Also as part of the SDP offer/answer exchange the medias that both agents
> agree not to use should have the m= line set to inactive, ie when the
> offerer states that it wants to receive a media stream with directional
> attribute recvonly and the answerer indicates that it is unable to send
> that media by setting the directional attribute to inactive (this media
> stream will not be sent in any direction). The ordering and the number of
> media lines should not change during the offer/answer exchange.
>
> Thus I suggest the following changes. Add an item to the list in 4.1.2
> (preferably in the middle):
>
>
>
> *To convey the intention of sending a media type which is not
> expected in return (e.g., a video presentation which does not wish      to
> receive video).*
>
> Section 5.2.3.2. would be changed as follows:
>
> If the "OfferToReceiveVideo" constraint is specified, with a value of
>    "N", the offer MUST include N non-rejected m= sections with media
>    type "video", even if fewer than N video MediaStreamTracks have been
>    added to the PeerConnection. This allows the offerer to receive
>    video, including multiple independent streams, even when not sending
>    it; accordingly, the directional attribute on the video m= sections
>    without associated MediaStreamTracks MUST be set to recvonly. If
>    this constraint is specified in the case where at least N video
>    MediaStreamTracks have already been added to the PeerConnection, or N
>    non-rejected m= sections with media type "video" would otherwise be
>    generated,
>
> *the offer MUST set the directional attribute to sendonly    for the
> MediaStreamTracks in the video m= section for the remaining
> MediaStreamTracks of type video beyond N.* The directional attribute
>    for MediaStreamTracks of type video not set to sendonly or recvonly
>    SHOULD be set to sendrecv unless inactive. For backwards compatibility,
>    a value of "true" is interpreted as equivalent to N=1
> *and a value of   * *"false" is i**nterpreted as equivalent to N=0.*
>
> The change in the paragraph above is mostly clarifying what previously was
> left unexplained with the words "*it has no effect*" and not touching on
> how to interpret a value of false. Section 5.2.3.1. would need to be
> changed in a similar way.
>
> These changes would be make it comply with RFC 3264 and 4566 and also be
> in line with the somewhat unclear w3c spec on WebRTC.
>
>
> Regards,
> Martin Ekblom
> Front-end Developer
> www.icewarp.com
>
>
> ------------------------------
> -----Original Message-----
> From: "Justin Uberti" 
> To: rtcweb@ietf.org, martin.ekblom@icewarp.com
> Date: 14/07/2014 04:20
> Subject: About the current JSEP-06 draft
>
>
>
>
> Adding rtcweb@ietf.org, the right mailing list for this.
>
> This behavior (of OfferToReceiveAudio/Video) was added to be conformant
> with Unified Plan, where each media stream requires its own m= line, and
> therefore the offerer needs the ability to advertise additional m= lines if
> it needs to receive more media streams than it is offering.
>
> I agree that the w3c spec's handling of this topic could be clarified.
>
>
> On Wed, Jul 2, 2014 at 2:37 AM, Martin Ekblom 
> wrote:
>
>> Hi,
>>
>> I believe there is a conceptual misunderstanding in section 5.2.3.1. and
>> 5.2.3.2. It seems to contradict the requirements of RFC 3264 / 4566 (SDP
>> offers and answers) and not be in line with the WebRTC draft. I would like
>> to contribute to improve or clarify this section, or in case I'm mistaken
>> confirm this.
>>
>> Is this the appropriate mailing list to disuss this?
>>
>> Regards,
>> Martin Ekblom
>> Front-end Developer
>> www.icewarp.com
>>
>>
>>
>
>
>
>
>
>
>
>
>
>

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


To make sure I understand, can you verify the example=
s I give below?

1 MST + no options: (unchanged)m=3Dvideo X
a=3Dsendrecv
a=3Dmsid:foo

<=
/div>


1 MST + N=3D0: (new)
m=3Dvideo X
a=3Dsendonly=

a=3Dmsid:foo

1 MST + N=3D1: (unch=
anged)
m=3Dvideo X
a=3Dsendrecv
a=3Dmsi=
d:foo




1 MST + N=3D2: (unchanged)
m=3Dvideo X
<=
div>a=3Dsendrecv
a=3Dmsid:foo
m=3Dvideo Y
a=3Drecvonly

Based on this, I would =
also change the meaning of OfferToReceiveVideo:true to mean max(1, # of MST=
s), since I think the N=3D1 behavior would be unexpected in the 2 MST case.=






On Wed,=
 Jul 16, 2014 at 6:20 AM, Martin Ekblom <martin.ekblom@icewarp.com=
> wrote:





Hi Justin,

I=
 entirely agree with you. Each media stream will have it's own m=3D lin=
e and extra m=3D lines with recvonly directional attributes should be added=
 for extra streams wanted. This allows for accepting more streams than send=
ing, which is entirely in line with the SDP RFCs.



However, the current JSEP draft misses one small fine point. Reversely,=
 it should also (MUST if you read the relevant RFC) allow for sending more =
streams than it wants to receive, ie the opposite case of the above, and th=
en send m=3D lines with the directional attribute set to sendonly. RFC 3264=
 is very clear with this: 'If the offerer wishes to only send media on a stream to =
its peer, it MUST mark the stream as sendonly with the "a=3Dsendonly&q=
uot; attribute.'



Also as part of the SDP offer/answer exchange the medias that both agen=
ts agree not to use should have the m=3D line set to inactive, ie when the =
offerer states that it wants to receive a media stream with directional att=
ribute recvonly and the answerer indicates that it is unable to send that m=
edia by setting the directional attribute to inactive (this media stream wi=
ll not be sent in any direction). The ordering and the number of media line=
s should not change during the offer/answer exchange.



Thus I suggest the following changes. Add an item to the list in 4.1.2 =
(preferably in the middle):

To convey the intention of sending a media type w=
hich is not


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 expected in return (e.g., a video presentati=
on which does not wish
=C2=A0=C2=A0=C2=A0 =C2=A0 to receive video).<=
/font>

Section 5.2.3.2. would be changed as fol=
lows:

If the "OfferToReceiveVideo" constraint is specified, with a val=
ue of


=C2=A0=C2=A0 "N", the offer MUST include N non-rejected m=3D sect=
ions with media
=C2=A0=C2=A0 type "video", even if fewer than =
N video MediaStreamTracks have been
=C2=A0=C2=A0 added to the PeerConnec=
tion. This allows the offerer to receive


=C2=A0=C2=A0 video, including multiple independent streams, even when not s=
ending
=C2=A0=C2=A0 it; accordingly, the directional attribute on the vi=
deo m=3D sections
=C2=A0=C2=A0 without associated MediaStreamTracks MUST=
 be set to recvonly. If

=C2=A0=C2=A0 this constraint is specified in the case where at least N vide=
o

=C2=A0=C2=A0 MediaStreamTracks have already been added to the PeerConnectio=
n, or N
=C2=A0=C2=A0 non-rejected m=3D sections with media type "vi=
deo" would otherwise be
=C2=A0=C2=A0 generated, the offer MUST s=
et the directional attribute to sendonly


=C2=A0=C2=A0 for the MediaStreamTracks in the video m=3D section for the re=
maining
=C2=A0=C2=A0 MediaStreamTracks of type video beyond N. The d=
irectional attribute
=C2=A0=C2=A0 for MediaStreamTracks of type video no=
t set to sendonly or recvonly


=C2=A0=C2=A0 SHOULD be set to sendrecv unless inactive. For backwards compa=
tibility,
=C2=A0=C2=A0 a value of "=
true" is interpreted as equivalent to N=3D1 and a value of


=C2=A0=C2=A0 "false" is interpreted as equivalent to N=3D0.<=
br>


The change in the paragraph above is mostly clarifying what previously =
was left unexplained with the words "it has no effect<=
/span>" and not touching on how to interpret a value of false. Section=
 5.2.3.1. would need to be changed in a similar way.



These changes would be make it comply with RFC 3264 and 4566 and also b=
e in line with the somewhat unclear w3c spec on WebRTC.

=

Regards,
Martin Ekblom
Front-end Developer
www.icewarp.com


=C2=A0




-----Original Message-----
From: &=
quot;Justin Uberti" <juberti@google.com>
To: rtcweb@ietf.org, martin.ekblom@icewarp.com


Date: 14/07/2014 04:20
Subject: About the current JSEP-06 draft

<=
div dir=3D"ltr">=C2=A0
=C2=A0=C2=A0
Adding rtcweb@ietf.org, the right mailing list=
 for this.





This behavior (of OfferToReceiveAudio/Video) was added to be conforman=
t with Unified Plan, where each media stream requires its own m=3D line, an=
d therefore the offerer needs the ability to advertise additional m=3D line=
s if it needs to receive more media streams than it is offering.







I agree that the w3c spec's handling of this topic could be clarif=
ied.
=C2=A0


=C2=A0
O=
n Wed, Jul 2, 2014 at 2:37 AM, Martin Ekblom <martin.ekblom@icewa=
rp.com> wrote:



Hi,

I believe there is a conceptual m=
isunderstanding in section 5.2.3.1. and 5.2.3.2. It seems to contradict the=
 requirements of RFC 3264 / 4566 (SDP offers and answers) and not be in lin=
e with the WebRTC draft. I would like to contribute to improve or clarify t=
his section, or in case I'm mistaken confirm this.



Is this the appropriate mailing list to disuss this?

Regards,Martin Ekblom
Front-end Developer
www.icewarp.com




=C2=A0


=C2=A0
=C2=A0


=C2=A0


=C2=A0


=C2=A0





--089e011845ead5e55f04fe663afa--


From nobody Thu Jul 17 18:09:38 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009281A0328 for ; Thu, 17 Jul 2014 18:09:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 ykLhf1BjdzMW for ; Thu, 17 Jul 2014 18:09:34 -0700 (PDT)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 729951A014E for ; Thu, 17 Jul 2014 18:09:34 -0700 (PDT)
Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta08.westchester.pa.mail.comcast.net with comcast id TcGD1o0010Fqzac58d9aQx; Fri, 18 Jul 2014 01:09:34 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id Td9Z1o00i3ZTu2S3Ud9Z4R; Fri, 18 Jul 2014 01:09:33 +0000
Message-ID: <53C873CD.7080308@alum.mit.edu>
Date: Thu, 17 Jul 2014 21:09:33 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405645774; bh=HaCw1dGsW3KOGRT5nQx/JD+J6B6dUChoRnSzW+2bpD4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hS6kAVrlS8rHDSWAl6sSaICvPG9vEHHQIJ5tXP5nfjmuwzgFwJncDjTNg05g/nWjK p4Sa7aluxJsB1ytEdx9kCjZZtpIUDzI9h1IeoeNsdO9mA5XlXqnYqxpKE1IES7GOnf 13dvgkooSNJdIU8imNmESwUlivUrGRJDnbCalOdWrUopcXWu4Ndowb0zlnH7Ep+lAe j3/Z5ZHF2MZLAZ9GOh45KEg3iQPk+WYeFU9sTyXAJCAiy6AkHU52ReW+wGVLpIQZbh 4yX9nUSaTypW/QoEQl1TzAmlkPIIdEXWi33CWwe4UxtSdVT/1pWX4+mcXb1PLauOM4 +IUdWgrtrcckQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/21PILsCMZPk8KvLvcafV9Unan6c
Subject: [rtcweb] Review of draft-ietf-rtcweb-overview-10
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 18 Jul 2014 01:09:36 -0000

I haven't read the overview carefully in a long time. This time I did.
I came away with the following thoughts:

Terminology:

    Media path:  The path that media data follows from one browser to
       another.

I don't think this is quite right by restricting to browsers. I think 
you mean:

    Media path:  The path that media data follows from one WebRTC device
       to another.

The intent is clear (e.g. from figure 2) but the definition doesn't say it.

Also, why aren't "WebRTC browser" and "WebRTC device" included in the 
Terminology section? Seems like they should be.

Section 5:

    Considerations for the transfer of data that is not in RTP format is
    described in [I-D.ietf-rtcweb-data-channel], and a supporting
    protocol is described in [I-D.ietf-rtcweb-data-protocol].  Webrtc
    devices MUST implement these two specifications.

Actually ietf-rtcweb-data-protocol only describes a protocol used for 
data channel *establishment*. As such, I think it is technically a 
Connection management protocol. This becomes more evident when you 
consider all the discussion on how to establish channels via SDP.

In principle I think ietf-rtcweb-data-protocol should be referenced from 
section 7. If that seems heretical, then how about at least saying:

    Considerations for the transfer of data that is not in RTP format is
    described in [I-D.ietf-rtcweb-data-channel], and a supporting
    protocol for establishing individual data channels is described in
    [I-D.ietf-rtcweb-data-protocol].  Webrtc devices MUST implement
    these two specifications.

Otherwise this document is remarkably clear.

	Thanks,
	Paul


From nobody Thu Jul 17 18:59:25 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2931B27C9 for ; Thu, 17 Jul 2014 18:59:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 BTlO2GMi6ytt for ; Thu, 17 Jul 2014 18:59:19 -0700 (PDT)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 304301A03A9 for ; Thu, 17 Jul 2014 18:59:18 -0700 (PDT)
Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta02.westchester.pa.mail.comcast.net with comcast id TdUB1o00C1GhbT851dzJrP; Fri, 18 Jul 2014 01:59:18 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id TdzJ1o00Q3ZTu2S3TdzJV1; Fri, 18 Jul 2014 01:59:18 +0000
Message-ID: <53C87F76.8070007@alum.mit.edu>
Date: Thu, 17 Jul 2014 21:59:18 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405648758; bh=NhXNWgzTqf9scDnx2antt8umyPrCetsG/TTKelWBeSY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=taNk/YsUFxEHCKeplFj6CHCffacBAnEFuBEq7TEU3J5ZoJFxwtRAYVqaMFgm11sdH klbaPzGJnwOrMnZWA8uO5NACSj1dZnsinuajZ5+0PwLwSnziOki6mNLKVmq7ZOVRZ6 or3FKiehcUl2YeGlGaZUFQXU3h8u1FH2kq2vIZZOamWoFevKc61h/RO2PgEkGWkYA1 npp0PUm5Pb10tXHH17lF0XuZtzU9m65XmkPL1FkvW7Ad77zeu5hLB5SK9UdT2Lil2V RxHjbyeYcOKcAgHCWACepAi9mhByy5rDRskxBzqHmTun7NhbIYTltlD3nbQJ9bw6nk vOUnC01MpSFPw==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0RfNCamiqohJhDZFdXzcbjThqdk
Subject: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness-05
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 18 Jul 2014 01:59:22 -0000

Some comments from reading the latest version:

Introduction:

    WebRTC endpoints are required to support full ICE as specified in
    section 3.4 of [I-D.ietf-rtcweb-transports].  However, when WebRTC
    endpoints interwork with other endpoints that support only ICE-lite
    (e.g. gateways) those endpoints will not generate consent checks, but
    just respond to consent checks they receive.

Having just read the overview document, I question the terminology 
above. The following would be more consistent with the overview:

    WebRTC browsers are required to support full ICE as specified in
    section 3.4 of [I-D.ietf-rtcweb-transports].  However, when WebRTC
    browsers interwork with other WebRTC devices that support only
    ICE-lite (e.g. gateways) those endpoints will not generate consent
    checks, but just respond to consent checks they receive.

or perhaps you mean:

    WebRTC devices are required to support full ICE as specified in
    section 3.4 of [I-D.ietf-rtcweb-transports].  However, when WebRTC
    devices interwork with other endpoints that support only ICE-lite
    (e.g. gateways) those endpoints will not generate consent checks, but
    just respond to consent checks they receive.

Section 4.1:

    ...  To prevent expiry of consent, a STUN binding
    request is sent every N milliseconds, where N SHOULD be 5000
    milliseconds and MUST be randomized at least 20% above and 20% below
    that value (to prevent prevent network synchronization).  Using the
    value 5000 milliseconds and that 20% randomization range, N would be
    a value between 4000 and 6000.  ...

The normative requirement is weird here. (I MUST do the randomization, 
but that forces me to violate the SHOULD.) Do you mean the central value 
SHOULD be 5000, but in the case that it is some other value then the 
range should be from 20% below to 20% above that value? Would that 20% 
be appropriate if I changed N to 500 or 50000? Also, is the 
randomization to be done once for the session, or repeated for each 
consent request that is sent?

I think the following gives the same rule in an easier to understand way:

    ...  To prevent expiry of consent, a STUN binding request MUST be
    every N milliseconds, where N is chosen randomly in the interval
    [.8N, 1.2N] (to prevent prevent network synchronization), where N
    SHOULD be 5000.  Using the value 5000 milliseconds and that 20%
    randomization range, N would be a value between 4000 and 6000.  ...

Note this is equivalent to [N, 1.5N] with the recommended value of N 
changed to 4000. That might be easier.

(And, if I remember my math, it would be more proper to write the 
interval as "[N, 1.5N)". But that may be disturbing to programmers. As a 
programmer I'd more likely write "[N, int(1.5N)-1]", but that is ugly in 
text.)

	Thanks,
	Paul


From nobody Thu Jul 17 19:19:49 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8054B1B27C9 for ; Thu, 17 Jul 2014 19:19:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CsaDD5DC9mJ for ; Thu, 17 Jul 2014 19:19:46 -0700 (PDT)
Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6CC41A0117 for ; Thu, 17 Jul 2014 19:19:45 -0700 (PDT)
Received: by mail-wg0-f47.google.com with SMTP id b13so2767420wgh.18 for ; Thu, 17 Jul 2014 19:19:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eAJTfZkYr4kJbtZzyAA2ClrnM0PLGX+W7R2Ux9PdxP4=; b=BQBvLqE8Q2igzwfyg5h2obyoIeNEZUo5IwcUKdzpNSkhhQoDEfT+KI4ruIaN4o942J Vus11JNR8Scwfsd+gKc0akC5wdiRShN/s9HbV+PnM5fPbhVUVvhSSqVtl6ROvidC3sji 8UYUhjmJdfa9X4mcOEL28YIOZfpfnb2+Tsq+HCEoqZCc+I5S0caHainKO8i05y502VIl rHc65eAnXY5ebuZDIkGAxnc4IOaab5ZNcaQl2xGkzm3ExJfAB4Kli/q+jQwpGE5VkU1r qDrPZpK+Bebfqph9v9ebJZuun+ooODUVPxcSKq3N7STT4afGSNwStzaxA/rdk0WTH/5y HxDw==
MIME-Version: 1.0
X-Received: by 10.180.228.104 with SMTP id sh8mr27906148wic.64.1405649984317;  Thu, 17 Jul 2014 19:19:44 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Thu, 17 Jul 2014 19:19:44 -0700 (PDT)
In-Reply-To: <53C87F76.8070007@alum.mit.edu>
References: <53C87F76.8070007@alum.mit.edu>
Date: Thu, 17 Jul 2014 19:19:44 -0700
Message-ID: 
From: Martin Thomson 
To: Paul Kyzivat 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NixUhEtGvgxhel2QqxCLLVaRa_k
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness-05
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 18 Jul 2014 02:19:47 -0000

On 17 July 2014 18:59, Paul Kyzivat  wrote:
>    WebRTC devices are required to support full ICE as specified in
>    section 3.4 of [I-D.ietf-rtcweb-transports].  However, when WebRTC
>    devices interwork with other endpoints that support only ICE-lite
>    (e.g. gateways) those endpoints will not generate consent checks, but
>    just respond to consent checks they receive.

Yes, this.

> Section 4.1:
>
>    ...  To prevent expiry of consent, a STUN binding
>    request is sent every N milliseconds, where N SHOULD be 5000
>    milliseconds and MUST be randomized at least 20% above and 20% below
>    that value (to prevent prevent network synchronization).  Using the
>    value 5000 milliseconds and that 20% randomization range, N would be
>    a value between 4000 and 6000.  ...

We've just discussed this particular point and concluded that the
randomization requirement isn't necessary, since there is no need for
any sort of lock step avoidance in a peer-to-peer system like this.


From nobody Thu Jul 17 20:04:45 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4681A040F for ; Thu, 17 Jul 2014 20:04:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 EFQn30YRoAEm for ; Thu, 17 Jul 2014 20:04:41 -0700 (PDT)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id B4E581A03CA for ; Thu, 17 Jul 2014 20:04:40 -0700 (PDT)
Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta05.westchester.pa.mail.comcast.net with comcast id TeyZ1o0020vyq2s55f4gxk; Fri, 18 Jul 2014 03:04:40 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id Tf4g1o0023ZTu2S3Rf4gQg; Fri, 18 Jul 2014 03:04:40 +0000
Message-ID: <53C88EC8.1010605@alum.mit.edu>
Date: Thu, 17 Jul 2014 23:04:40 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405652680; bh=bZQbdH1Q4DdbUucjZxbN+jOxSBdvXBKK9x4Iwp3LmE0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=uXRJ9I5qtNdGVEYYkkqvuSgjA26+VJ497aq+GpJ3P5agQ8Nrdj1H3oUpiH5b2L2n9 9aNTbUvi65QkhDzFWRTKrTAmaiiOuRSbB0O0SWrsFYfR1sahvr7cOJ99vgS1YE35am PXSkxIxl4GPi8byU5ZSNseHPLG1jJP4yV8sNiJEu1tpgG9DX5Fa8gW0ZHl0eyfobal N1FUHYGtDMZDsYU0qQMPGAzYwtNNoz8gtFwIjZBTLJHRtS1FMQUTi7TRqiwcTISTvO jC1HqAaimUC8IUT0SB9pScMO1GoUmpSTc8UqljAT8erl8Fjb3aOttlqTdaxA0lZfEo orOqDdqOyp99g==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/TQtaDjXOEF8_JXC5Oa_l3iI8Sio
Subject: [rtcweb] Questions on draft-ietf-rtcweb-rtp-usage-15
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 18 Jul 2014 03:04:42 -0000

I have a couple of questions after reading this draft:

Section 4.9 says:

    Taking the discussion in Section 11 into account, a WebRTC end-point
    MUST NOT use more than one RTCP CNAME in the RTP sessions belonging
    to single RTCPeerConnection (that is, an RTCPeerConnection forms a
    synchronisation context).

and then Section 11 says:

    ... This is motivating the
    strong recommendation in Section 4.9 to only use a single CNAME.

       The requirement on using the same CNAME for all SSRCs that
       originate from the same end-point, does not require a middlebox
       that forwards traffic from multiple end-points to only use a
       single CNAME.

So one is MUST strength, and the other seems to be SHOULD strength. 
Which is it?

And isn't this "middlebox" a WebRTC end-point? If so then that is 
another conflict.

Is it really that WebRTC *browsers* must use one CNAME, while other 
WebRTC *devices* have more freedom? That seems to make sense since an 
RTCPeerConnection is only a browser thing.

	Thanks,
	Paul


From nobody Thu Jul 17 20:17:17 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666781B2815 for ; Thu, 17 Jul 2014 20:17:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 3Bt_V5flJv2D for ; Thu, 17 Jul 2014 20:17:14 -0700 (PDT)
Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3111B27DC for ; Thu, 17 Jul 2014 20:17:14 -0700 (PDT)
Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta06.westchester.pa.mail.comcast.net with comcast id TesF1o00117dt5G56fHE3E; Fri, 18 Jul 2014 03:17:14 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id TfHD1o00U3ZTu2S3ZfHEUv; Fri, 18 Jul 2014 03:17:14 +0000
Message-ID: <53C891B9.6060103@alum.mit.edu>
Date: Thu, 17 Jul 2014 23:17:13 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Martin Thomson 
References: <53C87F76.8070007@alum.mit.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405653434; bh=d3RffazbNehKXQ1CjLruXLJUmRRNK8MtfeGfSZOCWKU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ubBnNti2ETf+J5kNGX5/m4v1uRFT+SHy2kTPV0+QC9xYcpEi3UMCkkN05i1BjW++j 1JQ3jz+j4T/fFMMO9iRqLUjCROS/Pmlsz6RIdheTnF08VkqfJ5tRoitiHYK3Pm65Wh 9z/sHT4flFIyrD5WK4dZUBja/niMnqSOsWbWomflyaecTgG6jZEVTAQytz2vTTA4EQ +gNodi6S54lEVVdvCERRL001Y8MW8OrNpKNSlCKir4RFAP6yWJVLhb+IPBaFO8z2Ke +UnTlDgrIM60DmtE3Ca+VGyAqeSrJIWX27mCgi8smQgm6hMej/P7sraE3bv4N9ZJxc JOg0kKPIy9H3w==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MKHNNrx-OE2sJnMuC0crQBJKcxY
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness-05
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 18 Jul 2014 03:17:15 -0000

On 7/17/14 10:19 PM, Martin Thomson wrote:
> On 17 July 2014 18:59, Paul Kyzivat  wrote:
>>     WebRTC devices are required to support full ICE as specified in
>>     section 3.4 of [I-D.ietf-rtcweb-transports].  However, when WebRTC
>>     devices interwork with other endpoints that support only ICE-lite
>>     (e.g. gateways) those endpoints will not generate consent checks, but
>>     just respond to consent checks they receive.
>
> Yes, this.

OK.

>> Section 4.1:
>>
>>     ...  To prevent expiry of consent, a STUN binding
>>     request is sent every N milliseconds, where N SHOULD be 5000
>>     milliseconds and MUST be randomized at least 20% above and 20% below
>>     that value (to prevent prevent network synchronization).  Using the
>>     value 5000 milliseconds and that 20% randomization range, N would be
>>     a value between 4000 and 6000.  ...
>
> We've just discussed this particular point and concluded that the
> randomization requirement isn't necessary, since there is no need for
> any sort of lock step avoidance in a peer-to-peer system like this.

Will these two be covered in -06?

	Thanks,
	Paul


From nobody Thu Jul 17 20:27:52 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1461A0452 for ; Thu, 17 Jul 2014 20:27:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZXvbcTztk2Z for ; Thu, 17 Jul 2014 20:27:49 -0700 (PDT)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 929901A0418 for ; Thu, 17 Jul 2014 20:27:49 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id bs8so142090wib.2 for ; Thu, 17 Jul 2014 20:27:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lile/T3+hsJ1cqmSGQt6luk9xSfzonfzZI9BFfMzR/I=; b=QdSkWGLWsQCRslZC3sYTpg7zo4W7kZ34DIfSytvmAGXt0m9PHLwaIuxyeBRBKuqZ3m MtbMcL+Guy8dppfBU4uTno0K6RjHaejITrPQq/ygAy6T/GC+Ai/52nZdhD3VT2MJjNp2 v2JVpje0U4j3cUuQNTL7LmahQVovkdqXG4myA1SJNpCfyccjs1kpM1Id6MalWFKpevbm XJT+abXm9Fhh36bW1RkqD0JrKKFE6W6HYPNPYYwYTwdMO5kSR5BCnDpPAZ6SUW7tX808 2lHVnNNPAuzPzMW0oNsEoMRYoLh6vllRrwQMUe6caIKKMILlwGcXGrjwg2E3lHbHJr6f GVSg==
MIME-Version: 1.0
X-Received: by 10.180.92.38 with SMTP id cj6mr3432068wib.64.1405654068145; Thu, 17 Jul 2014 20:27:48 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Thu, 17 Jul 2014 20:27:48 -0700 (PDT)
In-Reply-To: <53C891B9.6060103@alum.mit.edu>
References: <53C87F76.8070007@alum.mit.edu>  <53C891B9.6060103@alum.mit.edu>
Date: Thu, 17 Jul 2014 20:27:48 -0700
Message-ID: 
From: Martin Thomson 
To: Paul Kyzivat 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/b07yseDVplH-19HlpHEme09HcB8
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness-05
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 18 Jul 2014 03:27:51 -0000

On 17 July 2014 20:17, Paul Kyzivat  wrote:
> Will these two be covered in -06?

I should have said, this was a Mozilla discussion, not a co-author
discussion.  And fairly fresh.  I hope so.


From nobody Fri Jul 18 11:32:29 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5791B29CA for ; Fri, 18 Jul 2014 11:32:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 ZhiCn8z8Sa4a for ; Fri, 18 Jul 2014 11:32:25 -0700 (PDT)
Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 497001B29D9 for ; Fri, 18 Jul 2014 11:32:25 -0700 (PDT)
Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta12.westchester.pa.mail.comcast.net with comcast id TuWi1o00127AodY5CuYQSe; Fri, 18 Jul 2014 18:32:24 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id TuYQ1o00c3ZTu2S3fuYQyB; Fri, 18 Jul 2014 18:32:24 +0000
Message-ID: <53C96838.6020507@alum.mit.edu>
Date: Fri, 18 Jul 2014 14:32:24 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405708344; bh=oUNrQlw/GgZFtB6tjQsnc35FqjD+qDDp7+ixMUoQVdg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=S/ZUauiyHoR/xDdSsyuwa3op3FjtwC4979KXqUi64P9avtGet77PYYbpaSaI5UP0F j3Vubqo/PFiIJ8PJTZtJfm38wRZTmWrsZzhxi/qwv2DCJqpLE07jMo5ZjafHoQN1j/ 0MkIlAYaSJ6fyEnbFcdu5rs4c88nQZLplDi4ZlR43YkrkHPUIwUHaMaDx65i2tm26E A5YKYIiD/3okKWGLaROCPhyL9lCebB0SwQtHbx+GZOQtC/+AUkfG82mOiuPZWRd82W WEziOXNFW9RaYf1JcVAHH9p9JhE7ix077YTGMseCIfGat04KDWKjpiZoCbt+u3YTtF tn2apfoKA2wkw==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/eEkkktvVMoE0LOG40a0xL8EO6Eg
Subject: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 18 Jul 2014 18:32:26 -0000

I just did my first thorough read-through of JSEP in quite some time. I 
came away with a number of concerns:

Section 1.1:

When describing offers, modification by the application is mentioned:

    JSEP's handling of session descriptions is simple and
    straightforward.  Whenever an offer/answer exchange is needed, the
    initiating side creates an offer by calling a createOffer() API.  The
    application *optionally modifies that offer*, and then uses it to set
    up its local config via the setLocalDescription() API.

but when describing answers it is not:

    When the call is accepted, the callee uses the createAnswer() API to
    generate an appropriate answer, applies it using
    setLocalDescription(), and sends the answer back to the initiator
    over the signaling channel.  When the offerer gets that answer, it
    installs it using setRemoteDescription(), and initial setup is
    complete.

And Section 6 only talks about changing offers, not answers. It is 
equally important to be able to modify answers. (More on this in later 
comment on section 6.)

Section 4.1.4:

    The only difference between a provisional and final answer is that
    the final answer results in the freeing of any unused resources that
    were allocated as a result of the offer.  As such, the application
    can use some discretion on whether an answer should be applied as
    provisional or final, and can change the type of the session
    description as needed.  For example, in a serial forking scenario, an
    application may receive multiple "final" answers, one from each
    remote endpoint.  The application could choose to accept the initial
    answers as provisional answers, and only apply an answer as final
    when it receives one that meets its criteria (e.g. a live user
    instead of voicemail).

Issue: in this forking case, until the final selection is made it is 
unclear which one will need ICE completed. Only when a setlocal is done 
on one of the answers will ICE begin to be performed. Then, if another 
answer is provisionally set, won't that stop ICE for the prior one? And 
won't it require new candidates? What if one of the earlier ones is 
eventually chosen as final?

And what if ICE completes for one of the candidates? Can't media start 
to flow? Then what if a different candidate is set as the final answer?

Section 4.1.4.1:

I question the following:

    ...  While it is good practice to send an immediate
    response to an "offer", in order to warm up the session transport and
    prevent media clipping, the preferred handling for a web application
    would be to create and send an "inactive" final answer immediately
    after receiving the offer.  Later, when the called user actually
    accepts the call, the application can create a new "sendrecv" offer
    to update the previous offer/answer pair and start the media flow.

This is very unfriendly when receiving calls that might be forked. By 
immediately "answering" a call before knowing if the user will accept 
it, you preempt the possibility that it will be answered on some other fork.

For instance, if a call could come to your browser, or be sent to an 
answering service, and your broswer is on but you aren't present to 
accept the call, then the call will be accepted and then dropped rather 
than sent to the answering machine.

So this technique should not be used if there is any possibility that 
the request could be coming from a source that might try other 
possibilities.

Section 5.2.1:

    When createOffer is called for the first time, the result is known as
    the initial offer.

By this definition, if a peer connection initially *received* an offer 
and sent an answer, and then it later sends an offer then that offer 
would be considered an initial offer.

I think perhaps what is intended is:

    When createOffer is called before setLocal has been called with
    an offer,  the result is known as the initial offer.

The following doesn't support the "balanced" BUNDLE policy:

    Once all m= sections have been generated, a session-level "a=group"
    attribute MUST be added as specified in [RFC5888].  This attribute
    MUST have semantics "BUNDLE", and MUST include the mid identifiers of
    each m= section.  The effect of this is that the browser offers all
    m= sections as one BUNDLE group.  However, whether the m= sections
    are bundle-only or not depends on the BUNDLE policy.

Section 5.2.2 says:

    o  If any MediaStreamTracks have been added, and there exist recvonly
       m= sections of the appropriate media type with no associated
       MediaStreamTracks, or rejected m= sections of any media type,
       those m= sections MUST be recycled, and a local MediaStreamTrack
       associated with these recycled m= sections until all such existing
       m= sections have been used.  This includes any recvonly or
       rejected m= sections created by the preceding paragraph.

This fails to say anything about codec compatibility. SDP O/A requires 
the answer to be a subset of the offer in terms of PT/codec 
configuration. You should not use the same m-line unless there is a 
desire to use the same settings for the new track as are currently in 
use in the other direction.

Section 5.3.1:

    When createAnswer is called for the first time after a remote
    description has been provided, the result is known as the initial
    answer.

By this definition, if a peer connection initially sent an offer and 
received an answer, and then it later receives an offer then the answer 
to that first *received* offer would be considered an Initial Answer.

I think perhaps what is intended is:

    When createAnswer is called before setLocal has been called with
    an offer,  the result is known as the initial answer.

When specifying the mapping of local tracks to m-lines in a received 
offer, there is again no discussion of codec compatibility. It is quite 
possible that the m-line chosen by the algorithm in this section won't 
have compatible codec attributes, but some other m-line will.

Sections 5.3.2, 5.3.3, and 5.4-5.7:

Are these empty because the content is yet to be written?

Section 6:

Other likely changes are addition of extra attributes and maybe other 
parameters. For instance, CLUE will want to add another grouping construct.

	Thanks,
	Paul


From nobody Fri Jul 18 19:41:24 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3125D1A01F3 for ; Fri, 18 Jul 2014 19:41:19 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -5.184
X-Spam-Level: 
X-Spam-Status: No, score=-5.184 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lx2mceDDJReV for ; Fri, 18 Jul 2014 19:41:16 -0700 (PDT)
Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752CC1A0172 for ; Fri, 18 Jul 2014 19:41:16 -0700 (PDT)
Received: from epcpsbgr2.samsung.com (u142.gpu120.samsung.co.kr [203.254.230.142]) by mailout2.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N8X009WCU4PEO30@mailout2.samsung.com> for rtcweb@ietf.org; Sat, 19 Jul 2014 11:41:13 +0900 (KST)
Received: from epcpsbgx1.samsung.com ( [172.20.52.122]) by epcpsbgr2.samsung.com (EPCPMTA) with SMTP id 0C.8A.19452.9CAD9C35; Sat, 19 Jul 2014 11:41:13 +0900 (KST)
X-AuditID: cbfee68e-b7fb96d000004bfc-bf-53c9dac94847
Received: from epmailer02 ( [203.254.219.142]) by epcpsbgx1.samsung.com (EPCPMTA) with SMTP id F7.C9.03708.9CAD9C35; Sat, 19 Jul 2014 11:41:13 +0900 (KST)
Message-id: <08.C9.03708.9CAD9C35@epcpsbgx1.samsung.com>
Date: Sat, 19 Jul 2014 02:41:13 +0000 (GMT)
From: Kiran Kumar Guduru 
To: "rtcweb-request@ietf.org" , "rtcweb@ietf.org" , pkyzivat@alum.mit.edu
MIME-version: 1.0
X-MTR: 20140719022453642@kiran.guduru
Msgkey: 20140719022453642@kiran.guduru
X-EPLocale: en_US.windows-1252
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20140719022453642@kiran.guduru
X-ParentMTR: 
X-ArchiveUser: 
X-CPGSPASS: N
MIME-version: 1.0
Content-type: multipart/related; boundary="=_NamoWEC-u3a74ohxi5"
X-Generator: Namo ActiveSquare 7 7.0.0.45
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGKsWRmVeSWpSXmKPExsWyRsSkSvfkrZPBBh8nm1ms/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujP13djMVNPxnrPjTeYSpgXH6D8YuRk4OIQF1iQ2r77GB2BIC JhJnXu5ihbDFJC7cWw8U5wKqWcooMeP2akaYosYtFxkhEnMYJd4+2w+W4BWwkDh0eSKYzSKg KrH6SCvYVDaghl8n1gDFOTiEBSwlHhxMAgmLCNRI/D64kgniCCWJtVdvskKMEZQ4OfMJC8Qu VYnPaz5AxdUk1sy9AXWonMSSqZeZIGxeiRntT1lg4tO+rmGGsKUlzs/awAjzzOLvj6Hi/BLH bu9gAjkHpPfJ/WCYMbs3f4EaLyAx9cxBqFYtiYvL70DDhE9izcK3LDBjdp1azgzTe3/LXCZU 53NwMAs4SVw6lg5RoinxaFErCyjUJAQOcEisbN/HMoFRaRaSFlQ2XDtImFnAUOLLvMeMELai xJTuh+wQJXYS1z9kogqD2KoSV45cY17AyLGKUTS1ILmgOCm9yEivODG3uDQvXS85P3cTIzDx nP73rG8H480D1ocYq4BxNpFZSjQ5H5i48kriDY3NjCxMTUyNjcwtzagirCTOu+hhUpCQQHpi SWp2ampBalF8UWlOavEhRiYOTqkGxknlwa6vTu+wVit81rL9dEp70tV031lO8zxllymVd7xe WprxvJbR+qB5TNyDhRJuXGl6n6Oi/tRfuiR/iWMW4+I5WqsDLLhmpz+XXr4ozuTEP6sLuyrn LXezk7Levy1G7GXE9MeNQc8mb+XoUfosU1XkcGuSfUNs4rad2825ZvVcXrkz0K36vRJLcUai oRZzUXEiAE5DlBFpAwAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEJsWRmVeSWpSXmKPExsVy+t/tPt2Tt04GG+w8oGWx9l87uwOjx5Il P5kCGKPSbDJSE1NSixRS85LzUzLz0m2VvIPjneNNzQwMdQ0tLcyVFPISc1NtlVx8AnTdMnOA pioplCXmlAKFAhKLi5X07WyK8ktLUhUy8otLbJWiDc2N9IwM9EyN9AxNY60MDQyMTIFqEtIy 9t/ZzVTQ8J+x4k/nEaYGxuk/GLsYOTmEBNQlNqy+xwZiSwiYSDRuucgIYYtJXLi3HijOBVQz h1Hi7bP9YAkWAVWJ1UdawRrYgBp+nVgDFOfgEBawlHhwMAkkLCJQI/H74EomiPlKEmuv3mQF sXkFBCVOznzCAjFfVeLzmg9QcTWJNXNvQN0gJ7Fk6mUmCJtXYkb7UxaY+LSva5ghbGmJ87M2 wN25+PtjqDi/xLHbO5hAzgHpfXI/GGbM7s1foMYLSEw9cxCqVUvi4vI7rBA2n8SahW9ZYMbs OrWcGab3/pa5TKjO5+BgFnCSuHQsHaJEU+LRolaWCYwys5BUobLhOkDCzAKGEl/mPWaEsBUl pnQ/ZIcosZO4/iETVRjEVpW4cuQa8wJGjlWMoqkFyQXFSekVhnrFibnFpXnpesn5uZsYwcns 2cIdjF/OWx9iFOBgVOLh3aF1MliINbGsuDL3EKMK0JxHG1ZfYJRiycvPS1US4XVZA5TmTUms rEotyo8vKs1JLT7EOJERGMMTmaVEk/OBKTivJN7Q2MTc1NjUwsDQ3NyMlsJK4rx3byYFCQmk J5akZqemFqQWwRzFxMEp1cA4LyJ+/8mKhP9b961V0XVUlTpia57JmKo96e5S+ds9PFNjGf++ iV+mfnWGTlvdpYueR58Y63q4Xt5itCL3xN3ChuQCEVPvmg/FjtKLq5+zJ51JYNPt3fMpSv1z yqwDZVYC/4ovmZ29U/hwqk2og/rNl4q31Vb2Om65oHPr7AHOw5pXhb5MPH9HiaU4I9FQi7mo OBEAgbCdfeUDAAA=
DLP-Filter: Pass
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-ft7OObwCUFzns11qpXX7ewCLZA
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: kiran.guduru@samsung.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: Sat, 19 Jul 2014 02:41:19 -0000

--=_NamoWEC-u3a74ohxi5
Content-Type: text/html;
	charset="windows-1252"
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PHRpdGxlPlNhbXN1bmcgRW50ZXJwcmlzZSBQb3J0YWwgbXlTaW5nbGU8L3Rp
dGxlPgo8bWV0YSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9d2luZG93cy0xMjUyIiBodHRw
LWVxdWl2PSJDb250ZW50LVR5cGUiPgo8c3R5bGUgaWQ9Im15c2luZ2xlX3N0eWxlIiB0eXBlPSJ0
ZXh0L2NzcyI+UCB7CglNQVJHSU4tVE9QOiA1cHg7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJpYWw7
IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiA5cHQKfQpURCB7CglNQVJHSU4tVE9QOiA1
cHg7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJpYWw7IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1T
SVpFOiA5cHQKfQpMSSB7CglNQVJHSU4tVE9QOiA1cHg7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJp
YWw7IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiA5cHQKfQpCT0RZIHsKCUxJTkUtSEVJ
R0hUOiAxLjQ7IE1BUkdJTjogMTBweDsgRk9OVC1GQU1JTFk6IEFyaWFsLCBhcmlhbDsgRk9OVC1T
SVpFOiA5cHQKfQo8L3N0eWxlPgoKPG1ldGEgbmFtZT0iR0VORVJBVE9SIiBjb250ZW50PSJBY3Rp
dmVTcXVhcmUiPgo8L2hlYWQ+PGJvZHk+CjxwPkRlYXIgUGF1bCw8L3A+CjxwPiZuYnNwOzwvcD4K
PHA+TXkgY29tbWVudCBpcyBvbmx5IHJlZ2FyZGluZyB0aGUgY29tbWVudHMgb24gc2VjdGlvbiA2
IG9mIHRoZSBKU0VQIGRyYWZ0LjwvcD4KPHA+VGhlIHNkcCBtYW5nbGluZyBkZXNjcmliZWQgaW4g
c2VjdGlvbiA2IG1heSByZXN1bHQgaW4gdmFyaW91cyBlcnJvciBzY2VuYXJpb3MuPC9wPgo8cD5J
biB0aGF0IHNlY3Rpb24sIGl0IGlzIGRlc2NyaWJlZCBsaWtlIG1vc3Qgb2YgdGhlIHBhcmFtZXRl
cnMgY2FuIGJlIG1vZGlmaWVkIHRob3J1Z2ggY29uc3RyYWludHMuPC9wPgo8cD5UaGUgcmVxdWly
ZWQgbW9kaWZpY2F0aW9uLCBJIGZvdW5kLCB3aGljaCZuYnNwO2Nhbm5vdCBub3QgYmUgZG9uZSBi
eSB0aGUgY29uc3RyYWludHMgaXMgIlJlbW92ZSBvciByZW9yZGVyIG9mIGNvZGVjcyAobT0pIjwv
cD4KPHA+SW4gb3JkZXIgdG8gYXZvaWQgdGhlIFNEUCBtYW5nbGluZyBhdCBKYXZhIFNjcmlwdCBh
cHBsaWNhdGlvbiBsZXZlbCwgSSBzdWJtaXR0ZWQgYSBkcmFmdCBmb3IgY2hhbmdpbmcgdGhlIGNv
ZGVjIHByZWZlcmVuY2VzIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LWd1ZHVydS1ydGN3ZWItY29kZWMtcHJlZmVyZW5jZXMtMDEiPmh0dHA6Ly90b29scy5pZXRmLm9y
Zy9odG1sL2RyYWZ0LWd1ZHVydS1ydGN3ZWItY29kZWMtcHJlZmVyZW5jZXMtMDE8L2E+LiAoUGxl
YXNlIHJldmlldyBpdCkuPC9wPgo8cD5JZiB0aGlzIHByb3Bvc2FsIGlzIGFjY2VwdGFibGUgdG8g
dGhlIGdyb3VwLCBJIGhvcGUgd2UgY2FuIHJlbW92ZSBzZWN0aW9uIDYgZnJvbSBKU0VQIGRyYWZ0
LiA8L3A+CjxwPihFeHBlY3RpbmcgdGhhdCB3ZSBjYW4gZmluZCBhbHRlcm5hdGl2ZXMgZm9yIGFk
ZGluZyBleHRyYSBhdHRyaWJ1dGVzIGxpa2UgQ0xVRSBhcyBpZGVudGlmaWVkIGJ5IHlvdSwgZm9y
IGV4YW1wbGUmbmJzcDtieSBleHRlbmRpbmcgdGhlIHByb3Bvc2VkJm5ic3A7UlRDUlRQU2VuZGVy
L1JlY2VpdmVyIGJ5IGFkZGluZyBhIGdlbmVyaWMgc2V0U2RQQXR0cmlidXRlIChrZXksIHZhbHVl
KSBtZXRob2QpLjwvcD4KPHA+Jm5ic3A7PC9wPgo8cD5UaGFua3MsPC9wPgo8cD5LaXJhbi48L3A+
CjxwPjxicj48YnI+LS0tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLS0tLSA8YnI+U2VudDogUGF1
bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+PGJyPkRhdGU6IEZyaSwgMTggSnVsIDIw
MTQgMTQ6MzI6MjQgLTA0MDA8YnI+U3ViamVjdDogW3J0Y3dlYl0gUmV2aWV3IG9mIGRyYWZ0LWll
dGYtcnRjd2ViLWpzZXAtMDc8YnI+PGJyPkkganVzdCBkaWQgbXkgZmlyc3QgdGhvcm91Z2ggcmVh
ZC10aHJvdWdoIG9mIEpTRVAgaW4gcXVpdGUgc29tZSB0aW1lLiBJIDxicj5jYW1lIGF3YXkgd2l0
aCBhIG51bWJlciBvZiBjb25jZXJuczo8YnI+PGJyPlNlY3Rpb24gMS4xOjxicj48YnI+V2hlbiBk
ZXNjcmliaW5nIG9mZmVycywgbW9kaWZpY2F0aW9uIGJ5IHRoZSBhcHBsaWNhdGlvbiBpcyBtZW50
aW9uZWQ6PGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtKU0VQJ3MgaGFuZGxpbmcgb2Yg
c2Vzc2lvbiBkZXNjcmlwdGlvbnMgaXMgc2ltcGxlIGFuZDxicj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDtzdHJhaWdodGZvcndhcmQuJm5ic3A7Jm5ic3A7V2hlbmV2ZXIgYW4gb2ZmZXIvYW5zd2Vy
IGV4Y2hhbmdlIGlzIG5lZWRlZCwgdGhlPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2luaXRp
YXRpbmcgc2lkZSBjcmVhdGVzIGFuIG9mZmVyIGJ5IGNhbGxpbmcgYSBjcmVhdGVPZmZlcigpIEFQ
SS4mbmJzcDsmbmJzcDtUaGU8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YXBwbGljYXRpb24g
Km9wdGlvbmFsbHkgbW9kaWZpZXMgdGhhdCBvZmZlciosIGFuZCB0aGVuIHVzZXMgaXQgdG8gc2V0
PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3VwIGl0cyBsb2NhbCBjb25maWcgdmlhIHRoZSBz
ZXRMb2NhbERlc2NyaXB0aW9uKCkgQVBJLjxicj48YnI+YnV0IHdoZW4gZGVzY3JpYmluZyBhbnN3
ZXJzIGl0IGlzIG5vdDo8YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1doZW4gdGhlIGNh
bGwgaXMgYWNjZXB0ZWQsIHRoZSBjYWxsZWUgdXNlcyB0aGUgY3JlYXRlQW5zd2VyKCkgQVBJIHRv
PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2dlbmVyYXRlIGFuIGFwcHJvcHJpYXRlIGFuc3dl
ciwgYXBwbGllcyBpdCB1c2luZzxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzZXRMb2NhbERl
c2NyaXB0aW9uKCksIGFuZCBzZW5kcyB0aGUgYW5zd2VyIGJhY2sgdG8gdGhlIGluaXRpYXRvcjxi
cj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtvdmVyIHRoZSBzaWduYWxpbmcgY2hhbm5lbC4mbmJz
cDsmbmJzcDtXaGVuIHRoZSBvZmZlcmVyIGdldHMgdGhhdCBhbnN3ZXIsIGl0PGJyPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwO2luc3RhbGxzIGl0IHVzaW5nIHNldFJlbW90ZURlc2NyaXB0aW9uKCks
IGFuZCBpbml0aWFsIHNldHVwIGlzPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NvbXBsZXRl
Ljxicj48YnI+QW5kIFNlY3Rpb24gNiBvbmx5IHRhbGtzIGFib3V0IGNoYW5naW5nIG9mZmVycywg
bm90IGFuc3dlcnMuIEl0IGlzIDxicj5lcXVhbGx5IGltcG9ydGFudCB0byBiZSBhYmxlIHRvIG1v
ZGlmeSBhbnN3ZXJzLiAoTW9yZSBvbiB0aGlzIGluIGxhdGVyIDxicj5jb21tZW50IG9uIHNlY3Rp
b24gNi4pPGJyPjxicj5TZWN0aW9uIDQuMS40Ojxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7VGhlIG9ubHkgZGlmZmVyZW5jZSBiZXR3ZWVuIGEgcHJvdmlzaW9uYWwgYW5kIGZpbmFsIGFu
c3dlciBpcyB0aGF0PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3RoZSBmaW5hbCBhbnN3ZXIg
cmVzdWx0cyBpbiB0aGUgZnJlZWluZyBvZiBhbnkgdW51c2VkIHJlc291cmNlcyB0aGF0PGJyPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwO3dlcmUgYWxsb2NhdGVkIGFzIGEgcmVzdWx0IG9mIHRoZSBv
ZmZlci4mbmJzcDsmbmJzcDtBcyBzdWNoLCB0aGUgYXBwbGljYXRpb248YnI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Y2FuIHVzZSBzb21lIGRpc2NyZXRpb24gb24gd2hldGhlciBhbiBhbnN3ZXIg
c2hvdWxkIGJlIGFwcGxpZWQgYXM8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cHJvdmlzaW9u
YWwgb3IgZmluYWwsIGFuZCBjYW4gY2hhbmdlIHRoZSB0eXBlIG9mIHRoZSBzZXNzaW9uPGJyPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwO2Rlc2NyaXB0aW9uIGFzIG5lZWRlZC4mbmJzcDsmbmJzcDtG
b3IgZXhhbXBsZSwgaW4gYSBzZXJpYWwgZm9ya2luZyBzY2VuYXJpbywgYW48YnI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7YXBwbGljYXRpb24gbWF5IHJlY2VpdmUgbXVsdGlwbGUgImZpbmFsIiBh
bnN3ZXJzLCBvbmUgZnJvbSBlYWNoPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3JlbW90ZSBl
bmRwb2ludC4mbmJzcDsmbmJzcDtUaGUgYXBwbGljYXRpb24gY291bGQgY2hvb3NlIHRvIGFjY2Vw
dCB0aGUgaW5pdGlhbDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthbnN3ZXJzIGFzIHByb3Zp
c2lvbmFsIGFuc3dlcnMsIGFuZCBvbmx5IGFwcGx5IGFuIGFuc3dlciBhcyBmaW5hbDxicj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDt3aGVuIGl0IHJlY2VpdmVzIG9uZSB0aGF0IG1lZXRzIGl0cyBj
cml0ZXJpYSAoZS5nLiBhIGxpdmUgdXNlcjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtpbnN0
ZWFkIG9mIHZvaWNlbWFpbCkuPGJyPjxicj5Jc3N1ZTogaW4gdGhpcyBmb3JraW5nIGNhc2UsIHVu
dGlsIHRoZSBmaW5hbCBzZWxlY3Rpb24gaXMgbWFkZSBpdCBpcyA8YnI+dW5jbGVhciB3aGljaCBv
bmUgd2lsbCBuZWVkIElDRSBjb21wbGV0ZWQuIE9ubHkgd2hlbiBhIHNldGxvY2FsIGlzIGRvbmUg
PGJyPm9uIG9uZSBvZiB0aGUgYW5zd2VycyB3aWxsIElDRSBiZWdpbiB0byBiZSBwZXJmb3JtZWQu
IFRoZW4sIGlmIGFub3RoZXIgPGJyPmFuc3dlciBpcyBwcm92aXNpb25hbGx5IHNldCwgd29uJ3Qg
dGhhdCBzdG9wIElDRSBmb3IgdGhlIHByaW9yIG9uZT8gQW5kIDxicj53b24ndCBpdCByZXF1aXJl
IG5ldyBjYW5kaWRhdGVzPyBXaGF0IGlmIG9uZSBvZiB0aGUgZWFybGllciBvbmVzIGlzIDxicj5l
dmVudHVhbGx5IGNob3NlbiBhcyBmaW5hbD88YnI+PGJyPkFuZCB3aGF0IGlmIElDRSBjb21wbGV0
ZXMgZm9yIG9uZSBvZiB0aGUgY2FuZGlkYXRlcz8gQ2FuJ3QgbWVkaWEgc3RhcnQgPGJyPnRvIGZs
b3c/IFRoZW4gd2hhdCBpZiBhIGRpZmZlcmVudCBjYW5kaWRhdGUgaXMgc2V0IGFzIHRoZSBmaW5h
bCBhbnN3ZXI/PGJyPjxicj5TZWN0aW9uIDQuMS40LjE6PGJyPjxicj5JIHF1ZXN0aW9uIHRoZSBm
b2xsb3dpbmc6PGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsuLi4mbmJzcDsmbmJzcDtX
aGlsZSBpdCBpcyBnb29kIHByYWN0aWNlIHRvIHNlbmQgYW4gaW1tZWRpYXRlPGJyPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwO3Jlc3BvbnNlIHRvIGFuICJvZmZlciIsIGluIG9yZGVyIHRvIHdhcm0g
dXAgdGhlIHNlc3Npb24gdHJhbnNwb3J0IGFuZDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtw
cmV2ZW50IG1lZGlhIGNsaXBwaW5nLCB0aGUgcHJlZmVycmVkIGhhbmRsaW5nIGZvciBhIHdlYiBh
cHBsaWNhdGlvbjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt3b3VsZCBiZSB0byBjcmVhdGUg
YW5kIHNlbmQgYW4gImluYWN0aXZlIiBmaW5hbCBhbnN3ZXIgaW1tZWRpYXRlbHk8YnI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7YWZ0ZXIgcmVjZWl2aW5nIHRoZSBvZmZlci4mbmJzcDsmbmJzcDtM
YXRlciwgd2hlbiB0aGUgY2FsbGVkIHVzZXIgYWN0dWFsbHk8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7YWNjZXB0cyB0aGUgY2FsbCwgdGhlIGFwcGxpY2F0aW9uIGNhbiBjcmVhdGUgYSBuZXcg
InNlbmRyZWN2IiBvZmZlcjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0byB1cGRhdGUgdGhl
IHByZXZpb3VzIG9mZmVyL2Fuc3dlciBwYWlyIGFuZCBzdGFydCB0aGUgbWVkaWEgZmxvdy48YnI+
PGJyPlRoaXMgaXMgdmVyeSB1bmZyaWVuZGx5IHdoZW4gcmVjZWl2aW5nIGNhbGxzIHRoYXQgbWln
aHQgYmUgZm9ya2VkLiBCeSA8YnI+aW1tZWRpYXRlbHkgImFuc3dlcmluZyIgYSBjYWxsIGJlZm9y
ZSBrbm93aW5nIGlmIHRoZSB1c2VyIHdpbGwgYWNjZXB0IDxicj5pdCwgeW91IHByZWVtcHQgdGhl
IHBvc3NpYmlsaXR5IHRoYXQgaXQgd2lsbCBiZSBhbnN3ZXJlZCBvbiBzb21lIG90aGVyIGZvcmsu
PGJyPjxicj5Gb3IgaW5zdGFuY2UsIGlmIGEgY2FsbCBjb3VsZCBjb21lIHRvIHlvdXIgYnJvd3Nl
ciwgb3IgYmUgc2VudCB0byBhbiA8YnI+YW5zd2VyaW5nIHNlcnZpY2UsIGFuZCB5b3VyIGJyb3N3
ZXIgaXMgb24gYnV0IHlvdSBhcmVuJ3QgcHJlc2VudCB0byA8YnI+YWNjZXB0IHRoZSBjYWxsLCB0
aGVuIHRoZSBjYWxsIHdpbGwgYmUgYWNjZXB0ZWQgYW5kIHRoZW4gZHJvcHBlZCByYXRoZXIgPGJy
PnRoYW4gc2VudCB0byB0aGUgYW5zd2VyaW5nIG1hY2hpbmUuPGJyPjxicj5TbyB0aGlzIHRlY2hu
aXF1ZSBzaG91bGQgbm90IGJlIHVzZWQgaWYgdGhlcmUgaXMgYW55IHBvc3NpYmlsaXR5IHRoYXQg
PGJyPnRoZSByZXF1ZXN0IGNvdWxkIGJlIGNvbWluZyBmcm9tIGEgc291cmNlIHRoYXQgbWlnaHQg
dHJ5IG90aGVyIDxicj5wb3NzaWJpbGl0aWVzLjxicj48YnI+U2VjdGlvbiA1LjIuMTo8YnI+PGJy
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1doZW4gY3JlYXRlT2ZmZXIgaXMgY2FsbGVkIGZvciB0
aGUgZmlyc3QgdGltZSwgdGhlIHJlc3VsdCBpcyBrbm93biBhczxicj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDt0aGUgaW5pdGlhbCBvZmZlci48YnI+PGJyPkJ5IHRoaXMgZGVmaW5pdGlvbiwgaWYg
YSBwZWVyIGNvbm5lY3Rpb24gaW5pdGlhbGx5ICpyZWNlaXZlZCogYW4gb2ZmZXIgPGJyPmFuZCBz
ZW50IGFuIGFuc3dlciwgYW5kIHRoZW4gaXQgbGF0ZXIgc2VuZHMgYW4gb2ZmZXIgdGhlbiB0aGF0
IG9mZmVyIDxicj53b3VsZCBiZSBjb25zaWRlcmVkIGFuIGluaXRpYWwgb2ZmZXIuPGJyPjxicj5J
IHRoaW5rIHBlcmhhcHMgd2hhdCBpcyBpbnRlbmRlZCBpczo8YnI+PGJyPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwO1doZW4gY3JlYXRlT2ZmZXIgaXMgY2FsbGVkIGJlZm9yZSBzZXRMb2NhbCBoYXMg
YmVlbiBjYWxsZWQgd2l0aDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthbiBvZmZlciwmbmJz
cDsmbmJzcDt0aGUgcmVzdWx0IGlzIGtub3duIGFzIHRoZSBpbml0aWFsIG9mZmVyLjxicj48YnI+
VGhlIGZvbGxvd2luZyBkb2Vzbid0IHN1cHBvcnQgdGhlICJiYWxhbmNlZCIgQlVORExFIHBvbGlj
eTo8YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO09uY2UgYWxsIG09IHNlY3Rpb25zIGhh
dmUgYmVlbiBnZW5lcmF0ZWQsIGEgc2Vzc2lvbi1sZXZlbCAiYT1ncm91cCI8YnI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7YXR0cmlidXRlIE1VU1QgYmUgYWRkZWQgYXMgc3BlY2lmaWVkIGluIFtS
RkM1ODg4XS4mbmJzcDsmbmJzcDtUaGlzIGF0dHJpYnV0ZTxicj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDtNVVNUIGhhdmUgc2VtYW50aWNzICJCVU5ETEUiLCBhbmQgTVVTVCBpbmNsdWRlIHRoZSBt
aWQgaWRlbnRpZmllcnMgb2Y8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZWFjaCBtPSBzZWN0
aW9uLiZuYnNwOyZuYnNwO1RoZSBlZmZlY3Qgb2YgdGhpcyBpcyB0aGF0IHRoZSBicm93c2VyIG9m
ZmVycyBhbGw8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bT0gc2VjdGlvbnMgYXMgb25lIEJV
TkRMRSBncm91cC4mbmJzcDsmbmJzcDtIb3dldmVyLCB3aGV0aGVyIHRoZSBtPSBzZWN0aW9uczxi
cj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthcmUgYnVuZGxlLW9ubHkgb3Igbm90IGRlcGVuZHMg
b24gdGhlIEJVTkRMRSBwb2xpY3kuPGJyPjxicj5TZWN0aW9uIDUuMi4yIHNheXM6PGJyPjxicj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtvJm5ic3A7Jm5ic3A7SWYgYW55IE1lZGlhU3RyZWFtVHJh
Y2tzIGhhdmUgYmVlbiBhZGRlZCwgYW5kIHRoZXJlIGV4aXN0IHJlY3Zvbmx5PGJyPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtPSBzZWN0aW9ucyBvZiB0aGUgYXBwcm9wcmlh
dGUgbWVkaWEgdHlwZSB3aXRoIG5vIGFzc29jaWF0ZWQ8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IE1lZGlhU3RyZWFtVHJhY2tzLCBvciByZWplY3RlZCBtPSBzZWN0aW9u
cyBvZiBhbnkgbWVkaWEgdHlwZSw8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IHRob3NlIG09IHNlY3Rpb25zIE1VU1QgYmUgcmVjeWNsZWQsIGFuZCBhIGxvY2FsIE1lZGlh
U3RyZWFtVHJhY2s8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFzc29j
aWF0ZWQgd2l0aCB0aGVzZSByZWN5Y2xlZCBtPSBzZWN0aW9ucyB1bnRpbCBhbGwgc3VjaCBleGlz
dGluZzxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbT0gc2VjdGlvbnMg
aGF2ZSBiZWVuIHVzZWQuJm5ic3A7Jm5ic3A7VGhpcyBpbmNsdWRlcyBhbnkgcmVjdm9ubHkgb3I8
YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlamVjdGVkIG09IHNlY3Rp
b25zIGNyZWF0ZWQgYnkgdGhlIHByZWNlZGluZyBwYXJhZ3JhcGguPGJyPjxicj5UaGlzIGZhaWxz
IHRvIHNheSBhbnl0aGluZyBhYm91dCBjb2RlYyBjb21wYXRpYmlsaXR5LiBTRFAgTy9BIHJlcXVp
cmVzIDxicj50aGUgYW5zd2VyIHRvIGJlIGEgc3Vic2V0IG9mIHRoZSBvZmZlciBpbiB0ZXJtcyBv
ZiBQVC9jb2RlYyA8YnI+Y29uZmlndXJhdGlvbi4gWW91IHNob3VsZCBub3QgdXNlIHRoZSBzYW1l
IG0tbGluZSB1bmxlc3MgdGhlcmUgaXMgYSA8YnI+ZGVzaXJlIHRvIHVzZSB0aGUgc2FtZSBzZXR0
aW5ncyBmb3IgdGhlIG5ldyB0cmFjayBhcyBhcmUgY3VycmVudGx5IGluIDxicj51c2UgaW4gdGhl
IG90aGVyIGRpcmVjdGlvbi48YnI+PGJyPlNlY3Rpb24gNS4zLjE6PGJyPjxicj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDtXaGVuIGNyZWF0ZUFuc3dlciBpcyBjYWxsZWQgZm9yIHRoZSBmaXJzdCB0
aW1lIGFmdGVyIGEgcmVtb3RlPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2Rlc2NyaXB0aW9u
IGhhcyBiZWVuIHByb3ZpZGVkLCB0aGUgcmVzdWx0IGlzIGtub3duIGFzIHRoZSBpbml0aWFsPGJy
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2Fuc3dlci48YnI+PGJyPkJ5IHRoaXMgZGVmaW5pdGlv
biwgaWYgYSBwZWVyIGNvbm5lY3Rpb24gaW5pdGlhbGx5IHNlbnQgYW4gb2ZmZXIgYW5kIDxicj5y
ZWNlaXZlZCBhbiBhbnN3ZXIsIGFuZCB0aGVuIGl0IGxhdGVyIHJlY2VpdmVzIGFuIG9mZmVyIHRo
ZW4gdGhlIGFuc3dlciA8YnI+dG8gdGhhdCBmaXJzdCAqcmVjZWl2ZWQqIG9mZmVyIHdvdWxkIGJl
IGNvbnNpZGVyZWQgYW4gSW5pdGlhbCBBbnN3ZXIuPGJyPjxicj5JIHRoaW5rIHBlcmhhcHMgd2hh
dCBpcyBpbnRlbmRlZCBpczo8YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1doZW4gY3Jl
YXRlQW5zd2VyIGlzIGNhbGxlZCBiZWZvcmUgc2V0TG9jYWwgaGFzIGJlZW4gY2FsbGVkIHdpdGg8
YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YW4gb2ZmZXIsJm5ic3A7Jm5ic3A7dGhlIHJlc3Vs
dCBpcyBrbm93biBhcyB0aGUgaW5pdGlhbCBhbnN3ZXIuPGJyPjxicj5XaGVuIHNwZWNpZnlpbmcg
dGhlIG1hcHBpbmcgb2YgbG9jYWwgdHJhY2tzIHRvIG0tbGluZXMgaW4gYSByZWNlaXZlZCA8YnI+
b2ZmZXIsIHRoZXJlIGlzIGFnYWluIG5vIGRpc2N1c3Npb24gb2YgY29kZWMgY29tcGF0aWJpbGl0
eS4gSXQgaXMgcXVpdGUgPGJyPnBvc3NpYmxlIHRoYXQgdGhlIG0tbGluZSBjaG9zZW4gYnkgdGhl
IGFsZ29yaXRobSBpbiB0aGlzIHNlY3Rpb24gd29uJ3QgPGJyPmhhdmUgY29tcGF0aWJsZSBjb2Rl
YyBhdHRyaWJ1dGVzLCBidXQgc29tZSBvdGhlciBtLWxpbmUgd2lsbC48YnI+PGJyPlNlY3Rpb25z
IDUuMy4yLCA1LjMuMywgYW5kIDUuNC01Ljc6PGJyPjxicj5BcmUgdGhlc2UgZW1wdHkgYmVjYXVz
ZSB0aGUgY29udGVudCBpcyB5ZXQgdG8gYmUgd3JpdHRlbj88YnI+PGJyPlNlY3Rpb24gNjo8YnI+
PGJyPk90aGVyIGxpa2VseSBjaGFuZ2VzIGFyZSBhZGRpdGlvbiBvZiBleHRyYSBhdHRyaWJ1dGVz
IGFuZCBtYXliZSBvdGhlciA8YnI+cGFyYW1ldGVycy4gRm9yIGluc3RhbmNlLCBDTFVFIHdpbGwg
d2FudCB0byBhZGQgYW5vdGhlciBncm91cGluZyBjb25zdHJ1Y3QuPGJyPjxicj5UaGFua3MsPGJy
PlBhdWw8YnI+PGJyPjxicj48L3BreXppdmF0QGFsdW0ubWl0LmVkdT48L3A+CjxwPiZuYnNwOzwv
cD48IS0tU1A6a2lyYW4uZ3VkdXJ1LS0+PCEtLWtpcmFuLmd1ZHVydTpFUC0tPgo8cD4mbmJzcDs8
L3A+Cjx0YWJsZSBpZD0iY29uZmlkZW50aWFsc2lnbmltZyI+Cjx0Ym9keT4KPHRyPgo8dGQgTkFN
T19MT0NLPSIiPgo8cD48aW1nIGJvcmRlcj0iMCIgc3JjPSJjaWQ6QkVJMFhUNE5aNUpFQG5hbW8u
Y28ua3IiPjwvcD48L3RkPjwvdHI+PC90Ym9keT48L3RhYmxlPjwvYm9keT48L2h0bWw+PGltZyBz
cmM9J2h0dHA6Ly9leHQuc2Ftc3VuZy5uZXQvbWFpbGNoZWNrL1NlZW5UaW1lQ2hlY2tlcj9kbz05
ZTdiYTA3YWEwYmRhOWI0ODliYzU5NjBmNTM2Y2RhZjgyZDEzOWQwZjVkMmRjOWU1MmNjYWFhNWU3
OGQ3OTE3YTU4NmE4Yzk5ZGZiZmJhYjBlZGJlNjgzYzg1M2ZlNzFkYjlmZGRkZGEzM2U4MmNiZTRh
MzkxNDI0ZTYyZmNmNmNmODc4ZjlhMjZjZTE1YTAnIGJvcmRlcj0wIHdpZHRoPTAgaGVpZ2h0PTAg
c3R5bGU9J2Rpc3BsYXk6bm9uZSc+


--=_NamoWEC-u3a74ohxi5
Content-Type: image/gif;
	name="201407190811048_QKNMBDIF.gif"
Content-Transfer-Encoding: base64
Content-ID: 

R0lGODlhCAKQAMQAAAAAAP///8k6OspMTNRiYtt0dOSOjumiovLExPfZ2fvt7f/+/uvr69TU1Lm5
uYyMjG9vb0dHRzMzMyoqKgICAv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEA
ABUALAAAAAAIApAAAAX/ICOOZGmeaKqubOu+cCzPdG3feK7vfO//uYBwSCwaj8ikcslsOp/QqHRK
rVqv2Kx2y+16v1YReEwum8/otHrNbhcX8Lh8Tq/b73al2M3v+/+AgYKDVniGh4h1egyEjY6PkJGS
k0OJlpd5SXsBDQ6engwNjFKilHoNSaVYqkisTK5CoUqdo02waLJMubGogg6Nt1S/a3IIeAoJmHAJ
CnTIipq1EBETFBERDRHDUdqmSQ8PSd1GENzbR+NN6UPgqRPYr+Hrae1MDhFE94MUfA3hRvOKlHPC
z8xAIXIG4EFQAJGBOQWMzWEIDckmIfqEBFR3zhuWgk82DhGJrmOAekcy/zJpR5IMSiUqA8T8A5LN
yyc1l+QEU9MSxUMKD/2cs6iIyggQKExAxSCCtVoBmlKgIC/pBEZSIzBw8I/ryWr/hDSYRjUpvq9U
ozpdGiBp2rZTyzUAO9BqLyHt3IZt22Cs03Jm0YbzS2HgA2sTfj0AixfxNqlsszLqtjgtuAfDMA+p
BlgpqgdJh82d8ACpZ7VPiUA4HNlp2tVKHVT7NbewWKUR9kpNy4Azvt6F8SGdIBg1W71C7CY/rTru
ycr/kiYlAm620+hxm4o9K5ax5Las+04gvTschL5kD8LFBmFCZ9twp8NlO6S21uJfE7dNygD6+kpx
NGTAAQMQkIwCBAxggP+AySTw0AEJPmTAAAU4SIABBiQDIYUKDCVHUflwd81JgJWomlz8UMMABCay
OFdyDzBAgXh3OTBjA1T1JsqNS5VG4lxbEVeaCEut1hQ+i/VHHDsPACkbEdrYuGNfFDggI41SXnml
jVbyiGWV7CDZYjnaXDmXP+CcNWOY/ly12En3xeLiiKDtZ+dISOLDIicpCucmPuTlFkBiMu61J47g
HZnoiFWK4KWPoDkppJuTKkmdVjomieiQ8uHl5o38DKkjW3Vu5gCOK5pIp1YuHpqiJzNeWV+VNjIi
ao+shkoplPLE6OWVbyLlKI04bpPQAgU0dICAByiQLLLGUDSAMQMkkMD/tAgMoICzCChQLbIHeBgH
iEMc9Ys+a8pIhBg2BiCoumsiqh8F/dUVVkYFaVPqaj6KIBsjvQCcGL0yCTcMfc8ByQmUnpzVTaj2
ZqTvQIntCw7F2/TLSLyvWgyOjEGG6O7BaBbB0rn4pFtTN/qw++pzBb8Y85KrrctIuwT7mHPKeNmr
8b8Lj7OU0HdFxUnF/7yMKJMFC1GQwA7sqV93GMmKKMtIhuPyyBKfw49KUHdzNckjDUYijKXKo5i9
AfQUh0IRLSBtM8tCK3dD3yazgEI/xd3ggOLCQS5GIqLc9lRTEWHfy2037jR4Lx6G+L1qasQV4jlS
E2N8TK01MOHuYp6x/3mFFR2lw7+EijlmqNej7+quP6b5xkN0DHuvNZdrsOU3ndw05isbvvjIMN9j
I+LanPXS8AWhC3pBkk8V4+ych474PaIPARnSj49TUzv4GpcYkDXFBNLL+rQz/OmWE/H1Wdsb3332
3QkaPVUvUba64wi9bbe0cKBI3CgCobjt7W5wiNuECECAcDWEDoNrWvucJxYiTO1l8MLK19xTjnoU
LXwj82BUQtGeqPiDXnsaGcH0MY6iqa8/BLNc1xonwq7FToSx0x4JiUMwdenrH58JB2jWpDviDYor
e4EZ1vhnOsNdkHjgS14stqK8vTyxeTz7HV6AOMKxECcUh2mKaIxYtP8U/rB7w/heOMJnxl9wUGQy
AVlU0Je1QSWNa6hznwTb6D0yKq5g/KpgPdQGs4XxLwDHGiDeAtgQRS6AGcs6wAH7hoBl0c2BFTnC
RSRIPBaucUlOs1WKOigcIZ5lPKgAmqBA57goXcVdoNEaVU4pv2KxSFH9QthlaDmShrVvg5NhneVe
VCxVYoY4xRpCzXxoSq69MjftkBEoQeejTSXRd56UyTSXmLOXRbFtnynHmkjjPlHCsi2lRKfjjLnM
WQqhYr/BVVQQJrYq1QNiJ1GjBJUGptAUgV4gs9/u0heObuKxfbWTYD250sFQxfMuhLqHwnLzoiex
7JkFxQgi/efIAkj/ckHgWsCyEkCAZgxokg+MyAEegiBMQjAaRilc03DklHO0xz30okY1UEFTIjpF
meOZJgi7cVNkIiZGQcWHjaiRG+BMY57UUM/HksqwGY5nRUFV6C+KutWstiWo26ApOXuKCqJm1XVJ
bNl4wNS7WQrPGmDqZdNuyh/KrBFJ71jTYsZjqPHwR6z4GM07+FdUPs2Oqr2JKlTdkw/EQPOOvckr
de76uKW+Y4072SuKnFJWwx0GNH7NqS+N+M7EnMWyTR3PTxPLWHYc9avjSc5sjFjYQV2FH4mMVkNI
ysCGZCtZAiJAAQy0AAZS0lvDxVDgFhDBJpzKCH0xSi22ApUidAIK/9eNxXMxcpfsnsRW3NluSoqm
BytxwiT5gIp342iErdyFutA1CcLGOwvylsu+0MVvfGsR3fyuq2i7sO5jxCtemXzQvutNCXbPUSrr
vte8reCpfjUJYbF05ML2ha+F84Ff71I3HIh4RhysVQyJLKBDzZgDig3RXI9MYTGHQa+Ln+CXGdsY
DIuR8Y2x0B+PiEAZQA6ykO/AJB0bYchITrIcFNAsJTs5yDvOgieiTGUt/BgTzLhElp9siS0X48R6
C7KXtZxiMSNgzGM2hIjn4OU1TyTMSXYzi1NRXezWeRBGhgkYaHNn66q3zyaUQp4DrQmeArrQTbgy
HB5yCAMmwtFcbv+0if13AEkKudJAxnSQfwtpSN/hIct19HIN0EAlg/qBiDiCP0grhZtoQTNLWJFO
qLATLYQqiSVhWBJm0oRaxxQmu3tCOXitSQYcS9KX8HSkM23pIGsaE89WRrQDNOk7BMUOyqZDtoF8
bUscwXeEaAkrk+BrJpT7CucuwjpIQmwstHvcUHhfoo29aAqJtECWJhBxC7DAZAyoQAcqAIfs1u9H
ChxDzoJDwkccoQSSesQLGoAkLYShBBQgxRlS1sQbfm9+N4jj1xJusx+ZoH0T6OKPLJBHi8FASTpr
4P82EG9XqiEKEcAYG5p4xCVEIQedWOASt9syJKTvBBT95SjHULX/Ir5Se9+bQxOqEEsFnvSij0sy
siGNaVqTGhY9JRtb7Q/pyDkfF1ZmbVWqTUOXovbupOUvZV9OpwqZNb7KvSDKGWJYq8GW3FhDI4ep
HPjsXh53WWUyilHKXlrmGsw00ysjeY7d10NFvnCiHE7VE3rgHrqnKtMasuE8a3RD75SfWebaIqnR
CYAsZT3kWXXD0AJkr9KLQ2j2BnBWQ4i7Ujk0sKV761YcstUsbWVrWxE5KUkPiOnfe9RbHZpWcZu1
8ptfa+SlrlvQq3/moMfh5seXPe2VdfGKR0T12Tp9t4xfLW9ZC1sCesjyRd1I8jurWeJ/fe6z9f5m
ydzk14IAFJF//60nUqhmJ7c0J2KCgGQCAWJkI76SMFfxJEPyJK7VCUJyH+QRKEg1PeEwPvSyGP6g
FRSYK5P1OEnSLpziUCHzJhbUTIXRFAXlgIJya0dUK4dCHCqyJ9pwJqhSRK7CQvyQOyg4gSyIFCxk
ODxoMFkyIyuoOLQSK/TigzE0QsfSe7NXaYwmSR2lW3vTIHDDEJZmINqCQLJ3cwzHSAfEcovmUrUn
Ug+hEJWGAKx3N1gIfnXIEMuXhUt2YtoHB5W2hye1DHnofin3PxoHLXdYSYwGOClFLQi0LXIThsPX
SF4YN3lDiT8RFH7zc5LEN3gDhog4LhyjRIajMlCUJlIEDkBTVv//oEsUUzIWmISziA2vZCXZNChg
xycnSEN3VE/npIs3gRU6k0opY4y+KDNWsjWr1DFsAzpbww/WsIsJdU/EsxVJ+DvgdVAj0w3qokc2
9IxWSGkDUI4SF21diEDXFoYGFBFBQRGq120/AUDF8EBz+IjFZTdyGC7mSCGaFhHZYo4RYY8jp2/P
EhT3CIjN5iHrOIqYplKWplL96IaQCI8JInBCh0Dp2JCOtIYKVCClBopreEAdyVznY4q/gzmdhBQw
JkSkcx7WMxWjwzuU1TRRgjlSVESuIZN9xDS+iEbzcz1t9Q5ZREHOw4rccTRwZUS2MzlFNDyJ4R7t
okfWmA7ZaJT/TIg6PZlQNrQ/U3SFlqYh+TaKjlSG3gItBnRzZfgTF8JoAZSHi1SPCklJ01eG+/gT
27KIeNkhBMlwyUCPCSlSC/lA69cMZ+lID1lJEamYy4BA+ohAaEiSJiZAl0gthqmJD8SJlYRymCaS
ZomZpKhBKElBQUMboAd6MANGQzNGPnlGtciN/nJalddCTNmLNtg4fUSby8MWWLlOPIOUVfNE3tgx
XFRETzQNuUEN/1RISuNL3AQ67NONv/CNXNk6xfmV/kNSzeBRy0eHZHmJklQ3b3gtuKd79VZt37Jy
3TaJyWAgdAkhjLaPXwiH1xJ91KIhcdgMpfaWCRSXnamfI6ct/+63cuLphYm5fAGoneBCl55JN5So
hulIoJbomJrZe8AnkhI6ioIjUKOZThZ1MDqYM2nyTlzxG1X4JtbkNK5IPHolTsOSPiZaL/lEHcN2
m/h0GHAyR2KXD0vCKOZRUD/6kwA1IwaFFDnagxhVRAYFYzaiHj9JQx0EAdnkI4LyVNGpLyYIjqgz
UWGhaMVVUqTGQIuWIMaQjvBIIenZLQxUagiiIIS5npPIQM2wnnTIQKeWQMZwfXAgnyf3LfqGhn1a
cy3ne3bKeggZniBZkHaacgKXDIjJhd0SpmgoqY4ZN8YVXBdSLfT3nYyaphSKp8jVll96po2qocxF
VvlUGm9VU/9G9FMlBDOIpVNSFVQu6SlX9VWXw1n5gSI06FeLVRM09VPWyFr80BS+ehNBVUKI8UrL
SjvtoFmwlRTZsFadBVtCpSehRSW+kkQ2ClUzog9LNSKClZXtIx05MR4zVFvYqXDClwCTJnyJsGJv
Boh0Y49uKQfuegd6WG2WsGJGBwfEdWLwCmZ1MLB1IGfLEGbyiggGm692sLAkFmQLewgLW7EG+1Ia
xgn4lbFOUGAF9hwfu2HlghUV1l/nxV35QGFLgGEwUQv0sg0vmwrdRV7olWCKM2FOwLGExgtLoBlL
oz0Vpjgd4aXLhgcQQiA4F5mXsFxAhiALUodFG7VSO7VAFgj/rlZly6lHWCsMs+SkUUC0VDsHcxhA
/IoI/+pkRtdkYbu2bNu2gTBlW4sE1xS3wnC1ULAJuxBgQgtdgIZEYJC3OGsEnxC0W6C3WsAKnTC4
h8azMPExXICNcFu4gdtegwYgIwZnbftIZXYMmMu5dUBiZbtpSztkz5Bmn7stnXuwqZsHm6ASxLZU
ACFj17AYXhsGHWQenNRr16CrWzBsSbkF6TAN1XANk/tuXwFai9uz2xCut6oJtUsOudsEItgKezEH
F5K5jwSpiDBtC4FqctCZTwandRAuIwlklEkH9wotTKtwDzJyLNa64fW7WwQFPjJPlduxSZluSAAS
DZYF+msF//NgvL9Gbr1AhFNglSKCa3A0awe8SkbwEvg6XNibmMu2XNy7ttu2tN47B+K7vo55CSNU
RNQEHaMxPdLDF150EAjzXP5BGEMUWGSBHWwBFhczjZjnFPfhd3HyONBZQtAha2qhlHKRHusxFkIM
eKlRH3y3efAReFMjwilceJmHGjvcNqNQCt8hFVGaGLJhG3vVCyrBEiWkHIyhHFpcxHLBGUhcxYOi
HW7XJJO3UQppABIRc+5qaZUUB/8omAnickD3UX8zc/wGcCSnIA7XQAdgccD1cwPXpiA1YirHhYV8
cS9HXCRlyODij3KKLFlIyC93jgxkcfVGXHZ8sBHCIJdcfv89R2oVV6dB53Ozd8mVtnGG7CAH9yHw
W0SagkLn4SpcA1AJVQQycipLISU4glSdkCMhuCsiCA7FpCcm8nZ7wb/itIxSeCZnw4FNSCW+xIFt
0ysWpBjacM1nwiUDXCupwotGMiJ7kkLJQVHKNCa9wRWvxIFzsTmcVIOKwcw9siu3BILd7IHfHIwY
UQ6vdESo4iKWW1xGx2iwVyGc2GyaJoclRZ6yR56KpADm53rTd3/Bx2TNIoAgRYADYp7ft36fGFIe
VTe953yf6H+vl9IPjXskR1LFJ1IldXszjb7UZ4krx53YIqAAKXHo94gQkrYd3UD8Z4iCk8sjjIJa
czOvMhP/mRUxleNMMEI0BNU46MJT0ji/tXMNO+U4FlMzFLUkxpNH7yMzOgPWFdQfOTkxJHrO8CPV
VpyjqEijp4GKK1QyyhhsMmENOsXDWh1sS9HXXG2LeJFFL1EzNaOMO2q5y4cgeAqZhanHliafBySJ
2eKQ2ssQ3mmAa6hpqjefZ1mGdUOIbUiSEyfaqAuXHolzMu2FnE2JD2ogJZkQ9YqWrY1SeBrajvjb
GreHK0WXTV0LrltHP7k+o1U70xXZwNlKo5UmorPV8naS0DPNnxDM9yNMRog8M/Q+GUFBLyE512BD
/xDAp3UWzPM8KtleewI8hwQ+OElasuEJd5Evw8A+O1kl/zkh3utN1lb0DowVExAcQBRSqog5IN47
0YK5p5MMmhQM2oTpn2OY2f24hkPxE+BLUivnLL8XkOUYl3EDvo6UyrYtdAPphXTwjpbo4ZldqQJI
kJREQC5F4ZV93Eqsy3fUDmQ31b+bDrFk1YQ93apaQdatjXMk4FqrtSJUKMSREbH5SwXzmtmtxMaI
3gglwhlxRc9TH+UCSqSJCs0ji3Vt3/Kr3ySajQtT5olt5W49F58gb3F04AuKACd14gpSkDHu4JEp
4Z8dEbB9qKIN4Y3p4pWokAf0l/yGuqS2l7H94KC5nymelqD9wcdGmYwehzL+E8GtvhoX2jiekSFc
O71gP/89XlDmFJ1hjhXjcxU6MlSwggryFOt1JG8ceuXBrLXG5C7NGE7h/TsrquvapBFx7QlGdWEB
ftc4WqUeOk1xVSeC8qGwdE/hhOZGAD2BJW/1K1rndN3D7tZE+DDDEk2o4D+q3ZECt7m919kOjtpw
E56JWJaOmtKCWZ8BIkneuXKPvKftmdI3x5cnddr4Gekm7oXw/ph1g9G0DWf8boloCEA13n7uyXre
MuOSXu90aQyl7ilMZSupHq2ixWvtcR2y5R6VJ91Zh/Ksxas+blqGtSbEfkg8bK2N0QuLwVlWBfN7
xaxubVvuAfPEw1V0ffJ/5Vgxfw42ElQAA1e0cVb/kPP/a9Iew8BrT7NWpumABJ7GsWVb6cP0TP5O
d1En0PpZ7QCI3qstHZnakJwsmq0QYToh0bfIBLIsBrqmc6qQBGKO3SdwebqmDb6mKX1yDXQtwxWe
wvUtminpoxj32vLoCoEgZOrZ+Ar4imhzknSpv72mjAb43TcgiC+nDMpcm+RetjC5FlY0NhtT6yVe
HlZhOksKOkYLFlGylRuy6YVdAEaz+PWxrl+zFYb7SPD7KCuyUWH7VGCyJosJg7hkoZuw+ApnEctm
z+8MZxYHCPtInSuvHRJm7rq5WgZn1z98q8tkKrb98DqxI/auZeawy/D8ktTxjSDAdFv/9n8EhkBq
4I+9//wPAos4kqV5oql4KKr7wqlyLAHDBLm+873/A4M5xkNoPCKTyiWz6XxCo9Kd65CIYbPaLbfr
/YJdNkZYlGiV0yTEtYSInU8JBLocV8feWb25ruKLAOJxCboUqtxxJZosdi3GCR6eFNo05DQ44EA5
TD01aB4xWOrcpB3QDJYZEKAuHLwNxBQUKgwUtH0l0MymjryexGYFr7Se/A6LIPcKwxxn8cYYlECT
/FJ7nVbTKMcqSKso1zhE2FBEjD5RdDo9FCGN75Quz2td84bvFZgWL1974ae4R2+gCH+pAE57Y3BL
NhP4EOgDZyIAPHhS1K3L6MPiEDK+BhC4oqCArRYGDv+AnIMKwaldKAu0eGkA14IEBAZ8K7DKFyp9
NkvWvPltxE9pKEOuSIkTaNESM0/d3IVzgYGUrqoiOAkSwc03I0G+IsBqJlWrUFk5ZSq04EtXKX8i
1XcWVVWkZatqW1DgZZ2jCZbC1Ot2ajWrXwNrJcB1wJvEixUS08tXcNnAcHWl1HfYpF8SM7/aTTq1
6q1VBsj69bs34kgSe20V3Fn3yoECYmlkW5pT72ird8NRJBeBAoQh5GyQazCBeI7j7XYQN4dDOYUJ
DR5wCoA9AITq6LR3d0C9OMUJE9x1t679QQRNED4Nb29jOYTjHYmGPECAqrTTevef9hdbubn0lwII
MEb/AisKoMVYX6jEspdkCywo4QgLVsiCCCOxMIBLFLJgYUEsEXDgfvrpApN+rgRWgD62zaCPfwIG
OIt+M5xYIoLVwKQTiAxuU+BeQLK4QCw37libiSx6gwyBE244pIcTxjLAGaHZpAuA/Unj4n8x6vVi
ibUZGdmUEh7ZozRoKSklf296SeYINso1lJFXJvAXAggqMBIb+ZU45CxIHWAnThwaSYeSKyJ54jYG
IHpkfjBxxSReJQSnnXo5qPdAcecxcF4AGD2nAwVFRFCEqOx5yul1EzDgwAQ7sIcDqKkGMIEDDlBA
RHuyrgdBEcpxVxwExhYXgX1j+PLNNlcIaGEsitUy/8M2xBQqgmL4BaKPMg1FSAO0+y0AEbflvgiI
QK5YQa65c7IEIbpQ5tfTG9mY22e5R+6SFSqKgeuaV392Wya7er0hEpn8JkNvArwIyJPBDY048bVW
1lSNs3fWFOG9NJjLC77emlkyLwcu0AKYAmEc7RvvjkimviO03PC7Nm7Myyz+bUvzFeYGYyHA8ub2
M8kh//twwsBVtOyxue46a6akupMD1TbYUKs6wArrqg7PARscsRQFgGuu12FHTqsUWMKAOr1qt6w8
B9NcNzRHniTXtew2RM27QJcQsE1oITiA4RHNO689sBBT+OECBxyyHjbae7C5P5F08CzQUN4wvCP8
Tf+y5vfe5CXDZZJkOGN35xUMxQhbXKZ+17w+jMeWp4t77K5fSztIXrJs98uIIzzSgtUQwPrN8QqM
cJbcFBz05MzLvjfgIau+uh5Mk8NRAMo1sPVx8Fxtag7PPVCdsme3OhwF72e3HkXvvx+B9+7D347b
ZXNC//uj5sB7c2vINlR2uzL95SQH4122KMSHSs3rW/IymgHeNbNyuSt3n+OdBf3QuTJJTlvUExnI
9NEzhm1OD0PzXMXmAEHAja4WRqtew6BxBdZJjHfN02EszlCbVhDQSAaE3ciIWMLdmSxhf5ohy4bI
C5gVTwEJ2AlRYnSt5QVRZ28ggH9IEAwYQmOFNPz/4tE0eMPtTaRpPJjA08JGvvNVDYDrAV+mjqUr
/l2CVkWwyA0skgn75fE5qYIbRr4nRwF6JCgYnBCZfCSnm5SMXQZCECAwhqbASWNH2wIabQx1w37t
0EydhJy8zEUmAfXtYxGMCQpZ4pPTOcko0rDk3rIxCwiajm5pStkAZmAUJ9WyGOsqWomo0gqbLFJC
jVRlCItISyRmq1C4zF24ivRE4u2MBrXAD2dAGJFZILNSWiyLIKakQNe9UpcL/FAsTKmZXkazG7jI
lPe4Q4HssK1sRcin2awGx7CtTzlSY085QFGqfK7tBmwjqNuIUIQHTOA4uAIWruoTj0RSpSsdI8kN
/8ViFznlJjJH6VkgQFJMZfzFRUeyxbZegjHQmbQF11jFjg7mUpp8sJ2a8ShuKlfEVXDRSiipDR14
qs4RMIij+xJLC3RIU9twcT+wTBlUpZFUSOYwMiOgKQ8zahuarCJBKbUkM3P3U7FccoEpSx7GPCob
xfTQFmRN3IhSipatJg8pYlleRhP01JeFg6Un3ZBRA5abvDa1Y5Cq6lpto9MR0HNZ8/uaeWDFHfP0
U47PqSwEpGYO45iHPHA8nzkQGlrknPY54XNH+IbDCYFG9KJuqMOB0HDLOigwBbrQFk1qIokNAaK2
SKUDI35brt4C1w95QC4iaJKnNTC3BMI1g3HZcP9cGFgXdISIbrkOQdzkeuG5LphuufyQ3ZR99wUH
Qu6ehqvcQNThvA30Isomwd3hFjcQNJGEEFqlA0zsoAHfAUImgiCeIMQKFALewYERXOAhDJhZsgDE
Kt5LgloYwDYE2TCHO+zhD4M4xK4gad1EPBEgQDR+GllxJ+b2Ag354r4bOoWFTWzjG+M4xzouQ3tN
wA8bG1jFLB4yFG7QA1HEI8JENoKQEaxkIHxiyQaWsg+Q/L0m88DKQ9ayk5fMCS4nAcwQ3ggUFkyK
J1P5yGhWsxKw/AQkRxkJYjaCkXVQHO/VM81AKGQQ7ixZIQBSzzzgM5X9PL8/2zlTRM7zRhC9DnX/
lGoJkdajDwg9BNFWuTiTnrSgG01nTcfRCJbehHCwjGkdMFoIdfZnqjsdhVG7egmwHjKfOT1oRQ+5
1Qx2dEZsfQRf+3rUuoaHr2P9BF3rWdfC5jUQVt0d+0WUOQ3QNH14ANE7jqc56UuVeXAwSG5b1jmo
2ra3kcMcTUnn2dM2t3yE5Z0dvGfawzk1RE/1vc4eqzuiqPa02diDb/vTnpvqjrSXI596x1He50a4
Pc/xHvOUygFVe7as5n2+5cSRAcNRj8alw530cZw+yal22TqLavPYWz5lA0XH2w1yWd3ze8tRj9oS
PnNLfHs66kv4zmV+boykxxIYF/h3MM6eoT+H/+AZtzi6h1WfUz373sPx1GfXzR0BP70466YOet73
qVOpluQ53wE53K2r5XDC7DD/cnxwECrilN0S6Uv3Zxk+DokHMNRVVvA9eWUJtpGvf+hw26ty9QCN
7/Pw/sbVqUKVrH2ONuWQP1aoMsHPB4RvV2VHVtnUtiz7+Z3wpGAb+HjlbQjYSvHY6RUoTIV6xmuK
CLOqVagagKtUEZ6OAWQb4d0mHutkfhwMOFb4tP3fvueT96TfVNzAU6znr4+gwtI4OW61zwfPD/PW
6drYcvC0p60vArAi6B0JCuk4lp8ckoea29BveVUdHvYQlb2mXkV/ykocVsBqh3JiJTXvo56u+P9e
6ZFe41mH361W7VkE6CkfJlSfePQK7VkHRKGN4SHeqIwbdHRe2YyfcAhHBz7f98VfqTWUPmVe7h3g
OWBEZv3AqgHQAmreqFjCd/iX9p2P+jUHJzzHCuog5MnP1bwNDhzYDMIe+cygOgDS/cQgHp0PeQgL
DMpcE6ZaPr1RoHGczI3DsDjfx6GaREmcE0IesamK5bWe+OSgf3XNDY6BDJYDHpEPDrDH2LwRg0nN
E87K05hK2yBhD2ZK25if/PxX1uDgHNVh1YyNsMghDlqhAzIh84mhP/GfZX0H3IgHGqZNwIHecfAg
DHLiOUhNgU2Hrojh2PwhIPoTIIFNqcmPEbb/IdwQFCBNh/yBITwIINyoWhkqWiZqSqCNVgCNzyCi
og8Go2b54A7KkZ1Vh6iYYSHtIa7xDxSSFv1cohv+4hT6IgDhzz11nHn8Hq7M3ftUDQyWijE+oqcQ
lAaKo/9UjcaByqj4DzUekv34zyB2YeTpntW84zASW/3g4KbxIzFaRKQF5OrRjyL6TwxmY/w8IgAl
HXFMIqWth0VsoibmYCdWpP3IzcaJYs350SBOWjOmIh6FpP+8zTUCUnooo3aoI7EJC7ORAi5a5Cew
yte4A3Z8IjDyIQ/+YOTxJEZU4sGFofq5XTMqITQCoiVAoRth5A/4pCJmhyXgof0gZQQIC2vt/9oZ
guEL1tz3EEeomSH/lMp33EC/HSPOccIc3t1xGBmhWUTX2NGt5ZE+euJUMqQhqscctsNA1mNEqiUO
NKMhwUOgfcdCnt/3EIEtHtJ1zCJFPiNj6mJjXqQfDR956GJe3iQxaqBciuQe0ePfmaTEAWVd5hE8
hE8a3iI6euE49B8XXsKsAMvlydEw6uQO4lwxQh4gpUqrhEpQ6lPzJeHnLSEvyoq3TWOgXZ5FxJnV
FEHXQJom2t5r3ZMAqma4haMX9l/taSUgLkfrZSf/rGY/dc3+TNSs/GZvWhRCFQdb8t5dnpsOjOdm
BgdA9WM4Ss36AKHQxVE+KaPcpWfzKaDnzf8HOhDmepzjHeWgCcLKf2LiEm7irPieRbIe2wBS8G0l
bJbPKfJhYGaocOwReS5nqelmSg6nPi0gJZ6mDnBjapZdRDHfZcXctVnWbAojH3ZWRNkmAMFWOYjf
06QoVw6HWTrjY/LiZZlHLmYHjMaKF0IHi/rlfOzoodkoRInfclbWVeJRjaJerujKVjbfGm3pgdbo
//moqLRWzJUnbKlNtHkmHYaWJuRTgJUWJ2gmZ81KYaJoaNXpaMFoHO3pLiafk/pbaYbKkx5fVUKi
4mFWgFUpkaKeRF7kgmqp+AVnDF7bnZmDjbqNoSIpZpqPZmpmmb5WZZWacuzop8BKmCraOc7/WkfE
A/b1wK5sBDoAmCes2SXET4KRAvbhahTMKpQ1WYNZTazE6n+pGCYomJvxQK/uKrzp3bKeWZPFymCi
GZcZaxCYWRQOqxAAK4Gt2bUG2HdUKw8A66xuq60aWIT16pVtAnf6wLWm67siqxRE65kdma4WWLp6
n961ILsaW792mlf6KxB0Fr8GLJOxYMEibMIqbJoNrJwR7MJCbK9FrHbU6sR+j75abMZq7MbSSsW+
JMeCbMiK7MiSbMmaLBO44Mmq7MqybMu67MvK68PC7MzSbM3a7M0qbMri7M7ybM/67M+irMwC7dAS
bdEarcrq7NEq7dIybdMWbNI6bdRK7dRS/+2bCW3VYm3Wam3U6qwE7IDXAgHYBoHXiq0EmO3X8oDZ
qq3YCkHZrq0OgO3anm0AsK0P1C3coi3czm0OxO3b8u3Xym3Y7q3bsu3dBu7fhm3b9oDh6q3a4i3d
+i3d8u3bxm3aPq7kjm3aRu7dQm7hNm7eJm7nDq4TRK7dYi7g+i3hgu7lli3qHu7klm4SOC7r7u3p
/gDnrqHlPu7rGu7ski3inq7n6m7jUu7wIi7n4u7k3i7otu7xsu7lQu/z2u7iZi7wzq71bu7iym3t
Tm/vXm/wAq/10m7g1m3zTm/wpq70gq/zii/1Gu/Ytm7ysu/yDq/50u/5Iu/2yu/+ou7qXv+U+4Zv
++Zt5VauAOPv/XYv7Bbw+w4w9ZrvAwtw4b5u/f6t/gaw5vqu+kIwA5evAgOw8IouBg9u7YJwBH/w
7hLvBmOuCvsv+m4v+/6u6a6w6GawCE+w/kpw7Oou4aavBa/vD2cZd8Zw5zKv+xKwCbsu966u5wrv
C58v5AIu2qpw8z6wElfvDFdw/wIwFv8wD3vvDdtuB0MvFVPwBZdwF39w+iLx+rJwCn8vF2PxEFsu
BOdwEYev/C7BAmfx58qwC1tx7rYv45qxB6tu9MquHQNxGDMBGSPxBuOwFV/vAtuv/0qyBhuy4hpw
345uAYtxIityEl/y9xYy9kayAk/yII//8e46Lu6Wbymjchc/Mg1PcANbMuwi8imzagDL8SfT8i5P
wRDrMRzzMhJ0cB2rsitHQSWbsSBPsfoegRj3rRHjbTDz7hxf8hZfcR+38TNvMQhzMv6+sDKDMzLf
cRPgcCOPLxrvXR638Dd7cSTHsjVf8O2esw3PcgszMPP6cBKf7Sg/sQw3synbsw4XLDALLh6Trgbv
Mz9zb+m6MzHz8TwbQT3L8h8bsiivsRfvqz2/LzPvMQJD9PyaMh6TNDdnMzbnczmH7kpntDOj9Ehz
dExrb+wyMumCcRl7Mj7rtC47L0JL9DwLMku/9E5rcy3/swsyc1AT70dT9D9T8jAbcEgT/7VTU3VT
Gy8uw+9M6zM5v3RQK7VSv3Ix260Tc7AbjzAyW/VQL/M093Fbwy9ZV/Q7W/QykzVGR/RRtx5Yp7QU
X3NfY3JYL7Ja/3RVK4E3F/ZgIzb/ovQpn/EB7/VP+/JFS/YV+/Qjk208y/Nj+7RjD3Zlx7NeTzXu
MkAL8PNf/3VTp7Vbw3Vqt/NCU/RrLzRlx7by6u1JCzYrzzJcw/RYEzQHnzVvi/Js169wa0T+1rVw
o/Y+s/Zb33NotyBpb210S/d0G+1o1wB1Y3d2azfMWvd2e/d3gzfHdnd4k3d5m3esjfd5q/d6s/cU
jLcTa/Lo3rJAQzZV+/Vmi/BEV+9X2/92URuBAAC4AOgAgA94gBd4EBB4AAS4gSu4gB9Bgjd4gUM4
hPsAhR84ECx4hu9Ahlu4Eiz4hROxX/P2Ejc3Udv1Y9+3UI9zidc356Y3LUtxQ7u05AY3W/fvKtM3
Z4v4Uusyjuu4P39xP+94gnN4DhC5gx+5kSP5kit5kz+4g0d4lCd5g394lEs4g/dAh284lDt5lnO4
loO4Nsd2QO+0RW+zjBtx9tKzbv/4VcdvlUE3DJ8wQ89tNct5JzP2ZG/14TbxVb8yF+c5TmM4k0v5
klf5lCM6of83lCd6lW95l2M5lXu5EHw5pQv4hFc6gfuwYhu1LIcuK7u0HiMvUKu4Xp//MSNH9osb
NA1HryNjMArTOE579UzntkqL9CeLtQdHNWdb9ZEfOqEnupMH+6L7OoNP+aNbuYd/OZczAYFbuKM7
umbLeh5L8JyjbxQ/cTBD9myjdhkf8ZHFefe+8bhL76gfr4/Xsp238xKncgLzeCCvsZ4jAbQzOpYX
e6MbO7P/wK9feZgLu6Ev+xIse6TzgLNz+bCHeGdr9TET90STsEnvsFuD9GGH8LkLObhftwVru7i7
MnzD+i5XMSQ/vJ+PMVf3OU+Lc5BHtsDrO7Ij/BMkOZh3OaS3vMwPvMwjeMAXupOHPCL395DFdzgD
9Ij/vGV/NBsfPSmEe5qrcSc89Hxn/zut0/QbqzaMn3ZfUzFmTwHCD7ylbznOV3i9X7mGN7vO57yX
Y3q873rbjrnWJ/PQD7XRT7wco/oTv/htL3Zpf7y7I70WT/xU8zSsu3GnC/q8F7m/DzvOg/2+iz2y
z7zitzyVR3vYLzo77/rGr72J67etC74tc/w64Hm5J30uK7zD13U3v/mNX7zHqzglC73eNzaQD7R8
e73jd73kH/vtJ7u/F7zOEzymV/qk277ZDzraH37C6/j95jCL2zcQ1zPrQ79gOzM0Y3us80DK5PXP
l/WfZ7b2c7zGu73mQzVhb37z737aOz7lz7zw9/7Zpz/7L/76oz+x+z6z43zQ3/Pvrv/6IWcuCEiB
KAajiZ7pWq5o2b7uHM9unZLuojC5BAy2hMIbEfgr2mRLpg3XjD6lqhcxCr1ZjzOB9ytIgcdNL2oM
Npm76HWg7Waf4ba2mE51wcPLbN8Jc+RXRQNoIjiY2CdoxPXXhMPjk0dZaXmJmam5ydnp+QkaKjpK
Wmp6KiWJusra6voKGys7S1tLqmqbq7vL2+v7CxwcgCtcbHyMnKy8fNvD/AwdLT1NDUssFZQzckW4
nX2YOeQ4pEU5uKXdXYW4sqeG9sZnmpYXd2f/jh9v1x6mL/evnrx3ZQYKzBSHXz55awLe+0JwIUQ2
bszAizenosF9F+vwucbuD5SRLMD/lTz0TV0NcY7QKVFXbh3KloXu9ItoMyM9jmQeWpyYZg/DhhDJ
7Izy0+jGORwxSjyqBw9TnDp7OqWicapWOVcPOrWHjyhVnku3LiGK55pJlkp0xEzXtlwMGHJT4ljp
JO8UkyrubuFmVuzNsQH1afyJMyvGpAMZF6QatOziogYRI62M2ezXjQ4HXwXrz45gShdBR306mHFk
rJkjqu1bci4jlYQCjYMbO503wHzvzja09vc5skA5U04tNWdT5YoRH3V8NnQ/ywCP2+xM3PTYzVEV
ek7Y0ePTiVw/h5862vzjy6ddOzs5FzjfbuTWysUtf7hu/TSQ6O0fEmsPBcYHduNp/6feZFYRt153
UPm04GSV/KNYTgY2aBpoFU7YmGTRVaiaTgS6o9UaPCiwwF9x9aZbbfDN15tdetFlzm/GiNahVRce
ViB59MAD3WZhCUUQdaetdqBkQg2FVo7nCdTkktwtx1prnCSFXEQXTtcjCgygWFMS2iDC30y8vbUX
mVmsRCYLjKhp5kvZkdeeFCQOSKWWxRUZWnN0kiZdYX1KV+eVe0bHpXcLbSced1LaOaiihuqJyY/y
fJkimpeMdCaMe0ES5iOe+IUNopBeImiTN4nF6qCJ/VmVn12tap1nBSnUaoOodgmejl3OasmWDvZE
omBD4srrpWBqGpJ+pLa4WzZ4Uf8x3LOQ2OhpgIUyumujjqkqYj6L9rpUhkNNGSuhtgLLFbm6cqsc
lQjulF6V65qqWYk+GpdluAFgGic3pDqrBZyfenqwigJTy/BJXsWb6JJPcrloow5SVK6VTNVLa5JG
4luex792S5iHHD8G3sPwOjTkvcoBTO1s2iqsCZs0/RfzzdGm9N/MEM/JypYsK1mWpNd5+HPI77p8
mdGFOo1echlNDfSwD+ar2Z3lwVxN115/DXbY0XAtdtlmn4122qSQrXbbbr8Nd9psx0133XbfLczc
eO/Nd99+r71stAjjDG3CMOU2U+GFv6mwf40j7NuKKs7Y6X4z7uf44SesCRPPirj/ia3DNeqs+Hyc
s1R6zz6nrjl8L30uKi1cDxwmYM6GHheNMiVOuIvZJuybpprzZq3D9eWl+/HbyGAbXc/WZzuoB7Ml
p/Cmx05C7tLzPnj38Qn+O4vGQz55964wMEn4JJFfquj2bS4+bPG/Ja31zb+ouB/KF5+E49+4Jb/d
yQ+A9nkeOuRTsOltr2Dr856Y4pO9hcVPf4f7nuXGFxy78AyBvTtf+sCnuwu67wm4K+AET1iI462O
gOIAh/8kSD/QbRCDLoJefkyIGwP+bobzQ94CrfAD0Z0OgQSMCfU+1UDahG9362tgEmeBvhh2Dmdl
cuBu1pG55KkOiE8UYRd9WJfM/1kieuLTYhnr17/OZTFOWwxii2A3xvwxgRxFQN0Ns8UmIRqxEf6D
0f9qFyoopo9xU4ScGH+InyIisYMAstG0mnczC6LEep3Aix3L6ELLVbGQcVReD3f2OgFS0Ydm9IYA
N5lJPy4OEM1inxpRGYooNoyGrAtY9WgEwFZ+EpSwpKQMK3et1dkSjnuEjQUVyUs/ilFNdOwZI6fg
yVI185Ss3CAzmXc5Z+5SeNFsXStkqT7QUa6XNXGe9FSYhy8ukHQj3FnsKkFMDJrzevwJYQedGM5G
hvJ9v/zjNNGJQsMxEVo6FCU/uWezXIAzme7E4ori2chUMtSUVCwhIlf5TCWiie1TLYGoG+FHn1cK
jAvxtKQv04Q4ac7RoW9c4ztDGghm7ZOhtwnYQWGxUP7V0p7tVKn5AvnTzVHwpZIkKvCAyroqIhOk
PX1pLefYpvYJFKlMpeo903lRQDbVmzz1YP+qt1VvDhOrY3VqgLLIUeKdaYXA9B0fXyec0G01rWBN
Klk54VFf5tV89cyqEeXKSHKCYqF/K6xhD4vYJRA2sYxtrGPrttjHSnaylPVaZCuL2cxqNm8f3Kxn
PwtaQYZ2tKQtbSnQh9rUqna1rG2ta18L29jKdra0ra1tb4vb3Op2t7ztrW9/C9zgCne4xP1tCAAA
Ow==

--=_NamoWEC-u3a74ohxi5--



From nobody Sat Jul 19 06:35:40 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D3E1B280E for ; Sat, 19 Jul 2014 06:35:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 CysFZ-mQi-Ud for ; Sat, 19 Jul 2014 06:35:35 -0700 (PDT)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 39E9D1B2812 for ; Sat, 19 Jul 2014 06:35:35 -0700 (PDT)
Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta10.westchester.pa.mail.comcast.net with comcast id UCkC1o00427AodY5ADbark; Sat, 19 Jul 2014 13:35:34 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id UDba1o00H3ZTu2S3fDbaXr; Sat, 19 Jul 2014 13:35:34 +0000
Message-ID: <53CA7426.6030602@alum.mit.edu>
Date: Sat, 19 Jul 2014 09:35:34 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: kiran.guduru@samsung.com,  "rtcweb-request@ietf.org" , "rtcweb@ietf.org" 
References: <58.C9.03708.ACAD9C35@epcpsbgx1.samsung.com>
In-Reply-To: <58.C9.03708.ACAD9C35@epcpsbgx1.samsung.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405776934; bh=N9AKKgbqjExBxxXQv6BkscFdUlN9JvTwPRQctguryiQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VGPNEbV+fV74IdFGBmrAyzlU/7/pq6Z7drkWO+q51eGDcY8RN9dLTqCj6Q+XOPpis c9jTqzWJpVbrcIGgEeSb7qrEs5AieC8GkbmrZY+nrkEaTWkmBdLG2gLnX7wy8V6pvJ FdpRoZ9jmrhGT+rSW1oVdRWmNy6sIIGmzu2p4Odv/+AjwPstMYnpvocOYlTKXQyGDI w16uBquN5K6qNIJVTUNweE/02R+78bIBK15O9m62Ga3oD9c/z/HYSZR+ACOOhJpD+s EmjYBprSCWjGKROcmrbSBYyllDTKTQgRyOTvUD6SAAzPInNg4W66jg6827vO/UeG/g KtWAi75jiCCLg==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MgWn05y53VTIZmP8juGrs5PtH2o
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 19 Jul 2014 13:35:37 -0000

Kiran,

My need won't be satisfied by plausible constraints.
For instance, to interwork with CLUE it will be necessary to add an 
"a=group:clue" and include in it those m-lines that are to be "clue 
controlled". And that is needed in both offer and answer processing.

	Thanks,
	Paul

On 7/18/14 10:41 PM, Kiran Kumar Guduru wrote:
> Dear Paul,
>
> My comment is only regarding the comments on section 6 of the JSEP draft.
>
> The sdp mangling described in section 6 may result in various error
> scenarios.
>
> In that section, it is described like most of the parameters can be
> modified thorugh constraints.
>
> The required modification, I found, which cannot not be done by the
> constraints is "Remove or reorder of codecs (m=)"
>
> In order to avoid the SDP mangling at Java Script application level, I
> submitted a draft for changing the codec preferences
> http://tools.ietf.org/html/draft-guduru-rtcweb-codec-preferences-01.
> (Please review it).
>
> If this proposal is acceptable to the group, I hope we can remove
> section 6 from JSEP draft.
>
> (Expecting that we can find alternatives for adding extra attributes
> like CLUE as identified by you, for example by extending the
> proposed RTCRTPSender/Receiver by adding a generic setSdPAttribute (key,
> value) method).
>
> Thanks,
>
> Kiran.
>
>
>
> -------Original Message--------
> Sent: Paul Kyzivat
> Date: Fri, 18 Jul 2014 14:32:24 -0400
> Subject: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
>
> I just did my first thorough read-through of JSEP in quite some time. I
> came away with a number of concerns:
>
> Section 1.1:
>
> When describing offers, modification by the application is mentioned:
>
>      JSEP's handling of session descriptions is simple and
>      straightforward.  Whenever an offer/answer exchange is needed, the
>      initiating side creates an offer by calling a createOffer() API.  The
>      application *optionally modifies that offer*, and then uses it to set
>      up its local config via the setLocalDescription() API.
>
> but when describing answers it is not:
>
>      When the call is accepted, the callee uses the createAnswer() API to
>      generate an appropriate answer, applies it using
>      setLocalDescription(), and sends the answer back to the initiator
>      over the signaling channel.  When the offerer gets that answer, it
>      installs it using setRemoteDescription(), and initial setup is
>      complete.
>
> And Section 6 only talks about changing offers, not answers. It is
> equally important to be able to modify answers. (More on this in later
> comment on section 6.)
>
> Section 4.1.4:
>
>      The only difference between a provisional and final answer is that
>      the final answer results in the freeing of any unused resources that
>      were allocated as a result of the offer.  As such, the application
>      can use some discretion on whether an answer should be applied as
>      provisional or final, and can change the type of the session
>      description as needed.  For example, in a serial forking scenario, an
>      application may receive multiple "final" answers, one from each
>      remote endpoint.  The application could choose to accept the initial
>      answers as provisional answers, and only apply an answer as final
>      when it receives one that meets its criteria (e.g. a live user
>      instead of voicemail).
>
> Issue: in this forking case, until the final selection is made it is
> unclear which one will need ICE completed. Only when a setlocal is done
> on one of the answers will ICE begin to be performed. Then, if another
> answer is provisionally set, won't that stop ICE for the prior one? And
> won't it require new candidates? What if one of the earlier ones is
> eventually chosen as final?
>
> And what if ICE completes for one of the candidates? Can't media start
> to flow? Then what if a different candidate is set as the final answer?
>
> Section 4.1.4.1:
>
> I question the following:
>
>      ...  While it is good practice to send an immediate
>      response to an "offer", in order to warm up the session transport and
>      prevent media clipping, the preferred handling for a web application
>      would be to create and send an "inactive" final answer immediately
>      after receiving the offer.  Later, when the called user actually
>      accepts the call, the application can create a new "sendrecv" offer
>      to update the previous offer/answer pair and start the media flow.
>
> This is very unfriendly when receiving calls that might be forked. By
> immediately "answering" a call before knowing if the user will accept
> it, you preempt the possibility that it will be answered on some other fork.
>
> For instance, if a call could come to your browser, or be sent to an
> answering service, and your broswer is on but you aren't present to
> accept the call, then the call will be accepted and then dropped rather
> than sent to the answering machine.
>
> So this technique should not be used if there is any possibility that
> the request could be coming from a source that might try other
> possibilities.
>
> Section 5.2.1:
>
>      When createOffer is called for the first time, the result is known as
>      the initial offer.
>
> By this definition, if a peer connection initially *received* an offer
> and sent an answer, and then it later sends an offer then that offer
> would be considered an initial offer.
>
> I think perhaps what is intended is:
>
>      When createOffer is called before setLocal has been called with
>      an offer,  the result is known as the initial offer.
>
> The following doesn't support the "balanced" BUNDLE policy:
>
>      Once all m= sections have been generated, a session-level "a=group"
>      attribute MUST be added as specified in [RFC5888].  This attribute
>      MUST have semantics "BUNDLE", and MUST include the mid identifiers of
>      each m= section.  The effect of this is that the browser offers all
>      m= sections as one BUNDLE group.  However, whether the m= sections
>      are bundle-only or not depends on the BUNDLE policy.
>
> Section 5.2.2 says:
>
>      o  If any MediaStreamTracks have been added, and there exist recvonly
>         m= sections of the appropriate media type with no associated
>         MediaStreamTracks, or rejected m= sections of any media type,
>         those m= sections MUST be recycled, and a local MediaStreamTrack
>         associated with these recycled m= sections until all such existing
>         m= sections have been used.  This includes any recvonly or
>         rejected m= sections created by the preceding paragraph.
>
> This fails to say anything about codec compatibility. SDP O/A requires
> the answer to be a subset of the offer in terms of PT/codec
> configuration. You should not use the same m-line unless there is a
> desire to use the same settings for the new track as are currently in
> use in the other direction.
>
> Section 5.3.1:
>
>      When createAnswer is called for the first time after a remote
>      description has been provided, the result is known as the initial
>      answer.
>
> By this definition, if a peer connection initially sent an offer and
> received an answer, and then it later receives an offer then the answer
> to that first *received* offer would be considered an Initial Answer.
>
> I think perhaps what is intended is:
>
>      When createAnswer is called before setLocal has been called with
>      an offer,  the result is known as the initial answer.
>
> When specifying the mapping of local tracks to m-lines in a received
> offer, there is again no discussion of codec compatibility. It is quite
> possible that the m-line chosen by the algorithm in this section won't
> have compatible codec attributes, but some other m-line will.
>
> Sections 5.3.2, 5.3.3, and 5.4-5.7:
>
> Are these empty because the content is yet to be written?
>
> Section 6:
>
> Other likely changes are addition of extra attributes and maybe other
> parameters. For instance, CLUE will want to add another grouping construct.
>
> Thanks,
> Paul
>
>


From nobody Sat Jul 19 11:59:10 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BADF1B2A73; Sat, 19 Jul 2014 11:59:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kv9b58s9ELJ6; Sat, 19 Jul 2014 11:59:05 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AD241B2A29; Sat, 19 Jul 2014 11:59:03 -0700 (PDT)
X-AuditID: c1b4fb3a-f79a36d000000ffa-a0-53cabff562de
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 7A.CD.04090.5FFBAC35; Sat, 19 Jul 2014 20:59:01 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0174.001; Sat, 19 Jul 2014 20:59:01 +0200
From: Christer Holmberg 
To: Paul Kyzivat , "kiran.guduru@samsung.com" , "rtcweb-request@ietf.org" , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
Thread-Index: AQHPo1ZRB4ao1PZKb02IVbig7HO8LZunv/+Q
Date: Sat, 19 Jul 2014 18:59:00 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3CB4E6@ESESSMB209.ericsson.se>
References: <58.C9.03708.ACAD9C35@epcpsbgx1.samsung.com> <53CA7426.6030602@alum.mit.edu>
In-Reply-To: <53CA7426.6030602@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM+Jvje7X/aeCDTqWmFucbHzLYrFiwwFW i5sTtrBZrP3Xzu7A4vH3/QcmjyVLfjJ59G1ZxRjAHMVlk5Kak1mWWqRvl8CV0bP7AlvBVZeK 0209zA2MU0y7GDk5JARMJBac/MACYYtJXLi3nq2LkYtDSOAoo8TmfedYIJxFjBJ3Lh5n7mLk 4GATsJDo/qcNEhcR2Mso8WH9KyaQbmEBS4kTr86D2SICVhK/G9czQthGEsf774LZLAKqEivX /2MHsXkFfCXW3G9jA7GFBKIkNu/pALM5BXQknk3vZQWxGYEu+n5qDdhMZgFxiVtP5jNBXCog sWTPeWYIW1Ti5eN/rBC2ksSi25+h6nUkFuz+xAZha0ssW/iaGWKvoMTJmU9YJjCKzkIydhaS lllIWmYhaVnAyLKKUbQ4tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzCODm75bbWD8eBzx0OMAhyM Sjy8CxJOBguxJpYVV+YeYpTmYFES5114bl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkYH V8am6RffJk8/N3Wr99PYPl3zGMF+o71Wus5rXksz57v9kC02OyXdaLiBq7ChU/5Ef9Ub+Uru tG+/PJ898l7xTDdc6IG0+LnD1Va5yyMPuJ37ITnlm0PWY0X5yfMWPvKdY/v53S23c+dmnOmf vGZJyBLfk5PnZxh8+Hbwn8S8XvslnCnXV5QosRRnJBpqMRcVJwIAVA0zx4QCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/amDodMMUMCy8ZPROpihmsCZmHJo
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 19 Jul 2014 18:59:07 -0000

Hi,

>My need won't be satisfied by plausible constraints.
>For instance, to interwork with CLUE it will be necessary to add an "a=3Dg=
roup:clue" and include in it >those m-lines that are to be "clue controlled=
". And that is needed in both offer and answer >processing.

I agree with Paul.

The same applies if someone implements an JavaScript IMS client, in which c=
ase the JavaScript app very likely will add stuff to SDP.

Regards,

Christer




On 7/18/14 10:41 PM, Kiran Kumar Guduru wrote:
> Dear Paul,
>
> My comment is only regarding the comments on section 6 of the JSEP draft.
>
> The sdp mangling described in section 6 may result in various error=20
> scenarios.
>
> In that section, it is described like most of the parameters can be=20
> modified thorugh constraints.
>
> The required modification, I found, which cannot not be done by the=20
> constraints is "Remove or reorder of codecs (m=3D)"
>
> In order to avoid the SDP mangling at Java Script application level, I=20
> submitted a draft for changing the codec preferences=20
> http://tools.ietf.org/html/draft-guduru-rtcweb-codec-preferences-01.
> (Please review it).
>
> If this proposal is acceptable to the group, I hope we can remove=20
> section 6 from JSEP draft.
>
> (Expecting that we can find alternatives for adding extra attributes=20
> like CLUE as identified by you, for example by extending the proposed=20
> RTCRTPSender/Receiver by adding a generic setSdPAttribute (key,
> value) method).
>
> Thanks,
>
> Kiran.
>
>
>
> -------Original Message--------
> Sent: Paul Kyzivat
> Date: Fri, 18 Jul 2014 14:32:24 -0400
> Subject: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
>
> I just did my first thorough read-through of JSEP in quite some time.=20
> I came away with a number of concerns:
>
> Section 1.1:
>
> When describing offers, modification by the application is mentioned:
>
>      JSEP's handling of session descriptions is simple and
>      straightforward.  Whenever an offer/answer exchange is needed, the
>      initiating side creates an offer by calling a createOffer() API.  Th=
e
>      application *optionally modifies that offer*, and then uses it to se=
t
>      up its local config via the setLocalDescription() API.
>
> but when describing answers it is not:
>
>      When the call is accepted, the callee uses the createAnswer() API to
>      generate an appropriate answer, applies it using
>      setLocalDescription(), and sends the answer back to the initiator
>      over the signaling channel.  When the offerer gets that answer, it
>      installs it using setRemoteDescription(), and initial setup is
>      complete.
>
> And Section 6 only talks about changing offers, not answers. It is=20
> equally important to be able to modify answers. (More on this in later=20
> comment on section 6.)
>
> Section 4.1.4:
>
>      The only difference between a provisional and final answer is that
>      the final answer results in the freeing of any unused resources that
>      were allocated as a result of the offer.  As such, the application
>      can use some discretion on whether an answer should be applied as
>      provisional or final, and can change the type of the session
>      description as needed.  For example, in a serial forking scenario, a=
n
>      application may receive multiple "final" answers, one from each
>      remote endpoint.  The application could choose to accept the initial
>      answers as provisional answers, and only apply an answer as final
>      when it receives one that meets its criteria (e.g. a live user
>      instead of voicemail).
>
> Issue: in this forking case, until the final selection is made it is=20
> unclear which one will need ICE completed. Only when a setlocal is=20
> done on one of the answers will ICE begin to be performed. Then, if=20
> another answer is provisionally set, won't that stop ICE for the prior=20
> one? And won't it require new candidates? What if one of the earlier=20
> ones is eventually chosen as final?
>
> And what if ICE completes for one of the candidates? Can't media start=20
> to flow? Then what if a different candidate is set as the final answer?
>
> Section 4.1.4.1:
>
> I question the following:
>
>      ...  While it is good practice to send an immediate
>      response to an "offer", in order to warm up the session transport an=
d
>      prevent media clipping, the preferred handling for a web application
>      would be to create and send an "inactive" final answer immediately
>      after receiving the offer.  Later, when the called user actually
>      accepts the call, the application can create a new "sendrecv" offer
>      to update the previous offer/answer pair and start the media flow.
>
> This is very unfriendly when receiving calls that might be forked. By=20
> immediately "answering" a call before knowing if the user will accept=20
> it, you preempt the possibility that it will be answered on some other fo=
rk.
>
> For instance, if a call could come to your browser, or be sent to an=20
> answering service, and your broswer is on but you aren't present to=20
> accept the call, then the call will be accepted and then dropped=20
> rather than sent to the answering machine.
>
> So this technique should not be used if there is any possibility that=20
> the request could be coming from a source that might try other=20
> possibilities.
>
> Section 5.2.1:
>
>      When createOffer is called for the first time, the result is known a=
s
>      the initial offer.
>
> By this definition, if a peer connection initially *received* an offer=20
> and sent an answer, and then it later sends an offer then that offer=20
> would be considered an initial offer.
>
> I think perhaps what is intended is:
>
>      When createOffer is called before setLocal has been called with
>      an offer,  the result is known as the initial offer.
>
> The following doesn't support the "balanced" BUNDLE policy:
>
>      Once all m=3D sections have been generated, a session-level "a=3Dgro=
up"
>      attribute MUST be added as specified in [RFC5888].  This attribute
>      MUST have semantics "BUNDLE", and MUST include the mid identifiers o=
f
>      each m=3D section.  The effect of this is that the browser offers al=
l
>      m=3D sections as one BUNDLE group.  However, whether the m=3D sectio=
ns
>      are bundle-only or not depends on the BUNDLE policy.
>
> Section 5.2.2 says:
>
>      o  If any MediaStreamTracks have been added, and there exist recvonl=
y
>         m=3D sections of the appropriate media type with no associated
>         MediaStreamTracks, or rejected m=3D sections of any media type,
>         those m=3D sections MUST be recycled, and a local MediaStreamTrac=
k
>         associated with these recycled m=3D sections until all such exist=
ing
>         m=3D sections have been used.  This includes any recvonly or
>         rejected m=3D sections created by the preceding paragraph.
>
> This fails to say anything about codec compatibility. SDP O/A requires=20
> the answer to be a subset of the offer in terms of PT/codec=20
> configuration. You should not use the same m-line unless there is a=20
> desire to use the same settings for the new track as are currently in=20
> use in the other direction.
>
> Section 5.3.1:
>
>      When createAnswer is called for the first time after a remote
>      description has been provided, the result is known as the initial
>      answer.
>
> By this definition, if a peer connection initially sent an offer and=20
> received an answer, and then it later receives an offer then the=20
> answer to that first *received* offer would be considered an Initial Answ=
er.
>
> I think perhaps what is intended is:
>
>      When createAnswer is called before setLocal has been called with
>      an offer,  the result is known as the initial answer.
>
> When specifying the mapping of local tracks to m-lines in a received=20
> offer, there is again no discussion of codec compatibility. It is=20
> quite possible that the m-line chosen by the algorithm in this section=20
> won't have compatible codec attributes, but some other m-line will.
>
> Sections 5.3.2, 5.3.3, and 5.4-5.7:
>
> Are these empty because the content is yet to be written?
>
> Section 6:
>
> Other likely changes are addition of extra attributes and maybe other=20
> parameters. For instance, CLUE will want to add another grouping construc=
t.
>
> Thanks,
> Paul
>
>

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


From nobody Sat Jul 19 20:51:01 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D991B2B5A for ; Sat, 19 Jul 2014 20:50:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 3VYXr8yUIVd8 for ; Sat, 19 Jul 2014 20:50:48 -0700 (PDT)
Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68FBA1B2B53 for ; Sat, 19 Jul 2014 20:50:45 -0700 (PDT)
Received: by mail-vc0-f173.google.com with SMTP id hy10so10085321vcb.18 for ; Sat, 19 Jul 2014 20:50:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3d6nAy3+AnRDnMqyjF17EozMhgbcN0qYxCAQTA99woQ=; b=TRNVXq3m41bDz2FUWUmcG0gKP7Yl352xRCaZcRY5HZhjr64F9QEoi7kp4G9bRwgT0e 8TDzzyErvyJvvlhhtq3y8MPddcAbKrIWNU++XmXwBQaqIcwCGBWjiSscBIsvwaiVWNRt d3xLOJHGFIMqBGBEM+z4aAeP7SUEEZe3U8EQ4keEqN3SDNrPzvQk1lLAsgcrc83uR1Qm 8kzCfqKjpNMKRozWVJOnOoDV3oYADRMqNbJfKuFxrLKE/JdAlY5bTOaNgXPmo6acIBfx eUurwPcmisUIV3hH3muyBV9/k2uUSqUAFmADim62xc/km2269CiYV9uUvySOHukE5gXa dEBg==
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:content-type; bh=3d6nAy3+AnRDnMqyjF17EozMhgbcN0qYxCAQTA99woQ=; b=L8okZqpQtDHpK1/Lx+qz2VMsG2ntzSSCLj4bHNMNYxIXdtQMAV/Fq7isaV8rlMewIh M2TGPj4+EqC29oPZK32KuJfSxBVuf1QasYSIN7qf0CbT6aj8nPa3lnGKJKFIN5OcvFL2 NyyICPhF+aQrG7sYTX6s+97s1IrnFfd15uibwucU0ah1q0a6dDnL5GnLHrQGk+7h48QD HqyZe8mbpe+uPyPh980tovHvURAFzdxz/KsaHotJx4gyGzVRvUCLKokOTtpclNz3ERFE nhBVH+sGn69PF4QyWmDMHV0QDES6gPiAEfZJ6BE5NPMtrwJKu5O1x8OpB0MFM2O2Ib4v HbVw==
X-Gm-Message-State: ALoCoQkQA/xyZkEqkx+LV0BmDfZKdgu4KX2Aw0QCO0GXl10QggbyYMxd3HlSTQQOJPC9HC1eaP97
X-Received: by 10.220.163.3 with SMTP id y3mr18367309vcx.7.1405828244170; Sat, 19 Jul 2014 20:50:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.66.242 with HTTP; Sat, 19 Jul 2014 20:50:24 -0700 (PDT)
In-Reply-To: 
References:      <6355614E-44DA-4729-97C2-E903548EBA8B@gmail.com> <949EF20990823C4C85C18D59AA11AD8B1FC18D@FR712WXCHMBA11.zeu.alcatel-lucent.com>  <53B660BC.4090907@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8B1FD11D@FR712WXCHMBA11.zeu.alcatel-lucent.com>  <9D7AEC5F-2955-4044-B8DE-A80006994AEB@lurchi.franken.de>   
From: Justin Uberti 
Date: Sat, 19 Jul 2014 23:50:24 -0400
Message-ID: 
To: Shijun Sun 
Content-Type: multipart/alternative; boundary=001a1133da661c141004fe97e5eb
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wq5rgSgoTi4DsGK0jKpeTruIYAk
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] DTLS version
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Jul 2014 03:50:50 -0000

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

I was thinking the baseline cipher suite would be
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (note RSA instead of ECDSA), as the best
choice that maintains 1.0 compatibility.

I think we could also have a SHOULD for
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the preferred TLS 1.2 ciphersuite.


On Mon, Jul 7, 2014 at 5:29 PM, Shijun Sun  wrote:

> There seems a preference on supporting DTLS 1.0 due to the widespread
> adoption.  There is also a desire of supporting ECDHE when ECC is on a
> Standards Track.  Hope we could reach a consensus in Toronto.
>
> To keep the discussions going, here is a proposal with a specific cipher
> suite based on DTLS 1.0.
>
>     All implementations MUST implement the cipher suite
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
>     based on DTLS 1.0 with P256 as the curve to be used with ECDHE and
> ECDSA.  The Implementations
>     MAY advertise additional cipher suites based on DTLS 1.0 and/or DTLS
> 1.2 definitions, for example,
>     TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA with P256.
>
> We could keep DTLS 1.2 as an optional implementation decision for now and
> make that (and some corresponding new cipher suites) as required in the
> future.
>
> Thoughts?
>
> Best, Shijun
>
> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Michael Tuexen
> Sent: Friday, July 4, 2014 2:28 PM
> To: Eric Rescorla
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] DTLS version
>
> On 04 Jul 2014, at 23:19, Eric Rescorla  wrote:
>
> >
> >
> >
> > On Fri, Jul 4, 2014 at 2:11 PM, Michael Tuexen <
> Michael.Tuexen@lurchi.franken.de> wrote:
> > On 04 Jul 2014, at 21:48, Eric Rescorla  wrote:
> >
> > > I made this change in the current draft at:
> > >
> > > https://github.com/rtcweb-wg/security-arch/commit/c2af2bf7fd032abd36
> > > 7dff8d4d16f7ec435fa663
> > If implementations MUST implement both DTLS 1.0 and 1.2, when will
> > they use 1.0? Wouldn't they always use DTLS 1.2?
> >
> > There are non-RTCWEB implementations of these protocols.
> OK. Any suggested test for the SCTP over DTLS spec? It currently says MUST
> be based on DTLS 1.0 (as you suggested).
>
> Best regards
> Michael
> >
> > -Ekr
> >
> > Best regards
> > Michael
> > >
> > > Note that the TLS WG is currently discussing whether to bring ECC onto
> Standards Track.
> > > If they do, we probably want ot require support of ECDHE. We should
> discuss in YYZ.
> > >
> > >
> > >
> > > On Fri, Jul 4, 2014 at 3:23 AM, DRAGE, Keith (Keith) <
> keith.drage@alcatel-lucent.com> wrote:
> > > This is the direction I am tending in as well.
> > >
> > > Although what or if the second statement needs from RFC 2119 language
> would need to be debated.
> > >
> > > Obviously, new versions are not being put out there just to make it
> look like the WG is performing. In any referencing (not just this issue), I
> would need a good technical reason why the latest version cannot be made
> the normative reference. I am not seeing that at the moment.
> > >
> > > There is always be non-conforming equipment on the market (as an
> example look at the number of SIP implementations that still use UDP for
> large messages, or that can at least be configured that way). Just because
> we mandate 1.2 does not mean that everyone will conform from day 1, but at
> least a marker is established for what should be addressed if
> interoperability issues are identified.
> > >
> > > Keith
> > >
> > > > -----Original Message-----
> > > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald
> > > > Alvestrand
> > > > Sent: 04 July 2014 09:07
> > > > To: rtcweb@ietf.org
> > > > Subject: Re: [rtcweb] DTLS version
> > > >
> > > > On 07/03/2014 07:58 PM, Martin Thomson wrote:
> > > > > On 3 July 2014 01:39, DRAGE, Keith (Keith)
> > > > >  wrote:
> > > > >> Can someone elaborate what this massive apparent step
> > > > change is from 1.0 to 1.2?
> > > > > Actually, it's not a massive step.  TLS 1.2 (DTLS 1.2
> > > > depends on this,
> > > > > DTLS 1.0 depends on TLS 1.1) adds AEAD modes, but doesn't
> > > > > require their use, so you can pretty much just bump the version
> > > > > number and advertise 1.2.  That's exactly what we did with NSS,
> > > > > though NSS already supports TLS 1.2.
> > > > >
> > > > > That said, I agree with Jim about 1.0.  There's enough 1.0
> > > > out there
> > > > > now to make mandating 1.2 - as much as I might prefer that
> > > > - a little
> > > > > too aggressive.
> > > > >
> > > > >> Will those implementations that choose to stay with 1.0
> > > > still interwork with 1.2?
> > > > > That depends.  We could say "MUST NOT negotiate 1.0", which
> > > > > would prevent that.  I don't think that we're there.
> > > >
> > > > Sounds to me like MUST implement 1.2 (in order to move forward),
> > > > MUST accept 1.0 (in order to not lose the long tail).
> > > >
> > > > >
> > > > > _______________________________________________
> > > > > rtcweb mailing list
> > > > > rtcweb@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/rtcweb
> > > >
> > > > _______________________________________________
> > > > rtcweb mailing list
> > > > rtcweb@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/rtcweb
> > > >
> > > _______________________________________________
> > > rtcweb mailing list
> > > rtcweb@ietf.org
> > > https://www.ietf.org/mailman/listinfo/rtcweb
> > >
> > > _______________________________________________
> > > rtcweb mailing list
> > > rtcweb@ietf.org
> > > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

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


I was thinking the baseline cipher suite would be=C2=A0TLS_ECDHE_RSA_WITH=
_AES_128_CBC_SHA (note RSA instead of ECDSA), as the best choice that mainta=
ins 1.0 compatibility.



I=C2=A0think we could also have a SHOULD for TLS_ECDHE_RSA_W=
ITH_AES_128_GCM_SHA256 as the preferred TLS 1.2 ciphersuite.


On Mon, Jul 7, 2=
014 at 5:29 PM, Shijun Sun <shijuns@microsoft.com> wrote=
:



There seems a preference on supporting DTLS =
1.0 due to the widespread adoption. =C2=A0There is also a desire of support=
ing ECDHE when ECC is on a Standards Track. =C2=A0Hope we could reach a con=
sensus in Toronto.





To keep the discussions going, here is a proposal with a specific cipher su=
ite based on DTLS 1.0.



=C2=A0 =C2=A0 All implementations MUST implement the cipher suite TLS_ECDHE=
_ECDSA_WITH_AES_128_CBC_SHA

=C2=A0 =C2=A0 based on DTLS 1.0 with P256 as the curve to be used with ECDH=
E and ECDSA. =C2=A0The Implementations

=C2=A0 =C2=A0 MAY advertise additional cipher suites based on DTLS 1.0 and/=
or DTLS 1.2 definitions, for example,

=C2=A0 =C2=A0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA with P256.



We could keep DTLS 1.2 as an optional implementation decision for now and m=
ake that (and some corresponding new cipher suites) as required in the futu=
re.



Thoughts?



Best, Shijun




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

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

Sent: Friday, July 4, 2014 2:28 PM

To: Eric Rescorla

Cc: rtcweb@ietf.org

Subject: Re: [rtcweb] DTLS version




On 04 Jul 2014, at 23:19, Eri=
c Rescorla <ekr@rtfm.com> wrote:<=
br>


>

>

>

> On Fri, Jul 4, 2014 at 2:11 PM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> w=
rote:

> On 04 Jul 2014, at 21:48, Eric Rescorla <ekr@rtfm.com> wrote:

>

> > I made this change in the current draft at:

> >

> > https://github.com/rtcweb-wg/security-arc=
h/commit/c2af2bf7fd032abd36

> > 7dff8d4d16f7ec435fa663

> If implementations MUST implement both DTLS 1.0 and 1.2, when will

> they use 1.0? Wouldn't they always use DTLS 1.2?

>

> There are non-RTCWEB implementations of these protocols.

OK. Any suggested test for the SCTP over DTLS spec? It currently says MUST =
be based on DTLS 1.0 (as you suggested).



Best regards

Michael

>

> -Ekr

>

> Best regards

> Michael

> >

> > Note that the TLS WG is currently discussing whether to bring ECC=
 onto Standards Track.

> > If they do, we probably want ot require support of ECDHE. We shou=
ld discuss in YYZ.

> >

> >

> >

> > On Fri, Jul 4, 2014 at 3:23 AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:

> > This is the direction I am tending in as well.

> >

> > Although what or if the second statement needs from RFC 2119 lang=
uage would need to be debated.

> >

> > Obviously, new versions are not being put out there just to make =
it look like the WG is performing. In any referencing (not just this issue)=
, I would need a good technical reason why the latest version cannot be mad=
e the normative reference. I am not seeing that at the moment.



> >

> > There is always be non-conforming equipment on the market (as an =
example look at the number of SIP implementations that still use UDP for la=
rge messages, or that can at least be configured that way). Just because we=
 mandate 1.2 does not mean that everyone will conform from day 1, but at le=
ast a marker is established for what should be addressed if interoperabilit=
y issues are identified.



> >

> > Keith

> >

> > > -----Original Message-----

> > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald

> > > Alvestrand

> > > Sent: 04 July 2014 09:07

> > > To: rtcweb@ietf.org
> > > Subject: Re: [rtcweb] DTLS version

> > >

> > > On 07/03/2014 07:58 PM, Martin Thomson wrote:

> > > > On 3 July 2014 01:39, DRAGE, Keith (Keith)

> > > > <k=
eith.drage@alcatel-lucent.com> wrote:

> > > >> Can someone elaborate what this massive apparent st=
ep

> > > change is from 1.0 to 1.2?

> > > > Actually, it's not a massive step. =C2=A0TLS 1.2 (D=
TLS 1.2

> > > depends on this,

> > > > DTLS 1.0 depends on TLS 1.1) adds AEAD modes, but doesn=
't

> > > > require their use, so you can pretty much just bump the=
 version

> > > > number and advertise 1.2. =C2=A0That's exactly what=
 we did with NSS,

> > > > though NSS already supports TLS 1.2.

> > > >

> > > > That said, I agree with Jim about 1.0. =C2=A0There'=
s enough 1.0

> > > out there

> > > > now to make mandating 1.2 - as much as I might prefer t=
hat

> > > - a little

> > > > too aggressive.

> > > >

> > > >> Will those implementations that choose to stay with=
 1.0

> > > still interwork with 1.2?

> > > > That depends. =C2=A0We could say "MUST NOT negotia=
te 1.0", which

> > > > would prevent that. =C2=A0I don't think that we'=
;re there.

> > >

> > > Sounds to me like MUST implement 1.2 (in order to move forwa=
rd),

> > > MUST accept 1.0 (in order to not lose the long tail).

> > >

> > > >

> > > > _______________________________________________

> > > > rtcweb mailing list

> > > > rtcweb@ietf.org<=
br>
> > > > https://www.ietf.org/mailman/listinfo/rtcweb

> > >

> > > _______________________________________________

> > > rtcweb mailing list

> > > rtcweb@ietf.org

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

> > >

> > _______________________________________________

> > rtcweb mailing list

> > rtcweb@ietf.org

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

> >

> > _______________________________________________

> > rtcweb mailing list

> > rtcweb@ietf.org

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

>

>



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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





--001a1133da661c141004fe97e5eb--


From nobody Sun Jul 20 04:58:34 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895821B2BB7 for ; Sun, 20 Jul 2014 04:58:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfhjrjoxI4Oz for ; Sun, 20 Jul 2014 04:58:29 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31A491B281C for ; Sun, 20 Jul 2014 04:58:29 -0700 (PDT)
Received: from BLUPR03MB405.namprd03.prod.outlook.com (10.141.78.15) by BLUPR03MB406.namprd03.prod.outlook.com (10.141.78.23) with Microsoft SMTP Server (TLS) id 15.0.985.8; Sun, 20 Jul 2014 11:58:27 +0000
Received: from BLUPR03MB405.namprd03.prod.outlook.com ([10.141.78.15]) by BLUPR03MB405.namprd03.prod.outlook.com ([10.141.78.15]) with mapi id 15.00.0985.008; Sun, 20 Jul 2014 11:58:27 +0000
From: Shijun Sun 
To: Justin Uberti 
Thread-Topic: [rtcweb] DTLS version
Thread-Index: AQHPlpICeV5LRgJomEee9jrC1yXJQ5uN+SAAgAAOY4CAAJwqgIAA7SgAgAAmEYCAAJ3nAIAAFyaAgAACUACAAAJLAIAErRgwgBNQrgCAAIVLEA==
Date: Sun, 20 Jul 2014 11:58:25 +0000
Message-ID: <17987d3c6f3c49d8bacfbd613daa75a6@BLUPR03MB405.namprd03.prod.outlook.com>
References:      <6355614E-44DA-4729-97C2-E903548EBA8B@gmail.com> <949EF20990823C4C85C18D59AA11AD8B1FC18D@FR712WXCHMBA11.zeu.alcatel-lucent.com>  <53B660BC.4090907@alvestrand.no> <949EF20990823C4C85C18D59AA11AD8B1FD11D@FR712WXCHMBA11.zeu.alcatel-lucent.com>  <9D7AEC5F-2955-4044-B8DE-A80006994AEB@lurchi.franken.de>    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [173.243.47.194]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 02788FF38E
x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(51704005)(13464003)(479174003)(24454002)(377454003)(85852003)(99396002)(80022001)(76176999)(54356999)(74502001)(86612001)(74662001)(19300405004)(101416001)(81342001)(33646002)(19580405001)(19580395003)(46102001)(66066001)(92566001)(64706001)(31966008)(86362001)(20776003)(106116001)(74316001)(93886003)(50986999)(19609705001)(106356001)(81542001)(21056001)(95666004)(76576001)(85306003)(19617315012)(87936001)(15202345003)(83072002)(110136001)(4396001)(561944003)(107046002)(2656002)(105586002)(15975445006)(16236675004)(79102001)(19625215002)(77982001)(76482001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB406; H:BLUPR03MB405.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_17987d3c6f3c49d8bacfbd613daa75a6BLUPR03MB405namprd03pro_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DamEAHml6NuS5BkBPi0Z50o4uDE
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] DTLS version
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Jul 2014 11:58:32 -0000

--_000_17987d3c6f3c49d8bacfbd613daa75a6BLUPR03MB405namprd03pro_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SeKAmW0gZmluZSB3aXRoIHRoZSBiYXNlbGluZSAoTVVTVCkgcHJvcG9zZWQgYnkgSnVzdGluLg0K
DQpXZSBjYW4ga2VlcCB0aGUgRUNEU0Egb3B0aW9uIGFzIGEgcmVjb21tZW5kYXRpb24gKGFzIGFu
b3RoZXIgU0hPVUxEIG9yIE1BWSkgaWYgc29tZSBpbXBsZW1lbnRhdGlvbnMgYXJlIGV4cGVjdGVk
IHRvIG1vdmUgdG8gaXQgb3ZlciB0aW1lLg0KDQpGcm9tOiBKdXN0aW4gVWJlcnRpIFttYWlsdG86
anViZXJ0aUBnb29nbGUuY29tXQ0KU2VudDogU2F0dXJkYXksIEp1bHkgMTksIDIwMTQgODo1MCBQ
TQ0KVG86IFNoaWp1biBTdW4NCkNjOiBNaWNoYWVsIFR1ZXhlbjsgRXJpYyBSZXNjb3JsYTsgcnRj
d2ViQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gRFRMUyB2ZXJzaW9uDQoNCkkgd2Fz
IHRoaW5raW5nIHRoZSBiYXNlbGluZSBjaXBoZXIgc3VpdGUgd291bGQgYmUgVExTX0VDREhFX1JT
QV9XSVRIX0FFU18xMjhfQ0JDX1NIQSAobm90ZSBSU0EgaW5zdGVhZCBvZiBFQ0RTQSksIGFzIHRo
ZSBiZXN0IGNob2ljZSB0aGF0IG1haW50YWlucyAxLjAgY29tcGF0aWJpbGl0eS4NCg0KSSB0aGlu
ayB3ZSBjb3VsZCBhbHNvIGhhdmUgYSBTSE9VTEQgZm9yIFRMU19FQ0RIRV9SU0FfV0lUSF9BRVNf
MTI4X0dDTV9TSEEyNTYgYXMgdGhlIHByZWZlcnJlZCBUTFMgMS4yIGNpcGhlcnN1aXRlLg0KDQpP
biBNb24sIEp1bCA3LCAyMDE0IGF0IDU6MjkgUE0sIFNoaWp1biBTdW4gPHNoaWp1bnNAbWljcm9z
b2Z0LmNvbTxtYWlsdG86c2hpanVuc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpUaGVyZSBzZWVt
cyBhIHByZWZlcmVuY2Ugb24gc3VwcG9ydGluZyBEVExTIDEuMCBkdWUgdG8gdGhlIHdpZGVzcHJl
YWQgYWRvcHRpb24uICBUaGVyZSBpcyBhbHNvIGEgZGVzaXJlIG9mIHN1cHBvcnRpbmcgRUNESEUg
d2hlbiBFQ0MgaXMgb24gYSBTdGFuZGFyZHMgVHJhY2suICBIb3BlIHdlIGNvdWxkIHJlYWNoIGEg
Y29uc2Vuc3VzIGluIFRvcm9udG8uDQoNClRvIGtlZXAgdGhlIGRpc2N1c3Npb25zIGdvaW5nLCBo
ZXJlIGlzIGEgcHJvcG9zYWwgd2l0aCBhIHNwZWNpZmljIGNpcGhlciBzdWl0ZSBiYXNlZCBvbiBE
VExTIDEuMC4NCg0KICAgIEFsbCBpbXBsZW1lbnRhdGlvbnMgTVVTVCBpbXBsZW1lbnQgdGhlIGNp
cGhlciBzdWl0ZSBUTFNfRUNESEVfRUNEU0FfV0lUSF9BRVNfMTI4X0NCQ19TSEENCiAgICBiYXNl
ZCBvbiBEVExTIDEuMCB3aXRoIFAyNTYgYXMgdGhlIGN1cnZlIHRvIGJlIHVzZWQgd2l0aCBFQ0RI
RSBhbmQgRUNEU0EuICBUaGUgSW1wbGVtZW50YXRpb25zDQogICAgTUFZIGFkdmVydGlzZSBhZGRp
dGlvbmFsIGNpcGhlciBzdWl0ZXMgYmFzZWQgb24gRFRMUyAxLjAgYW5kL29yIERUTFMgMS4yIGRl
ZmluaXRpb25zLCBmb3IgZXhhbXBsZSwNCiAgICBUTFNfRUNESEVfUlNBX1dJVEhfQUVTXzEyOF9D
QkNfU0hBIHdpdGggUDI1Ni4NCg0KV2UgY291bGQga2VlcCBEVExTIDEuMiBhcyBhbiBvcHRpb25h
bCBpbXBsZW1lbnRhdGlvbiBkZWNpc2lvbiBmb3Igbm93IGFuZCBtYWtlIHRoYXQgKGFuZCBzb21l
IGNvcnJlc3BvbmRpbmcgbmV3IGNpcGhlciBzdWl0ZXMpIGFzIHJlcXVpcmVkIGluIHRoZSBmdXR1
cmUuDQoNClRob3VnaHRzPw0KDQpCZXN0LCBTaGlqdW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS0NCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPG1haWx0
bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBNaWNoYWVsIFR1ZXhlbg0K
U2VudDogRnJpZGF5LCBKdWx5IDQsIDIwMTQgMjoyOCBQTQ0KVG86IEVyaWMgUmVzY29ybGENCkNj
OiBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb
cnRjd2ViXSBEVExTIHZlcnNpb24NCk9uIDA0IEp1bCAyMDE0LCBhdCAyMzoxOSwgRXJpYyBSZXNj
b3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+PiB3cm90ZToNCg0KPg0KPg0K
Pg0KPiBPbiBGcmksIEp1bCA0LCAyMDE0IGF0IDI6MTEgUE0sIE1pY2hhZWwgVHVleGVuIDxNaWNo
YWVsLlR1ZXhlbkBsdXJjaGkuZnJhbmtlbi5kZTxtYWlsdG86TWljaGFlbC5UdWV4ZW5AbHVyY2hp
LmZyYW5rZW4uZGU+PiB3cm90ZToNCj4gT24gMDQgSnVsIDIwMTQsIGF0IDIxOjQ4LCBFcmljIFJl
c2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdyb3RlOg0KPg0KPiA+
IEkgbWFkZSB0aGlzIGNoYW5nZSBpbiB0aGUgY3VycmVudCBkcmFmdCBhdDoNCj4gPg0KPiA+IGh0
dHBzOi8vZ2l0aHViLmNvbS9ydGN3ZWItd2cvc2VjdXJpdHktYXJjaC9jb21taXQvYzJhZjJiZjdm
ZDAzMmFiZDM2DQo+ID4gN2RmZjhkNGQxNmY3ZWM0MzVmYTY2Mw0KPiBJZiBpbXBsZW1lbnRhdGlv
bnMgTVVTVCBpbXBsZW1lbnQgYm90aCBEVExTIDEuMCBhbmQgMS4yLCB3aGVuIHdpbGwNCj4gdGhl
eSB1c2UgMS4wPyBXb3VsZG4ndCB0aGV5IGFsd2F5cyB1c2UgRFRMUyAxLjI/DQo+DQo+IFRoZXJl
IGFyZSBub24tUlRDV0VCIGltcGxlbWVudGF0aW9ucyBvZiB0aGVzZSBwcm90b2NvbHMuDQpPSy4g
QW55IHN1Z2dlc3RlZCB0ZXN0IGZvciB0aGUgU0NUUCBvdmVyIERUTFMgc3BlYz8gSXQgY3VycmVu
dGx5IHNheXMgTVVTVCBiZSBiYXNlZCBvbiBEVExTIDEuMCAoYXMgeW91IHN1Z2dlc3RlZCkuDQoN
CkJlc3QgcmVnYXJkcw0KTWljaGFlbA0KPg0KPiAtRWtyDQo+DQo+IEJlc3QgcmVnYXJkcw0KPiBN
aWNoYWVsDQo+ID4NCj4gPiBOb3RlIHRoYXQgdGhlIFRMUyBXRyBpcyBjdXJyZW50bHkgZGlzY3Vz
c2luZyB3aGV0aGVyIHRvIGJyaW5nIEVDQyBvbnRvIFN0YW5kYXJkcyBUcmFjay4NCj4gPiBJZiB0
aGV5IGRvLCB3ZSBwcm9iYWJseSB3YW50IG90IHJlcXVpcmUgc3VwcG9ydCBvZiBFQ0RIRS4gV2Ug
c2hvdWxkIGRpc2N1c3MgaW4gWVlaLg0KPiA+DQo+ID4NCj4gPg0KPiA+IE9uIEZyaSwgSnVsIDQs
IDIwMTQgYXQgMzoyMyBBTSwgRFJBR0UsIEtlaXRoIChLZWl0aCkgPGtlaXRoLmRyYWdlQGFsY2F0
ZWwtbHVjZW50LmNvbTxtYWlsdG86a2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tPj4gd3Jv
dGU6DQo+ID4gVGhpcyBpcyB0aGUgZGlyZWN0aW9uIEkgYW0gdGVuZGluZyBpbiBhcyB3ZWxsLg0K
PiA+DQo+ID4gQWx0aG91Z2ggd2hhdCBvciBpZiB0aGUgc2Vjb25kIHN0YXRlbWVudCBuZWVkcyBm
cm9tIFJGQyAyMTE5IGxhbmd1YWdlIHdvdWxkIG5lZWQgdG8gYmUgZGViYXRlZC4NCj4gPg0KPiA+
IE9idmlvdXNseSwgbmV3IHZlcnNpb25zIGFyZSBub3QgYmVpbmcgcHV0IG91dCB0aGVyZSBqdXN0
IHRvIG1ha2UgaXQgbG9vayBsaWtlIHRoZSBXRyBpcyBwZXJmb3JtaW5nLiBJbiBhbnkgcmVmZXJl
bmNpbmcgKG5vdCBqdXN0IHRoaXMgaXNzdWUpLCBJIHdvdWxkIG5lZWQgYSBnb29kIHRlY2huaWNh
bCByZWFzb24gd2h5IHRoZSBsYXRlc3QgdmVyc2lvbiBjYW5ub3QgYmUgbWFkZSB0aGUgbm9ybWF0
aXZlIHJlZmVyZW5jZS4gSSBhbSBub3Qgc2VlaW5nIHRoYXQgYXQgdGhlIG1vbWVudC4NCj4gPg0K
PiA+IFRoZXJlIGlzIGFsd2F5cyBiZSBub24tY29uZm9ybWluZyBlcXVpcG1lbnQgb24gdGhlIG1h
cmtldCAoYXMgYW4gZXhhbXBsZSBsb29rIGF0IHRoZSBudW1iZXIgb2YgU0lQIGltcGxlbWVudGF0
aW9ucyB0aGF0IHN0aWxsIHVzZSBVRFAgZm9yIGxhcmdlIG1lc3NhZ2VzLCBvciB0aGF0IGNhbiBh
dCBsZWFzdCBiZSBjb25maWd1cmVkIHRoYXQgd2F5KS4gSnVzdCBiZWNhdXNlIHdlIG1hbmRhdGUg
MS4yIGRvZXMgbm90IG1lYW4gdGhhdCBldmVyeW9uZSB3aWxsIGNvbmZvcm0gZnJvbSBkYXkgMSwg
YnV0IGF0IGxlYXN0IGEgbWFya2VyIGlzIGVzdGFibGlzaGVkIGZvciB3aGF0IHNob3VsZCBiZSBh
ZGRyZXNzZWQgaWYgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMgYXJlIGlkZW50aWZpZWQuDQo+ID4N
Cj4gPiBLZWl0aA0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4g
RnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dl
Yi1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEhhcmFsZA0KPiA+ID4gQWx2ZXN0cmFu
ZA0KPiA+ID4gU2VudDogMDQgSnVseSAyMDE0IDA5OjA3DQo+ID4gPiBUbzogcnRjd2ViQGlldGYu
b3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQo+ID4gPiBTdWJqZWN0OiBSZTogW3J0Y3dlYl0g
RFRMUyB2ZXJzaW9uDQo+ID4gPg0KPiA+ID4gT24gMDcvMDMvMjAxNCAwNzo1OCBQTSwgTWFydGlu
IFRob21zb24gd3JvdGU6DQo+ID4gPiA+IE9uIDMgSnVseSAyMDE0IDAxOjM5LCBEUkFHRSwgS2Vp
dGggKEtlaXRoKQ0KPiA+ID4gPiA8a2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0
bzprZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb20+PiB3cm90ZToNCj4gPiA+ID4+IENhbiBz
b21lb25lIGVsYWJvcmF0ZSB3aGF0IHRoaXMgbWFzc2l2ZSBhcHBhcmVudCBzdGVwDQo+ID4gPiBj
aGFuZ2UgaXMgZnJvbSAxLjAgdG8gMS4yPw0KPiA+ID4gPiBBY3R1YWxseSwgaXQncyBub3QgYSBt
YXNzaXZlIHN0ZXAuICBUTFMgMS4yIChEVExTIDEuMg0KPiA+ID4gZGVwZW5kcyBvbiB0aGlzLA0K
PiA+ID4gPiBEVExTIDEuMCBkZXBlbmRzIG9uIFRMUyAxLjEpIGFkZHMgQUVBRCBtb2RlcywgYnV0
IGRvZXNuJ3QNCj4gPiA+ID4gcmVxdWlyZSB0aGVpciB1c2UsIHNvIHlvdSBjYW4gcHJldHR5IG11
Y2gganVzdCBidW1wIHRoZSB2ZXJzaW9uDQo+ID4gPiA+IG51bWJlciBhbmQgYWR2ZXJ0aXNlIDEu
Mi4gIFRoYXQncyBleGFjdGx5IHdoYXQgd2UgZGlkIHdpdGggTlNTLA0KPiA+ID4gPiB0aG91Z2gg
TlNTIGFscmVhZHkgc3VwcG9ydHMgVExTIDEuMi4NCj4gPiA+ID4NCj4gPiA+ID4gVGhhdCBzYWlk
LCBJIGFncmVlIHdpdGggSmltIGFib3V0IDEuMC4gIFRoZXJlJ3MgZW5vdWdoIDEuMA0KPiA+ID4g
b3V0IHRoZXJlDQo+ID4gPiA+IG5vdyB0byBtYWtlIG1hbmRhdGluZyAxLjIgLSBhcyBtdWNoIGFz
IEkgbWlnaHQgcHJlZmVyIHRoYXQNCj4gPiA+IC0gYSBsaXR0bGUNCj4gPiA+ID4gdG9vIGFnZ3Jl
c3NpdmUuDQo+ID4gPiA+DQo+ID4gPiA+PiBXaWxsIHRob3NlIGltcGxlbWVudGF0aW9ucyB0aGF0
IGNob29zZSB0byBzdGF5IHdpdGggMS4wDQo+ID4gPiBzdGlsbCBpbnRlcndvcmsgd2l0aCAxLjI/
DQo+ID4gPiA+IFRoYXQgZGVwZW5kcy4gIFdlIGNvdWxkIHNheSAiTVVTVCBOT1QgbmVnb3RpYXRl
IDEuMCIsIHdoaWNoDQo+ID4gPiA+IHdvdWxkIHByZXZlbnQgdGhhdC4gIEkgZG9uJ3QgdGhpbmsg
dGhhdCB3ZSdyZSB0aGVyZS4NCj4gPiA+DQo+ID4gPiBTb3VuZHMgdG8gbWUgbGlrZSBNVVNUIGlt
cGxlbWVudCAxLjIgKGluIG9yZGVyIHRvIG1vdmUgZm9yd2FyZCksDQo+ID4gPiBNVVNUIGFjY2Vw
dCAxLjAgKGluIG9yZGVyIHRvIG5vdCBsb3NlIHRoZSBsb25nIHRhaWwpLg0KPiA+ID4NCj4gPiA+
ID4NCj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCj4gPiA+ID4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPiA+ID4gPiBydGN3ZWJAaWV0Zi5vcmc8
bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCj4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9ydGN3ZWINCj4gPiA+DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPiA+
ID4gcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQo+ID4gPiBodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPiA+ID4NCj4gPiBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHJ0Y3dlYiBtYWls
aW5nIGxpc3QNCj4gPiBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCj4g
PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPiA+DQo+ID4g
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBydGN3
ZWIgbWFpbGluZyBsaXN0DQo+ID4gcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5v
cmc+DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCj4N
Cj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0
Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3Jn
Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5n
IGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K

--_000_17987d3c6f3c49d8bacfbd613daa75a6BLUPR03MB405namprd03pro_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ
cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246
dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw
bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE
O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np
emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu
V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx
MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz
aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg
Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh
bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT
ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+SeKAmW0gZmluZSB3aXRoIHRoZSBiYXNlbGluZSAoTVVTVCkgcHJv
cG9zZWQgYnkgSnVzdGluLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBjYW4ga2VlcCB0aGUgRUNEU0Egb3B0aW9u
IGFzIGEgcmVjb21tZW5kYXRpb24gKGFzIGFub3RoZXIgU0hPVUxEIG9yIE1BWSkgaWYgc29tZSBp
bXBsZW1lbnRhdGlvbnMgYXJlIGV4cGVjdGVkIHRvIG1vdmUgdG8gaXQgb3ZlciB0aW1lLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5k
Q29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPiBKdXN0aW4gVWJlcnRpIFttYWlsdG86anViZXJ0aUBnb29nbGUuY29tXQ0K
PGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBKdWx5IDE5LCAyMDE0IDg6NTAgUE08YnI+DQo8
Yj5Ubzo8L2I+IFNoaWp1biBTdW48YnI+DQo8Yj5DYzo8L2I+IE1pY2hhZWwgVHVleGVuOyBFcmlj
IFJlc2NvcmxhOyBydGN3ZWJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3
ZWJdIERUTFMgdmVyc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg
d2FzIHRoaW5raW5nIHRoZSBiYXNlbGluZSBjaXBoZXIgc3VpdGUgd291bGQgYmUmbmJzcDs8c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UTFNfRUNESEVfUlNBX1dJVEhfQUVTXzEyOF9DQkNfU0hB
IChub3RlIFJTQSBpbnN0ZWFkIG9mIEVDRFNBKTwvc3Bhbj4sIGFzIHRoZSBiZXN0IGNob2ljZSB0
aGF0IG1haW50YWlucyAxLjAgY29tcGF0aWJpbGl0eS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkmbmJzcDt0aGluayB3ZSBjb3VsZCBhbHNvIGhhdmUgYSBT
SE9VTEQgZm9yIFRMU19FQ0RIRV9SU0FfV0lUSF9BRVNfMTI4X0dDTV9TSEEyNTYgYXMgdGhlIHBy
ZWZlcnJlZCBUTFMgMS4yIGNpcGhlcnN1aXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w
cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u
IE1vbiwgSnVsIDcsIDIwMTQgYXQgNToyOSBQTSwgU2hpanVuIFN1biAmbHQ7PGEgaHJlZj0ibWFp
bHRvOnNoaWp1bnNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNoaWp1bnNAbWljcm9z
b2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g
MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPlRoZXJlIHNlZW1zIGEgcHJlZmVyZW5jZSBvbiBzdXBwb3J0aW5nIERU
TFMgMS4wIGR1ZSB0byB0aGUgd2lkZXNwcmVhZCBhZG9wdGlvbi4gJm5ic3A7VGhlcmUgaXMgYWxz
byBhIGRlc2lyZSBvZiBzdXBwb3J0aW5nIEVDREhFIHdoZW4gRUNDIGlzIG9uIGEgU3RhbmRhcmRz
IFRyYWNrLiAmbmJzcDtIb3BlIHdlIGNvdWxkIHJlYWNoIGEgY29uc2Vuc3VzIGluIFRvcm9udG8u
PGJyPg0KPGJyPg0KVG8ga2VlcCB0aGUgZGlzY3Vzc2lvbnMgZ29pbmcsIGhlcmUgaXMgYSBwcm9w
b3NhbCB3aXRoIGEgc3BlY2lmaWMgY2lwaGVyIHN1aXRlIGJhc2VkIG9uIERUTFMgMS4wLjxicj4N
Cjxicj4NCiZuYnNwOyAmbmJzcDsgQWxsIGltcGxlbWVudGF0aW9ucyBNVVNUIGltcGxlbWVudCB0
aGUgY2lwaGVyIHN1aXRlIFRMU19FQ0RIRV9FQ0RTQV9XSVRIX0FFU18xMjhfQ0JDX1NIQTxicj4N
CiZuYnNwOyAmbmJzcDsgYmFzZWQgb24gRFRMUyAxLjAgd2l0aCBQMjU2IGFzIHRoZSBjdXJ2ZSB0
byBiZSB1c2VkIHdpdGggRUNESEUgYW5kIEVDRFNBLiAmbmJzcDtUaGUgSW1wbGVtZW50YXRpb25z
PGJyPg0KJm5ic3A7ICZuYnNwOyBNQVkgYWR2ZXJ0aXNlIGFkZGl0aW9uYWwgY2lwaGVyIHN1aXRl
cyBiYXNlZCBvbiBEVExTIDEuMCBhbmQvb3IgRFRMUyAxLjIgZGVmaW5pdGlvbnMsIGZvciBleGFt
cGxlLDxicj4NCiZuYnNwOyAmbmJzcDsgVExTX0VDREhFX1JTQV9XSVRIX0FFU18xMjhfQ0JDX1NI
QSB3aXRoIFAyNTYuPGJyPg0KPGJyPg0KV2UgY291bGQga2VlcCBEVExTIDEuMiBhcyBhbiBvcHRp
b25hbCBpbXBsZW1lbnRhdGlvbiBkZWNpc2lvbiBmb3Igbm93IGFuZCBtYWtlIHRoYXQgKGFuZCBz
b21lIGNvcnJlc3BvbmRpbmcgbmV3IGNpcGhlciBzdWl0ZXMpIGFzIHJlcXVpcmVkIGluIHRoZSBm
dXR1cmUuPGJyPg0KPGJyPg0KVGhvdWdodHM/PGJyPg0KPGJyPg0KQmVzdCwgU2hpanVuPG86cD48
L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0
b206MTIuMHB0Ij48YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IHJ0
Y3dlYiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZyI+cnRj
d2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgTWljaGFlbCBUdWV4ZW48YnI+
DQpTZW50OiBGcmlkYXksIEp1bHkgNCwgMjAxNCAyOjI4IFBNPGJyPg0KVG86IEVyaWMgUmVzY29y
bGE8YnI+DQpDYzogPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYu
b3JnPC9hPjxicj4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBEVExTIHZlcnNpb248bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAwNCBK
dWwgMjAxNCwgYXQgMjM6MTksIEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JA
cnRmbS5jb20iPmVrckBydGZtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZndDs8YnI+
DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gRnJpLCBKdWwgNCwgMjAxNCBhdCAyOjExIFBN
LCBNaWNoYWVsIFR1ZXhlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuVHVleGVuQGx1cmNo
aS5mcmFua2VuLmRlIj5NaWNoYWVsLlR1ZXhlbkBsdXJjaGkuZnJhbmtlbi5kZTwvYT4mZ3Q7IHdy
b3RlOjxicj4NCiZndDsgT24gMDQgSnVsIDIwMTQsIGF0IDIxOjQ4LCBFcmljIFJlc2NvcmxhICZs
dDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIj5la3JAcnRmbS5jb208L2E+Jmd0OyB3cm90
ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEkgbWFkZSB0aGlzIGNoYW5nZSBpbiB0aGUgY3Vy
cmVudCBkcmFmdCBhdDo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0iaHR0
cHM6Ly9naXRodWIuY29tL3J0Y3dlYi13Zy9zZWN1cml0eS1hcmNoL2NvbW1pdC9jMmFmMmJmN2Zk
MDMyYWJkMzYiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZ2l0aHViLmNvbS9ydGN3ZWItd2cv
c2VjdXJpdHktYXJjaC9jb21taXQvYzJhZjJiZjdmZDAzMmFiZDM2PC9hPjxicj4NCiZndDsgJmd0
OyA3ZGZmOGQ0ZDE2ZjdlYzQzNWZhNjYzPGJyPg0KJmd0OyBJZiBpbXBsZW1lbnRhdGlvbnMgTVVT
VCBpbXBsZW1lbnQgYm90aCBEVExTIDEuMCBhbmQgMS4yLCB3aGVuIHdpbGw8YnI+DQomZ3Q7IHRo
ZXkgdXNlIDEuMD8gV291bGRuJ3QgdGhleSBhbHdheXMgdXNlIERUTFMgMS4yPzxicj4NCiZndDs8
YnI+DQomZ3Q7IFRoZXJlIGFyZSBub24tUlRDV0VCIGltcGxlbWVudGF0aW9ucyBvZiB0aGVzZSBw
cm90b2NvbHMuPGJyPg0KT0suIEFueSBzdWdnZXN0ZWQgdGVzdCBmb3IgdGhlIFNDVFAgb3ZlciBE
VExTIHNwZWM/IEl0IGN1cnJlbnRseSBzYXlzIE1VU1QgYmUgYmFzZWQgb24gRFRMUyAxLjAgKGFz
IHlvdSBzdWdnZXN0ZWQpLjxicj4NCjxicj4NCkJlc3QgcmVnYXJkczxicj4NCk1pY2hhZWw8YnI+
DQomZ3Q7PGJyPg0KJmd0OyAtRWtyPGJyPg0KJmd0Ozxicj4NCiZndDsgQmVzdCByZWdhcmRzPGJy
Pg0KJmd0OyBNaWNoYWVsPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE5vdGUgdGhhdCB0
aGUgVExTIFdHIGlzIGN1cnJlbnRseSBkaXNjdXNzaW5nIHdoZXRoZXIgdG8gYnJpbmcgRUNDIG9u
dG8gU3RhbmRhcmRzIFRyYWNrLjxicj4NCiZndDsgJmd0OyBJZiB0aGV5IGRvLCB3ZSBwcm9iYWJs
eSB3YW50IG90IHJlcXVpcmUgc3VwcG9ydCBvZiBFQ0RIRS4gV2Ugc2hvdWxkIGRpc2N1c3MgaW4g
WVlaLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZn
dDsgJmd0OyBPbiBGcmksIEp1bCA0LCAyMDE0IGF0IDM6MjMgQU0sIERSQUdFLCBLZWl0aCAoS2Vp
dGgpICZsdDs8YSBocmVmPSJtYWlsdG86a2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tIj5r
ZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZn
dDsgVGhpcyBpcyB0aGUgZGlyZWN0aW9uIEkgYW0gdGVuZGluZyBpbiBhcyB3ZWxsLjxicj4NCiZn
dDsgJmd0Ozxicj4NCiZndDsgJmd0OyBBbHRob3VnaCB3aGF0IG9yIGlmIHRoZSBzZWNvbmQgc3Rh
dGVtZW50IG5lZWRzIGZyb20gUkZDIDIxMTkgbGFuZ3VhZ2Ugd291bGQgbmVlZCB0byBiZSBkZWJh
dGVkLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBPYnZpb3VzbHksIG5ldyB2ZXJzaW9u
cyBhcmUgbm90IGJlaW5nIHB1dCBvdXQgdGhlcmUganVzdCB0byBtYWtlIGl0IGxvb2sgbGlrZSB0
aGUgV0cgaXMgcGVyZm9ybWluZy4gSW4gYW55IHJlZmVyZW5jaW5nIChub3QganVzdCB0aGlzIGlz
c3VlKSwgSSB3b3VsZCBuZWVkIGEgZ29vZCB0ZWNobmljYWwgcmVhc29uIHdoeSB0aGUgbGF0ZXN0
IHZlcnNpb24gY2Fubm90IGJlIG1hZGUgdGhlIG5vcm1hdGl2ZSByZWZlcmVuY2UuIEkgYW0gbm90
IHNlZWluZw0KIHRoYXQgYXQgdGhlIG1vbWVudC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn
dDsgVGhlcmUgaXMgYWx3YXlzIGJlIG5vbi1jb25mb3JtaW5nIGVxdWlwbWVudCBvbiB0aGUgbWFy
a2V0IChhcyBhbiBleGFtcGxlIGxvb2sgYXQgdGhlIG51bWJlciBvZiBTSVAgaW1wbGVtZW50YXRp
b25zIHRoYXQgc3RpbGwgdXNlIFVEUCBmb3IgbGFyZ2UgbWVzc2FnZXMsIG9yIHRoYXQgY2FuIGF0
IGxlYXN0IGJlIGNvbmZpZ3VyZWQgdGhhdCB3YXkpLiBKdXN0IGJlY2F1c2Ugd2UgbWFuZGF0ZSAx
LjIgZG9lcyBub3QgbWVhbiB0aGF0IGV2ZXJ5b25lDQogd2lsbCBjb25mb3JtIGZyb20gZGF5IDEs
IGJ1dCBhdCBsZWFzdCBhIG1hcmtlciBpcyBlc3RhYmxpc2hlZCBmb3Igd2hhdCBzaG91bGQgYmUg
YWRkcmVzc2VkIGlmIGludGVyb3BlcmFiaWxpdHkgaXNzdWVzIGFyZSBpZGVudGlmaWVkLjxicj4N
CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBLZWl0aDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg
Jmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
RnJvbTogcnRjd2ViIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYu
b3JnIj5ydGN3ZWItYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBIYXJhbGQ8YnI+
DQomZ3Q7ICZndDsgJmd0OyBBbHZlc3RyYW5kPGJyPg0KJmd0OyAmZ3Q7ICZndDsgU2VudDogMDQg
SnVseSAyMDE0IDA5OjA3PGJyPg0KJmd0OyAmZ3Q7ICZndDsgVG86IDxhIGhyZWY9Im1haWx0bzpy
dGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyBT
dWJqZWN0OiBSZTogW3J0Y3dlYl0gRFRMUyB2ZXJzaW9uPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+
DQomZ3Q7ICZndDsgJmd0OyBPbiAwNy8wMy8yMDE0IDA3OjU4IFBNLCBNYXJ0aW4gVGhvbXNvbiB3
cm90ZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IE9uIDMgSnVseSAyMDE0IDAxOjM5LCBEUkFH
RSwgS2VpdGggKEtlaXRoKTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmx0OzxhIGhyZWY9Im1h
aWx0bzprZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb20iPmtlaXRoLmRyYWdlQGFsY2F0ZWwt
bHVjZW50LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IENh
biBzb21lb25lIGVsYWJvcmF0ZSB3aGF0IHRoaXMgbWFzc2l2ZSBhcHBhcmVudCBzdGVwPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgY2hhbmdlIGlzIGZyb20gMS4wIHRvIDEuMj88YnI+DQomZ3Q7ICZndDsg
Jmd0OyAmZ3Q7IEFjdHVhbGx5LCBpdCdzIG5vdCBhIG1hc3NpdmUgc3RlcC4gJm5ic3A7VExTIDEu
MiAoRFRMUyAxLjI8YnI+DQomZ3Q7ICZndDsgJmd0OyBkZXBlbmRzIG9uIHRoaXMsPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgJmd0OyBEVExTIDEuMCBkZXBlbmRzIG9uIFRMUyAxLjEpIGFkZHMgQUVBRCBt
b2RlcywgYnV0IGRvZXNuJ3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHJlcXVpcmUgdGhlaXIg
dXNlLCBzbyB5b3UgY2FuIHByZXR0eSBtdWNoIGp1c3QgYnVtcCB0aGUgdmVyc2lvbjxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsgbnVtYmVyIGFuZCBhZHZlcnRpc2UgMS4yLiAmbmJzcDtUaGF0J3Mg
ZXhhY3RseSB3aGF0IHdlIGRpZCB3aXRoIE5TUyw8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRo
b3VnaCBOU1MgYWxyZWFkeSBzdXBwb3J0cyBUTFMgMS4yLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoYXQgc2FpZCwgSSBhZ3JlZSB3aXRoIEppbSBh
Ym91dCAxLjAuICZuYnNwO1RoZXJlJ3MgZW5vdWdoIDEuMDxicj4NCiZndDsgJmd0OyAmZ3Q7IG91
dCB0aGVyZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgbm93IHRvIG1ha2UgbWFuZGF0aW5nIDEu
MiAtIGFzIG11Y2ggYXMgSSBtaWdodCBwcmVmZXIgdGhhdDxicj4NCiZndDsgJmd0OyAmZ3Q7IC0g
YSBsaXR0bGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRvbyBhZ2dyZXNzaXZlLjxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBXaWxsIHRob3Nl
IGltcGxlbWVudGF0aW9ucyB0aGF0IGNob29zZSB0byBzdGF5IHdpdGggMS4wPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgc3RpbGwgaW50ZXJ3b3JrIHdpdGggMS4yPzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsgVGhhdCBkZXBlbmRzLiAmbmJzcDtXZSBjb3VsZCBzYXkgJnF1b3Q7TVVTVCBOT1QgbmVnb3Rp
YXRlIDEuMCZxdW90Oywgd2hpY2g8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHdvdWxkIHByZXZl
bnQgdGhhdC4gJm5ic3A7SSBkb24ndCB0aGluayB0aGF0IHdlJ3JlIHRoZXJlLjxicj4NCiZndDsg
Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgU291bmRzIHRvIG1lIGxpa2UgTVVTVCBpbXBs
ZW1lbnQgMS4yIChpbiBvcmRlciB0byBtb3ZlIGZvcndhcmQpLDxicj4NCiZndDsgJmd0OyAmZ3Q7
IE1VU1QgYWNjZXB0IDEuMCAoaW4gb3JkZXIgdG8gbm90IGxvc2UgdGhlIGxvbmcgdGFpbCkuPGJy
Pg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCiZndDsg
Jmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGll
dGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48YnI+DQomZ3Q7ICZndDsg
Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcnRjd2ViIG1haWxpbmcgbGlzdDxi
cj4NCiZndDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dl
YkBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxicj4NCiZndDsgJmd0OyAm
Z3Q7PGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IHJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZn
dDsgPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxi
cj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vcnRjd2ViPC9hPjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyBy
dGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJA
aWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0iaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5r
Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48YnI+DQom
Z3Q7PGJyPg0KJmd0Ozxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPGJyPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h
aWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxh
bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxicj4N
Cjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy
Pg0KcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5v
cmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_17987d3c6f3c49d8bacfbd613daa75a6BLUPR03MB405namprd03pro_--


From nobody Sun Jul 20 10:10:10 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37841B289E for ; Sun, 20 Jul 2014 10:10:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.13
X-Spam-Level: 
X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77] autolearn=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 ED3HEzlKf2_I for ; Sun, 20 Jul 2014 10:10:06 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A257D1A8BB4 for ; Sun, 20 Jul 2014 10:10:06 -0700 (PDT)
Received: from [207.236.147.203] (port=62251 helo=[10.255.253.157]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1X8uce-00052Q-La for rtcweb@ietf.org; Sun, 20 Jul 2014 18:10:05 +0100
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Colin Perkins 
In-Reply-To: <20140704195354.9574.18912.idtracker@ietfa.amsl.com>
Date: Sun, 20 Jul 2014 13:10:01 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20140704195354.9574.18912.idtracker@ietfa.amsl.com>
To: rtcweb@ietf.org
X-Mailer: Apple Mail (2.1878.6)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold =  On = 
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/e6TsenOZVf9GhkJMpLjD6pYCF54
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-security-arch-10.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Jul 2014 17:10:08 -0000

On 4 Jul 2014, at 15:53, Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the Real-Time Communication in =
WEB-browsers Working Group of the IETF.
>=20
>        Title           : WebRTC Security Architecture
>        Author          : Eric Rescorla
> 	Filename        : draft-ietf-rtcweb-security-arch-10.txt
> 	Pages           : 45
> 	Date            : 2014-07-04
>=20
> Abstract:
>   The Real-Time Communications on the Web (RTCWEB) working group is
>   tasked with standardizing protocols for enabling real-time
>   communications within user-agents using web technologies (commonly
>   called "WebRTC").  This document defines the security architecture
>   for WebRTC.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/

One minor point, to avoid potential confusion due to acronym clash, I =
suggest changing =93WebRTC implementations MUST NOT offer SDES or select =
it if offered=94 in Section 5.5 to =93=85MUST NOT offer SDP Security =
Descriptions [RFC=85] or select=85=94

Cheers,
Colin




--=20
Colin Perkins
http://csperkins.org/




From nobody Sun Jul 20 19:35:43 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58881B2AD6 for ; Sun, 20 Jul 2014 19:35:41 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -5.184
X-Spam-Level: 
X-Spam-Status: No, score=-5.184 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cl0tWkXUBLbE for ; Sun, 20 Jul 2014 19:35:39 -0700 (PDT)
Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981041B2ACE for ; Sun, 20 Jul 2014 19:35:38 -0700 (PDT)
Received: from epcpsbgr3.samsung.com (u143.gpu120.samsung.co.kr [203.254.230.143]) by mailout2.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N91003QPJ7DW390@mailout2.samsung.com> for rtcweb@ietf.org; Mon, 21 Jul 2014 11:35:37 +0900 (KST)
Received: from epcpsbgx1.samsung.com ( [172.20.52.123]) by epcpsbgr3.samsung.com (EPCPMTA) with SMTP id 73.AE.14704.87C7CC35; Mon, 21 Jul 2014 11:35:37 +0900 (KST)
X-AuditID: cbfee68f-b7fef6d000003970-ce-53cc7c7859b9
Received: from epmailer01 ( [203.254.219.141]) by epcpsbgx1.samsung.com (EPCPMTA) with SMTP id DE.EF.03708.D5C7CC35; Mon, 21 Jul 2014 11:35:09 +0900 (KST)
Message-id: 
Date: Mon, 21 Jul 2014 02:35:09 +0000 (GMT)
From: Kiran Kumar Guduru 
To: Paul Kyzivat , "rtcweb-request@ietf.org" , "rtcweb@ietf.org" 
MIME-version: 1.0
X-MTR: 20140721023444958@kiran.guduru
Msgkey: 20140721023444958@kiran.guduru
X-EPLocale: en_US.windows-1252
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20140721023444958@kiran.guduru
X-ParentMTR: 
X-ArchiveUser: 
X-CPGSPASS: N
MIME-version: 1.0
Content-type: multipart/related; boundary="=_NamoWEC-qrem077x8a"
X-Generator: Namo ActiveSquare 7 7.0.0.45
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBKsWRmVeSWpSXmKPExsWyRsSkWrey5kywwZyNjBZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY9eyfawFl2YxVfz/GtbA2D+ZqYuRk0NIQF1iw+p7bCC2hICJ xJODX1khbDGJC/fWA8W5gGqWMkpsvNXKAlM08eMhFojEHEaJ/d96mUESvAIWEo/+HAcrYhFQ lTi/cRFYnA2o4deJNYwgtrCArcS7g/fYQZpFBDoYJWY13mSFOENJYu1VCJtXQFDi5MwnQIM4 gLapSrx84wsRVpO40HGXHeIIOYklUy8zQdi8EjPan7LAxKd9XcMMYUtLnJ+1gRHmm8XfH0PF +SWO3d7BBDGeV+LJ/WCYMbs3f4EGhIDE1DMHoVq1JG6cmgMNFD6JNQvfssCM2XVqOTNM7/0t c5lQXc/JwSzgJLF50g+oGk2JR4taweEmIXCEQ+L+ucNsExiVZiHpQWfD9EPYhhJf5j1mhLAV JaZ0P2SfBfQCs4CdRN9VJVRhEFtV4sqRa8wLGDlWMYqmFiQXFCelFxnrFSfmFpfmpesl5+du YgQmn9P/nvXvYLx7wPoQYxUw2iYyS4km5wOTV15JvKGxmZGFqYmpsZG5pRlVhJXEee8/TAoS EkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwFj8/+zMKmMnZf2ViVE/nTU3SU566LCOY9OeaZk+ 99Z9kb2kVzXnXsUvl75l5Xy1ObPfqsS/jBAsK3o5nXXlrMU9azfob9JoeWa9yEH3z7M4o1+v dhWmuByz8E0w1w2q7rQ4lzLZeOobL6eaTxxsIav4zv3+pH7mar4am7Sw6uz8ynsfFfxu6Sux FGckGmoxFxUnAgC8GJntawMAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCJsWRmVeSWpSXmKPExsVy+t/tXt3smjPBBlv2CVis/dfO7sDosWTJ T6YAxqg0m4zUxJTUIoXUvOT8lMy8dFsl7+B453hTMwNDXUNLC3MlhbzE3FRbJRefAF23zByg qUoKZYk5pUChgMTiYiV9O5ui/NKSVIWM/OISW6VoQ3MjPSMDPVMjPUPTWCtDAwMjU6CahLSM Xcv2sRZcmsVU8f9rWANj/2SmLkZODiEBdYkNq++xgdgSAiYSEz8eYoGwxSQu3FsPFOcCqpnD KLH/Wy8zSIJFQFXi/MZFYDYbUMOvE2sYQWxhAVuJdwfvsYM0iAh0MErMarzJCrFBSWLtVQib V0BQ4uTMJ0AbOIA2qEq8fOMLEVaTuNBxlx1isZzEkqmXmSBsXokZ7U9ZYOLTvq5hhrClJc7P 2sAIc+ji74+h4vwSx27vYIIYzyvx5H4wzJjdm79A/SggMfXMQahWLYkbp+awQth8EmsWvmWB GbPr1HJmmN77W+Yyobqek4NZwEli86QfUDWaEo8WtbJMYJSZhaQMnQ3TAmEbSnyZ95gRwlaU mNL9kH0W0NXMAnYSfVeVUIVBbFWJK0euMS9g5FjFKJpakFxQnJReYahXnJhbXJqXrpecn7uJ EZzQni3cwfjlvPUhRgEORiUe3gXMZ4KFWBPLiitzDzGqAM15tGH1BUYplrz8vFQlEd4TGUBp 3pTEyqrUovz4otKc1OJDjBMZgZE8kVlKNDkfmIbzSuINjU3MTY1NLQwMzc3NaCmsJM5792ZS kJBAemJJanZqakFqEcxRTBycUg2Mm2br6dSYaLRxzm5bwS8s9PrOhF0i/Pu+NoT//KdZxhy7 cdfJaqNnHFZ+XHFNfS12zy6v70i/tO+lsvd+8fSyH4aN7xY6XBXZscD3zu7nxvkzSx5d3fDb VWLD7VMn/kUkbFq+qrNL83aS97cZZ6Z8+Hh0lcLjL53NEcFL7tre2TBjXXJ60jIpWSWW4oxE Qy3mouJEAODx62jnAwAA
DLP-Filter: Pass
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qnnAjQMRSrZfKdkQkRX_46Z8ojo
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: kiran.guduru@samsung.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: Mon, 21 Jul 2014 02:35:42 -0000

--=_NamoWEC-qrem077x8a
Content-Type: text/html;
	charset="windows-1252"
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PHRpdGxlPlNhbXN1bmcgRW50ZXJwcmlzZSBQb3J0YWwgbXlTaW5nbGU8L3Rp
dGxlPgo8bWV0YSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9d2luZG93cy0xMjUyIiBodHRw
LWVxdWl2PSJDb250ZW50LVR5cGUiPgo8c3R5bGUgaWQ9Im15c2luZ2xlX3N0eWxlIiB0eXBlPSJ0
ZXh0L2NzcyI+UCB7CglNQVJHSU4tVE9QOiA1cHg7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJpYWw7
IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiA5cHQKfQpURCB7CglNQVJHSU4tVE9QOiA1
cHg7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJpYWw7IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1T
SVpFOiA5cHQKfQpMSSB7CglNQVJHSU4tVE9QOiA1cHg7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJp
YWw7IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiA5cHQKfQpCT0RZIHsKCUxJTkUtSEVJ
R0hUOiAxLjQ7IE1BUkdJTjogMTBweDsgRk9OVC1GQU1JTFk6IEFyaWFsLCBhcmlhbDsgRk9OVC1T
SVpFOiA5cHQKfQo8L3N0eWxlPgoKPG1ldGEgbmFtZT0iR0VORVJBVE9SIiBjb250ZW50PSJBY3Rp
dmVTcXVhcmUiPgo8L2hlYWQ+PGJvZHk+CjxwPkl0IHNlZW1zIHRoZXJlIGlzIGEgc21hbGwgbWlz
LXVuZGVyc3RhbmRpbmcgaGVyZS4gSSBhZ3JlZSB0aGVyZSBpcyBhIG5lZWQgZm9yIHBhcnNpbmcg
YW5kIGVkaXRpbmcgU0RQIGJ5IEpTIGFwcGxpY2F0aW9uIGZvciBub3cuPC9wPgo8cD5JIGFtIG5v
dCBzYXlpbmcgdGhhdCBjb25zdHJhaW50cyB3aWxsIGRvIGV2ZXJ5dGhpbmcuPC9wPgo8cD5NeSBp
bnRlbnRpb24gaXMsIHRvIGZpbmQgdGhlIHBvc3NpYmlsaXRpZXMgdG8gZXh0ZW5kIHRoZSBBUEkg
b2YgZXhpc3RpbmcgUlRDUGVlckNvbm5lY3Rpb24gYW5kIHByb3Bvc2VkIFJUQ1JUUFNlbmRlci9S
ZWNlaXZlciB0byBhZGQgdGhlIGF0dHJpYnV0ZXMgcmVxdWlyZWQgYnkgSlMgYXBwbGljYXRpb24u
PC9wPgo8cD5Gb3Igbm93LCBJIHByb3Bvc2VkIHNvbHV0aW9uIGZvciBvbmUgc3VjaCBraW5kIG9m
IHByb2JsZW0sIGkuZS4sIHByaW9yaXRpemluZyBjb2RlY3MuPC9wPgo8cD5zZXRTZFBBdHRyaWJ1
dGUgKGtleSwgdmFsdWUpIGlzIGp1c3QgYW4gZXhhbXBsZSBvbiB0b3Agb2YgbXkgaGVhZCwgd2hp
Y2ggbWlnaHQgc29sdmUgdGhpcy4gQnV0IHdlIGNhbiByZWFsbHkgZmlndXJlIG91dCB0aGlzIGFm
dGVyIGdldHRpbmcgdGhlIHByb3Bvc2VkIEFQSSAoUlRDUlRQU2VuZGVyL1JlY2VpdmVyICkgaW4g
ZHJhZnQuPC9wPgo8cD48L3A+CjxwPlJlZ2FyZHMsPC9wPgo8cD5LaXJhbjwvcD4KPHA+Jm5ic3A7
PC9wPgo8cD4tLS0tLS0tIDxiPk9yaWdpbmFsIE1lc3NhZ2U8L2I+IC0tLS0tLS08L3A+CjxwPjxi
PlNlbmRlcjwvYj4gOiBQYXVsIEt5eml2YXQmbHQ7cGt5eml2YXRAYWx1bS5taXQuZWR1Jmd0Ozwv
cD4KPHA+PGI+RGF0ZTwvYj4gOiBKdWwgMTksIDIwMTQgMjI6MzUgKEdNVCswOTowMCk8L3A+Cjxw
PjxiPlRpdGxlPC9iPiA6IFJlOiBbcnRjd2ViXSBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1ydGN3ZWIt
anNlcC0wNzwvcD4KPHA+Jm5ic3A7PC9wPktpcmFuLDxicj48YnI+TXkgbmVlZCB3b24ndCBiZSBz
YXRpc2ZpZWQgYnkgcGxhdXNpYmxlIGNvbnN0cmFpbnRzLjxicj5Gb3IgaW5zdGFuY2UsIHRvIGlu
dGVyd29yayB3aXRoIENMVUUgaXQgd2lsbCBiZSBuZWNlc3NhcnkgdG8gYWRkIGFuIDxicj4iYT1n
cm91cDpjbHVlIiBhbmQgaW5jbHVkZSBpbiBpdCB0aG9zZSBtLWxpbmVzIHRoYXQgYXJlIHRvIGJl
ICJjbHVlIDxicj5jb250cm9sbGVkIi4gQW5kIHRoYXQgaXMgbmVlZGVkIGluIGJvdGggb2ZmZXIg
YW5kIGFuc3dlciBwcm9jZXNzaW5nLjxicj48YnI+VGhhbmtzLDxicj5QYXVsPGJyPjxicj5PbiA3
LzE4LzE0IDEwOjQxIFBNLCBLaXJhbiBLdW1hciBHdWR1cnUgd3JvdGU6PGJyPiZndDsgRGVhciBQ
YXVsLDxicj4mZ3Q7PGJyPiZndDsgTXkgY29tbWVudCBpcyBvbmx5IHJlZ2FyZGluZyB0aGUgY29t
bWVudHMgb24gc2VjdGlvbiA2IG9mIHRoZSBKU0VQIGRyYWZ0Ljxicj4mZ3Q7PGJyPiZndDsgVGhl
IHNkcCBtYW5nbGluZyBkZXNjcmliZWQgaW4gc2VjdGlvbiA2IG1heSByZXN1bHQgaW4gdmFyaW91
cyBlcnJvcjxicj4mZ3Q7IHNjZW5hcmlvcy48YnI+Jmd0Ozxicj4mZ3Q7IEluIHRoYXQgc2VjdGlv
biwgaXQgaXMgZGVzY3JpYmVkIGxpa2UgbW9zdCBvZiB0aGUgcGFyYW1ldGVycyBjYW4gYmU8YnI+
Jmd0OyBtb2RpZmllZCB0aG9ydWdoIGNvbnN0cmFpbnRzLjxicj4mZ3Q7PGJyPiZndDsgVGhlIHJl
cXVpcmVkIG1vZGlmaWNhdGlvbiwgSSBmb3VuZCwgd2hpY2ggY2Fubm90IG5vdCBiZSBkb25lIGJ5
IHRoZTxicj4mZ3Q7IGNvbnN0cmFpbnRzIGlzICJSZW1vdmUgb3IgcmVvcmRlciBvZiBjb2RlY3Mg
KG09KSI8YnI+Jmd0Ozxicj4mZ3Q7IEluIG9yZGVyIHRvIGF2b2lkIHRoZSBTRFAgbWFuZ2xpbmcg
YXQgSmF2YSBTY3JpcHQgYXBwbGljYXRpb24gbGV2ZWwsIEk8YnI+Jmd0OyBzdWJtaXR0ZWQgYSBk
cmFmdCBmb3IgY2hhbmdpbmcgdGhlIGNvZGVjIHByZWZlcmVuY2VzPGJyPiZndDsgaHR0cDovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ3VkdXJ1LXJ0Y3dlYi1jb2RlYy1wcmVmZXJlbmNlcy0w
MS48YnI+Jmd0OyAoUGxlYXNlIHJldmlldyBpdCkuPGJyPiZndDs8YnI+Jmd0OyBJZiB0aGlzIHBy
b3Bvc2FsIGlzIGFjY2VwdGFibGUgdG8gdGhlIGdyb3VwLCBJIGhvcGUgd2UgY2FuIHJlbW92ZTxi
cj4mZ3Q7IHNlY3Rpb24gNiBmcm9tIEpTRVAgZHJhZnQuPGJyPiZndDs8YnI+Jmd0OyAoRXhwZWN0
aW5nIHRoYXQgd2UgY2FuIGZpbmQgYWx0ZXJuYXRpdmVzIGZvciBhZGRpbmcgZXh0cmEgYXR0cmli
dXRlczxicj4mZ3Q7IGxpa2UgQ0xVRSBhcyBpZGVudGlmaWVkIGJ5IHlvdSwgZm9yIGV4YW1wbGUg
YnkgZXh0ZW5kaW5nIHRoZTxicj4mZ3Q7IHByb3Bvc2VkIFJUQ1JUUFNlbmRlci9SZWNlaXZlciBi
eSBhZGRpbmcgYSBnZW5lcmljIHNldFNkUEF0dHJpYnV0ZSAoa2V5LDxicj4mZ3Q7IHZhbHVlKSBt
ZXRob2QpLjxicj4mZ3Q7PGJyPiZndDsgVGhhbmtzLDxicj4mZ3Q7PGJyPiZndDsgS2lyYW4uPGJy
PiZndDs8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDsgLS0tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LS0tLTxicj4mZ3Q7IFNlbnQ6IFBhdWwgS3l6aXZhdDxicj4mZ3Q7IERhdGU6IEZyaSwgMTggSnVs
IDIwMTQgMTQ6MzI6MjQgLTA0MDA8YnI+Jmd0OyBTdWJqZWN0OiBbcnRjd2ViXSBSZXZpZXcgb2Yg
ZHJhZnQtaWV0Zi1ydGN3ZWItanNlcC0wNzxicj4mZ3Q7PGJyPiZndDsgSSBqdXN0IGRpZCBteSBm
aXJzdCB0aG9yb3VnaCByZWFkLXRocm91Z2ggb2YgSlNFUCBpbiBxdWl0ZSBzb21lIHRpbWUuIEk8
YnI+Jmd0OyBjYW1lIGF3YXkgd2l0aCBhIG51bWJlciBvZiBjb25jZXJuczo8YnI+Jmd0Ozxicj4m
Z3Q7IFNlY3Rpb24gMS4xOjxicj4mZ3Q7PGJyPiZndDsgV2hlbiBkZXNjcmliaW5nIG9mZmVycywg
bW9kaWZpY2F0aW9uIGJ5IHRoZSBhcHBsaWNhdGlvbiBpcyBtZW50aW9uZWQ6PGJyPiZndDs8YnI+
Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0pTRVAncyBoYW5kbGluZyBv
ZiBzZXNzaW9uIGRlc2NyaXB0aW9ucyBpcyBzaW1wbGUgYW5kPGJyPiZndDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzdHJhaWdodGZvcndhcmQuJm5ic3A7Jm5ic3A7V2hlbmV2
ZXIgYW4gb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlIGlzIG5lZWRlZCwgdGhlPGJyPiZndDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtpbml0aWF0aW5nIHNpZGUgY3JlYXRlcyBhbiBv
ZmZlciBieSBjYWxsaW5nIGEgY3JlYXRlT2ZmZXIoKSBBUEkuJm5ic3A7Jm5ic3A7VGhlPGJyPiZn
dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthcHBsaWNhdGlvbiAqb3B0aW9u
YWxseSBtb2RpZmllcyB0aGF0IG9mZmVyKiwgYW5kIHRoZW4gdXNlcyBpdCB0byBzZXQ8YnI+Jmd0
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3VwIGl0cyBsb2NhbCBjb25maWcg
dmlhIHRoZSBzZXRMb2NhbERlc2NyaXB0aW9uKCkgQVBJLjxicj4mZ3Q7PGJyPiZndDsgYnV0IHdo
ZW4gZGVzY3JpYmluZyBhbnN3ZXJzIGl0IGlzIG5vdDo8YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7V2hlbiB0aGUgY2FsbCBpcyBhY2NlcHRlZCwgdGhl
IGNhbGxlZSB1c2VzIHRoZSBjcmVhdGVBbnN3ZXIoKSBBUEkgdG88YnI+Jmd0OyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2dlbmVyYXRlIGFuIGFwcHJvcHJpYXRlIGFuc3dlciwg
YXBwbGllcyBpdCB1c2luZzxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7c2V0TG9jYWxEZXNjcmlwdGlvbigpLCBhbmQgc2VuZHMgdGhlIGFuc3dlciBiYWNrIHRvIHRo
ZSBpbml0aWF0b3I8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO292
ZXIgdGhlIHNpZ25hbGluZyBjaGFubmVsLiZuYnNwOyZuYnNwO1doZW4gdGhlIG9mZmVyZXIgZ2V0
cyB0aGF0IGFuc3dlciwgaXQ8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwO2luc3RhbGxzIGl0IHVzaW5nIHNldFJlbW90ZURlc2NyaXB0aW9uKCksIGFuZCBpbml0aWFs
IHNldHVwIGlzPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjb21w
bGV0ZS48YnI+Jmd0Ozxicj4mZ3Q7IEFuZCBTZWN0aW9uIDYgb25seSB0YWxrcyBhYm91dCBjaGFu
Z2luZyBvZmZlcnMsIG5vdCBhbnN3ZXJzLiBJdCBpczxicj4mZ3Q7IGVxdWFsbHkgaW1wb3J0YW50
IHRvIGJlIGFibGUgdG8gbW9kaWZ5IGFuc3dlcnMuIChNb3JlIG9uIHRoaXMgaW4gbGF0ZXI8YnI+
Jmd0OyBjb21tZW50IG9uIHNlY3Rpb24gNi4pPGJyPiZndDs8YnI+Jmd0OyBTZWN0aW9uIDQuMS40
Ojxicj4mZ3Q7PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGUg
b25seSBkaWZmZXJlbmNlIGJldHdlZW4gYSBwcm92aXNpb25hbCBhbmQgZmluYWwgYW5zd2VyIGlz
IHRoYXQ8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3RoZSBmaW5h
bCBhbnN3ZXIgcmVzdWx0cyBpbiB0aGUgZnJlZWluZyBvZiBhbnkgdW51c2VkIHJlc291cmNlcyB0
aGF0PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt3ZXJlIGFsbG9j
YXRlZCBhcyBhIHJlc3VsdCBvZiB0aGUgb2ZmZXIuJm5ic3A7Jm5ic3A7QXMgc3VjaCwgdGhlIGFw
cGxpY2F0aW9uPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjYW4g
dXNlIHNvbWUgZGlzY3JldGlvbiBvbiB3aGV0aGVyIGFuIGFuc3dlciBzaG91bGQgYmUgYXBwbGll
ZCBhczxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cHJvdmlzaW9u
YWwgb3IgZmluYWwsIGFuZCBjYW4gY2hhbmdlIHRoZSB0eXBlIG9mIHRoZSBzZXNzaW9uPGJyPiZn
dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtkZXNjcmlwdGlvbiBhcyBuZWVk
ZWQuJm5ic3A7Jm5ic3A7Rm9yIGV4YW1wbGUsIGluIGEgc2VyaWFsIGZvcmtpbmcgc2NlbmFyaW8s
IGFuPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthcHBsaWNhdGlv
biBtYXkgcmVjZWl2ZSBtdWx0aXBsZSAiZmluYWwiIGFuc3dlcnMsIG9uZSBmcm9tIGVhY2g8YnI+
Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3JlbW90ZSBlbmRwb2ludC4m
bmJzcDsmbmJzcDtUaGUgYXBwbGljYXRpb24gY291bGQgY2hvb3NlIHRvIGFjY2VwdCB0aGUgaW5p
dGlhbDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YW5zd2VycyBh
cyBwcm92aXNpb25hbCBhbnN3ZXJzLCBhbmQgb25seSBhcHBseSBhbiBhbnN3ZXIgYXMgZmluYWw8
YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3doZW4gaXQgcmVjZWl2
ZXMgb25lIHRoYXQgbWVldHMgaXRzIGNyaXRlcmlhIChlLmcuIGEgbGl2ZSB1c2VyPGJyPiZndDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtpbnN0ZWFkIG9mIHZvaWNlbWFpbCku
PGJyPiZndDs8YnI+Jmd0OyBJc3N1ZTogaW4gdGhpcyBmb3JraW5nIGNhc2UsIHVudGlsIHRoZSBm
aW5hbCBzZWxlY3Rpb24gaXMgbWFkZSBpdCBpczxicj4mZ3Q7IHVuY2xlYXIgd2hpY2ggb25lIHdp
bGwgbmVlZCBJQ0UgY29tcGxldGVkLiBPbmx5IHdoZW4gYSBzZXRsb2NhbCBpcyBkb25lPGJyPiZn
dDsgb24gb25lIG9mIHRoZSBhbnN3ZXJzIHdpbGwgSUNFIGJlZ2luIHRvIGJlIHBlcmZvcm1lZC4g
VGhlbiwgaWYgYW5vdGhlcjxicj4mZ3Q7IGFuc3dlciBpcyBwcm92aXNpb25hbGx5IHNldCwgd29u
J3QgdGhhdCBzdG9wIElDRSBmb3IgdGhlIHByaW9yIG9uZT8gQW5kPGJyPiZndDsgd29uJ3QgaXQg
cmVxdWlyZSBuZXcgY2FuZGlkYXRlcz8gV2hhdCBpZiBvbmUgb2YgdGhlIGVhcmxpZXIgb25lcyBp
czxicj4mZ3Q7IGV2ZW50dWFsbHkgY2hvc2VuIGFzIGZpbmFsPzxicj4mZ3Q7PGJyPiZndDsgQW5k
IHdoYXQgaWYgSUNFIGNvbXBsZXRlcyBmb3Igb25lIG9mIHRoZSBjYW5kaWRhdGVzPyBDYW4ndCBt
ZWRpYSBzdGFydDxicj4mZ3Q7IHRvIGZsb3c/IFRoZW4gd2hhdCBpZiBhIGRpZmZlcmVudCBjYW5k
aWRhdGUgaXMgc2V0IGFzIHRoZSBmaW5hbCBhbnN3ZXI/PGJyPiZndDs8YnI+Jmd0OyBTZWN0aW9u
IDQuMS40LjE6PGJyPiZndDs8YnI+Jmd0OyBJIHF1ZXN0aW9uIHRoZSBmb2xsb3dpbmc6PGJyPiZn
dDs8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy4uLiZuYnNwOyZu
YnNwO1doaWxlIGl0IGlzIGdvb2QgcHJhY3RpY2UgdG8gc2VuZCBhbiBpbW1lZGlhdGU8YnI+Jmd0
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3Jlc3BvbnNlIHRvIGFuICJvZmZl
ciIsIGluIG9yZGVyIHRvIHdhcm0gdXAgdGhlIHNlc3Npb24gdHJhbnNwb3J0IGFuZDxicj4mZ3Q7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cHJldmVudCBtZWRpYSBjbGlwcGlu
ZywgdGhlIHByZWZlcnJlZCBoYW5kbGluZyBmb3IgYSB3ZWIgYXBwbGljYXRpb248YnI+Jmd0OyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3dvdWxkIGJlIHRvIGNyZWF0ZSBhbmQg
c2VuZCBhbiAiaW5hY3RpdmUiIGZpbmFsIGFuc3dlciBpbW1lZGlhdGVseTxicj4mZ3Q7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YWZ0ZXIgcmVjZWl2aW5nIHRoZSBvZmZlci4m
bmJzcDsmbmJzcDtMYXRlciwgd2hlbiB0aGUgY2FsbGVkIHVzZXIgYWN0dWFsbHk8YnI+Jmd0OyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2FjY2VwdHMgdGhlIGNhbGwsIHRoZSBh
cHBsaWNhdGlvbiBjYW4gY3JlYXRlIGEgbmV3ICJzZW5kcmVjdiIgb2ZmZXI8YnI+Jmd0OyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3RvIHVwZGF0ZSB0aGUgcHJldmlvdXMgb2Zm
ZXIvYW5zd2VyIHBhaXIgYW5kIHN0YXJ0IHRoZSBtZWRpYSBmbG93Ljxicj4mZ3Q7PGJyPiZndDsg
VGhpcyBpcyB2ZXJ5IHVuZnJpZW5kbHkgd2hlbiByZWNlaXZpbmcgY2FsbHMgdGhhdCBtaWdodCBi
ZSBmb3JrZWQuIEJ5PGJyPiZndDsgaW1tZWRpYXRlbHkgImFuc3dlcmluZyIgYSBjYWxsIGJlZm9y
ZSBrbm93aW5nIGlmIHRoZSB1c2VyIHdpbGwgYWNjZXB0PGJyPiZndDsgaXQsIHlvdSBwcmVlbXB0
IHRoZSBwb3NzaWJpbGl0eSB0aGF0IGl0IHdpbGwgYmUgYW5zd2VyZWQgb24gc29tZSBvdGhlciBm
b3JrLjxicj4mZ3Q7PGJyPiZndDsgRm9yIGluc3RhbmNlLCBpZiBhIGNhbGwgY291bGQgY29tZSB0
byB5b3VyIGJyb3dzZXIsIG9yIGJlIHNlbnQgdG8gYW48YnI+Jmd0OyBhbnN3ZXJpbmcgc2Vydmlj
ZSwgYW5kIHlvdXIgYnJvc3dlciBpcyBvbiBidXQgeW91IGFyZW4ndCBwcmVzZW50IHRvPGJyPiZn
dDsgYWNjZXB0IHRoZSBjYWxsLCB0aGVuIHRoZSBjYWxsIHdpbGwgYmUgYWNjZXB0ZWQgYW5kIHRo
ZW4gZHJvcHBlZCByYXRoZXI8YnI+Jmd0OyB0aGFuIHNlbnQgdG8gdGhlIGFuc3dlcmluZyBtYWNo
aW5lLjxicj4mZ3Q7PGJyPiZndDsgU28gdGhpcyB0ZWNobmlxdWUgc2hvdWxkIG5vdCBiZSB1c2Vk
IGlmIHRoZXJlIGlzIGFueSBwb3NzaWJpbGl0eSB0aGF0PGJyPiZndDsgdGhlIHJlcXVlc3QgY291
bGQgYmUgY29taW5nIGZyb20gYSBzb3VyY2UgdGhhdCBtaWdodCB0cnkgb3RoZXI8YnI+Jmd0OyBw
b3NzaWJpbGl0aWVzLjxicj4mZ3Q7PGJyPiZndDsgU2VjdGlvbiA1LjIuMTo8YnI+Jmd0Ozxicj4m
Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7V2hlbiBjcmVhdGVPZmZlciBp
cyBjYWxsZWQgZm9yIHRoZSBmaXJzdCB0aW1lLCB0aGUgcmVzdWx0IGlzIGtub3duIGFzPGJyPiZn
dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0aGUgaW5pdGlhbCBvZmZlci48
YnI+Jmd0Ozxicj4mZ3Q7IEJ5IHRoaXMgZGVmaW5pdGlvbiwgaWYgYSBwZWVyIGNvbm5lY3Rpb24g
aW5pdGlhbGx5ICpyZWNlaXZlZCogYW4gb2ZmZXI8YnI+Jmd0OyBhbmQgc2VudCBhbiBhbnN3ZXIs
IGFuZCB0aGVuIGl0IGxhdGVyIHNlbmRzIGFuIG9mZmVyIHRoZW4gdGhhdCBvZmZlcjxicj4mZ3Q7
IHdvdWxkIGJlIGNvbnNpZGVyZWQgYW4gaW5pdGlhbCBvZmZlci48YnI+Jmd0Ozxicj4mZ3Q7IEkg
dGhpbmsgcGVyaGFwcyB3aGF0IGlzIGludGVuZGVkIGlzOjxicj4mZ3Q7PGJyPiZndDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtXaGVuIGNyZWF0ZU9mZmVyIGlzIGNhbGxlZCBi
ZWZvcmUgc2V0TG9jYWwgaGFzIGJlZW4gY2FsbGVkIHdpdGg8YnI+Jmd0OyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwO2FuIG9mZmVyLCZuYnNwOyZuYnNwO3RoZSByZXN1bHQgaXMg
a25vd24gYXMgdGhlIGluaXRpYWwgb2ZmZXIuPGJyPiZndDs8YnI+Jmd0OyBUaGUgZm9sbG93aW5n
IGRvZXNuJ3Qgc3VwcG9ydCB0aGUgImJhbGFuY2VkIiBCVU5ETEUgcG9saWN5Ojxicj4mZ3Q7PGJy
PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtPbmNlIGFsbCBtPSBzZWN0
aW9ucyBoYXZlIGJlZW4gZ2VuZXJhdGVkLCBhIHNlc3Npb24tbGV2ZWwgImE9Z3JvdXAiPGJyPiZn
dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthdHRyaWJ1dGUgTVVTVCBiZSBh
ZGRlZCBhcyBzcGVjaWZpZWQgaW4gW1JGQzU4ODhdLiZuYnNwOyZuYnNwO1RoaXMgYXR0cmlidXRl
PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtNVVNUIGhhdmUgc2Vt
YW50aWNzICJCVU5ETEUiLCBhbmQgTVVTVCBpbmNsdWRlIHRoZSBtaWQgaWRlbnRpZmllcnMgb2Y8
YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2VhY2ggbT0gc2VjdGlv
bi4mbmJzcDsmbmJzcDtUaGUgZWZmZWN0IG9mIHRoaXMgaXMgdGhhdCB0aGUgYnJvd3NlciBvZmZl
cnMgYWxsPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDttPSBzZWN0
aW9ucyBhcyBvbmUgQlVORExFIGdyb3VwLiZuYnNwOyZuYnNwO0hvd2V2ZXIsIHdoZXRoZXIgdGhl
IG09IHNlY3Rpb25zPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDth
cmUgYnVuZGxlLW9ubHkgb3Igbm90IGRlcGVuZHMgb24gdGhlIEJVTkRMRSBwb2xpY3kuPGJyPiZn
dDs8YnI+Jmd0OyBTZWN0aW9uIDUuMi4yIHNheXM6PGJyPiZndDs8YnI+Jmd0OyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO28mbmJzcDsmbmJzcDtJZiBhbnkgTWVkaWFTdHJlYW1U
cmFja3MgaGF2ZSBiZWVuIGFkZGVkLCBhbmQgdGhlcmUgZXhpc3QgcmVjdm9ubHk8YnI+Jmd0OyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtPSBzZWN0aW9u
cyBvZiB0aGUgYXBwcm9wcmlhdGUgbWVkaWEgdHlwZSB3aXRoIG5vIGFzc29jaWF0ZWQ8YnI+Jmd0
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNZWRpYVN0
cmVhbVRyYWNrcywgb3IgcmVqZWN0ZWQgbT0gc2VjdGlvbnMgb2YgYW55IG1lZGlhIHR5cGUsPGJy
PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhv
c2UgbT0gc2VjdGlvbnMgTVVTVCBiZSByZWN5Y2xlZCwgYW5kIGEgbG9jYWwgTWVkaWFTdHJlYW1U
cmFjazxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IGFzc29jaWF0ZWQgd2l0aCB0aGVzZSByZWN5Y2xlZCBtPSBzZWN0aW9ucyB1bnRpbCBhbGwg
c3VjaCBleGlzdGluZzxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IG09IHNlY3Rpb25zIGhhdmUgYmVlbiB1c2VkLiZuYnNwOyZuYnNwO1RoaXMg
aW5jbHVkZXMgYW55IHJlY3Zvbmx5IG9yPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVqZWN0ZWQgbT0gc2VjdGlvbnMgY3JlYXRlZCBieSB0
aGUgcHJlY2VkaW5nIHBhcmFncmFwaC48YnI+Jmd0Ozxicj4mZ3Q7IFRoaXMgZmFpbHMgdG8gc2F5
IGFueXRoaW5nIGFib3V0IGNvZGVjIGNvbXBhdGliaWxpdHkuIFNEUCBPL0EgcmVxdWlyZXM8YnI+
Jmd0OyB0aGUgYW5zd2VyIHRvIGJlIGEgc3Vic2V0IG9mIHRoZSBvZmZlciBpbiB0ZXJtcyBvZiBQ
VC9jb2RlYzxicj4mZ3Q7IGNvbmZpZ3VyYXRpb24uIFlvdSBzaG91bGQgbm90IHVzZSB0aGUgc2Ft
ZSBtLWxpbmUgdW5sZXNzIHRoZXJlIGlzIGE8YnI+Jmd0OyBkZXNpcmUgdG8gdXNlIHRoZSBzYW1l
IHNldHRpbmdzIGZvciB0aGUgbmV3IHRyYWNrIGFzIGFyZSBjdXJyZW50bHkgaW48YnI+Jmd0OyB1
c2UgaW4gdGhlIG90aGVyIGRpcmVjdGlvbi48YnI+Jmd0Ozxicj4mZ3Q7IFNlY3Rpb24gNS4zLjE6
PGJyPiZndDs8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1doZW4g
Y3JlYXRlQW5zd2VyIGlzIGNhbGxlZCBmb3IgdGhlIGZpcnN0IHRpbWUgYWZ0ZXIgYSByZW1vdGU8
YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2Rlc2NyaXB0aW9uIGhh
cyBiZWVuIHByb3ZpZGVkLCB0aGUgcmVzdWx0IGlzIGtub3duIGFzIHRoZSBpbml0aWFsPGJyPiZn
dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthbnN3ZXIuPGJyPiZndDs8YnI+
Jmd0OyBCeSB0aGlzIGRlZmluaXRpb24sIGlmIGEgcGVlciBjb25uZWN0aW9uIGluaXRpYWxseSBz
ZW50IGFuIG9mZmVyIGFuZDxicj4mZ3Q7IHJlY2VpdmVkIGFuIGFuc3dlciwgYW5kIHRoZW4gaXQg
bGF0ZXIgcmVjZWl2ZXMgYW4gb2ZmZXIgdGhlbiB0aGUgYW5zd2VyPGJyPiZndDsgdG8gdGhhdCBm
aXJzdCAqcmVjZWl2ZWQqIG9mZmVyIHdvdWxkIGJlIGNvbnNpZGVyZWQgYW4gSW5pdGlhbCBBbnN3
ZXIuPGJyPiZndDs8YnI+Jmd0OyBJIHRoaW5rIHBlcmhhcHMgd2hhdCBpcyBpbnRlbmRlZCBpczo8
YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7V2hlbiBj
cmVhdGVBbnN3ZXIgaXMgY2FsbGVkIGJlZm9yZSBzZXRMb2NhbCBoYXMgYmVlbiBjYWxsZWQgd2l0
aDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YW4gb2ZmZXIsJm5i
c3A7Jm5ic3A7dGhlIHJlc3VsdCBpcyBrbm93biBhcyB0aGUgaW5pdGlhbCBhbnN3ZXIuPGJyPiZn
dDs8YnI+Jmd0OyBXaGVuIHNwZWNpZnlpbmcgdGhlIG1hcHBpbmcgb2YgbG9jYWwgdHJhY2tzIHRv
IG0tbGluZXMgaW4gYSByZWNlaXZlZDxicj4mZ3Q7IG9mZmVyLCB0aGVyZSBpcyBhZ2FpbiBubyBk
aXNjdXNzaW9uIG9mIGNvZGVjIGNvbXBhdGliaWxpdHkuIEl0IGlzIHF1aXRlPGJyPiZndDsgcG9z
c2libGUgdGhhdCB0aGUgbS1saW5lIGNob3NlbiBieSB0aGUgYWxnb3JpdGhtIGluIHRoaXMgc2Vj
dGlvbiB3b24ndDxicj4mZ3Q7IGhhdmUgY29tcGF0aWJsZSBjb2RlYyBhdHRyaWJ1dGVzLCBidXQg
c29tZSBvdGhlciBtLWxpbmUgd2lsbC48YnI+Jmd0Ozxicj4mZ3Q7IFNlY3Rpb25zIDUuMy4yLCA1
LjMuMywgYW5kIDUuNC01Ljc6PGJyPiZndDs8YnI+Jmd0OyBBcmUgdGhlc2UgZW1wdHkgYmVjYXVz
ZSB0aGUgY29udGVudCBpcyB5ZXQgdG8gYmUgd3JpdHRlbj88YnI+Jmd0Ozxicj4mZ3Q7IFNlY3Rp
b24gNjo8YnI+Jmd0Ozxicj4mZ3Q7IE90aGVyIGxpa2VseSBjaGFuZ2VzIGFyZSBhZGRpdGlvbiBv
ZiBleHRyYSBhdHRyaWJ1dGVzIGFuZCBtYXliZSBvdGhlcjxicj4mZ3Q7IHBhcmFtZXRlcnMuIEZv
ciBpbnN0YW5jZSwgQ0xVRSB3aWxsIHdhbnQgdG8gYWRkIGFub3RoZXIgZ3JvdXBpbmcgY29uc3Ry
dWN0Ljxicj4mZ3Q7PGJyPiZndDsgVGhhbmtzLDxicj4mZ3Q7IFBhdWw8YnI+Jmd0Ozxicj4mZ3Q7
PGJyPjxicj4KPHA+Jm5ic3A7PC9wPjwhLS1TUDpraXJhbi5ndWR1cnUtLT48IS0ta2lyYW4uZ3Vk
dXJ1OkVQLS0+CjxwPiZuYnNwOzwvcD4KPHRhYmxlIGlkPSJjb25maWRlbnRpYWxzaWduaW1nIj4K
PHRib2R5Pgo8dHI+Cjx0ZCBOQU1PX0xPQ0s9IiI+CjxwPjxpbWcgYm9yZGVyPSIwIiBzcmM9ImNp
ZDpCRUkwWFQ0Tlo1SkVAbmFtby5jby5rciI+PC9wPjwvdGQ+PC90cj48L3Rib2R5PjwvdGFibGU+
PC9ib2R5PjwvaHRtbD48aW1nIHNyYz0naHR0cDovL2V4dC5zYW1zdW5nLm5ldC9tYWlsY2hlY2sv
U2VlblRpbWVDaGVja2VyP2RvPWY0ZmI3MGJhOGI3MmM5ZWMzYTg2YzlkMDg3NmUyNGMxYmYxMmJm
OGIxZGU3Yjc3ODUyY2NhYWE1ZTc4ZDc5MTdhNTg2YThjOTlkZmJmYmFiMGVkYmU2ODNjODUzZmU3
MWRiOWZkZGRkYTMzZTgyY2JlNGEzOTE0MjRlNjJmY2Y2Y2Y4NzhmOWEyNmNlMTVhMCcgYm9yZGVy
PTAgd2lkdGg9MCBoZWlnaHQ9MCBzdHlsZT0nZGlzcGxheTpub25lJz4=


--=_NamoWEC-qrem077x8a
Content-Type: image/gif;
	name="201407210805126_QKNMBDIF.gif"
Content-Transfer-Encoding: base64
Content-ID: 

R0lGODlhCAKQAMQAAAAAAP///8k6OspMTNRiYtt0dOSOjumiovLExPfZ2fvt7f/+/uvr69TU1Lm5
uYyMjG9vb0dHRzMzMyoqKgICAv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEA
ABUALAAAAAAIApAAAAX/ICOOZGmeaKqubOu+cCzPdG3feK7vfO//uYBwSCwaj8ikcslsOp/QqHRK
rVqv2Kx2y+16v1YReEwum8/otHrNbhcX8Lh8Tq/b73al2M3v+/+AgYKDVniGh4h1egyEjY6PkJGS
k0OJlpd5SXsBDQ6engwNjFKilHoNSaVYqkisTK5CoUqdo02waLJMubGogg6Nt1S/a3IIeAoJmHAJ
CnTIipq1EBETFBERDRHDUdqmSQ8PSd1GENzbR+NN6UPgqRPYr+Hrae1MDhFE94MUfA3hRvOKlHPC
z8xAIXIG4EFQAJGBOQWMzWEIDckmIfqEBFR3zhuWgk82DhGJrmOAekcy/zJpR5IMSiUqA8T8A5LN
yyc1l+QEU9MSxUMKD/2cs6iIyggQKExAxSCCtVoBmlKgIC/pBEZSIzBw8I/ryWr/hDSYRjUpvq9U
ozpdGiBp2rZTyzUAO9BqLyHt3IZt22Cs03Jm0YbzS2HgA2sTfj0AixfxNqlsszLqtjgtuAfDMA+p
BlgpqgdJh82d8ACpZ7VPiUA4HNlp2tVKHVT7NbewWKUR9kpNy4Azvt6F8SGdIBg1W71C7CY/rTru
ycr/kiYlAm620+hxm4o9K5ax5Las+04gvTschL5kD8LFBmFCZ9twp8NlO6S21uJfE7dNygD6+kpx
NGTAAQMQkIwCBAxggP+AySTw0AEJPmTAAAU4SIABBiQDIYUKDCVHUflwd81JgJWomlz8UMMABCay
OFdyDzBAgXh3OTBjA1T1JsqNS5VG4lxbEVeaCEut1hQ+i/VHHDsPACkbEdrYuGNfFDggI41SXnml
jVbyiGWV7CDZYjnaXDmXP+CcNWOY/ly12En3xeLiiKDtZ+dISOLDIicpCucmPuTlFkBiMu61J47g
HZnoiFWK4KWPoDkppJuTKkmdVjomieiQ8uHl5o38DKkjW3Vu5gCOK5pIp1YuHpqiJzNeWV+VNjIi
ao+shkoplPLE6OWVbyLlKI04bpPQAgU0dICAByiQLLLGUDSAMQMkkMD/tAgMoICzCChQLbIHeBgH
iEMc9Ys+a8pIhBg2BiCoumsiqh8F/dUVVkYFaVPqaj6KIBsjvQCcGL0yCTcMfc8ByQmUnpzVTaj2
ZqTvQIntCw7F2/TLSLyvWgyOjEGG6O7BaBbB0rn4pFtTN/qw++pzBb8Y85KrrctIuwT7mHPKeNmr
8b8Lj7OU0HdFxUnF/7yMKJMFC1GQwA7sqV93GMmKKMtIhuPyyBKfw49KUHdzNckjDUYijKXKo5i9
AfQUh0IRLSBtM8tCK3dD3yazgEI/xd3ggOLCQS5GIqLc9lRTEWHfy2037jR4Lx6G+L1qasQV4jlS
E2N8TK01MOHuYp6x/3mFFR2lw7+EijlmqNej7+quP6b5xkN0DHuvNZdrsOU3ndw05isbvvjIMN9j
I+LanPXS8AWhC3pBkk8V4+ych474PaIPARnSj49TUzv4GpcYkDXFBNLL+rQz/OmWE/H1Wdsb3332
3QkaPVUvUba64wi9bbe0cKBI3CgCobjt7W5wiNuECECAcDWEDoNrWvucJxYiTO1l8MLK19xTjnoU
LXwj82BUQtGeqPiDXnsaGcH0MY6iqa8/BLNc1xonwq7FToSx0x4JiUMwdenrH58JB2jWpDviDYor
e4EZ1vhnOsNdkHjgS14stqK8vTyxeTz7HV6AOMKxECcUh2mKaIxYtP8U/rB7w/heOMJnxl9wUGQy
AVlU0Je1QSWNa6hznwTb6D0yKq5g/KpgPdQGs4XxLwDHGiDeAtgQRS6AGcs6wAH7hoBl0c2BFTnC
RSRIPBaucUlOs1WKOigcIZ5lPKgAmqBA57goXcVdoNEaVU4pv2KxSFH9QthlaDmShrVvg5NhneVe
VCxVYoY4xRpCzXxoSq69MjftkBEoQeejTSXRd56UyTSXmLOXRbFtnynHmkjjPlHCsi2lRKfjjLnM
WQqhYr/BVVQQJrYq1QNiJ1GjBJUGptAUgV4gs9/u0heObuKxfbWTYD250sFQxfMuhLqHwnLzoiex
7JkFxQgi/efIAkj/ckHgWsCyEkCAZgxokg+MyAEegiBMQjAaRilc03DklHO0xz30okY1UEFTIjpF
meOZJgi7cVNkIiZGQcWHjaiRG+BMY57UUM/HksqwGY5nRUFV6C+KutWstiWo26ApOXuKCqJm1XVJ
bNl4wNS7WQrPGmDqZdNuyh/KrBFJ71jTYsZjqPHwR6z4GM07+FdUPs2Oqr2JKlTdkw/EQPOOvckr
de76uKW+Y4072SuKnFJWwx0GNH7NqS+N+M7EnMWyTR3PTxPLWHYc9avjSc5sjFjYQV2FH4mMVkNI
ysCGZCtZAiJAAQy0AAZS0lvDxVDgFhDBJpzKCH0xSi22ApUidAIK/9eNxXMxcpfsnsRW3NluSoqm
BytxwiT5gIp342iErdyFutA1CcLGOwvylsu+0MVvfGsR3fyuq2i7sO5jxCtemXzQvutNCXbPUSrr
vte8reCpfjUJYbF05ML2ha+F84Ff71I3HIh4RhysVQyJLKBDzZgDig3RXI9MYTGHQa+Ln+CXGdsY
DIuR8Y2x0B+PiEAZQA6ykO/AJB0bYchITrIcFNAsJTs5yDvOgieiTGUt/BgTzLhElp9siS0X48R6
C7KXtZxiMSNgzGM2hIjn4OU1TyTMSXYzi1NRXezWeRBGhgkYaHNn66q3zyaUQp4DrQmeArrQTbgy
HB5yCAMmwtFcbv+0if13AEkKudJAxnSQfwtpSN/hIct19HIN0EAlg/qBiDiCP0grhZtoQTNLWJFO
qLATLYQqiSVhWBJm0oRaxxQmu3tCOXitSQYcS9KX8HSkM23pIGsaE89WRrQDNOk7BMUOyqZDtoF8
bUscwXeEaAkrk+BrJpT7CucuwjpIQmwstHvcUHhfoo29aAqJtECWJhBxC7DAZAyoQAcqAIfs1u9H
ChxDzoJDwkccoQSSesQLGoAkLYShBBQgxRlS1sQbfm9+N4jj1xJusx+ZoH0T6OKPLJBHi8FASTpr
4P82EG9XqiEKEcAYG5p4xCVEIQedWOASt9syJKTvBBT95SjHULX/Ir5Se9+bQxOqEEsFnvSij0sy
siGNaVqTGhY9JRtb7Q/pyDkfF1ZmbVWqTUOXovbupOUvZV9OpwqZNb7KvSDKGWJYq8GW3FhDI4ep
HPjsXh53WWUyilHKXlrmGsw00ysjeY7d10NFvnCiHE7VE3rgHrqnKtMasuE8a3RD75SfWebaIqnR
CYAsZT3kWXXD0AJkr9KLQ2j2BnBWQ4i7Ujk0sKV761YcstUsbWVrWxE5KUkPiOnfe9RbHZpWcZu1
8ptfa+SlrlvQq3/moMfh5seXPe2VdfGKR0T12Tp9t4xfLW9ZC1sCesjyRd1I8jurWeJ/fe6z9f5m
ydzk14IAFJF//60nUqhmJ7c0J2KCgGQCAWJkI76SMFfxJEPyJK7VCUJyH+QRKEg1PeEwPvSyGP6g
FRSYK5P1OEnSLpziUCHzJhbUTIXRFAXlgIJya0dUK4dCHCqyJ9pwJqhSRK7CQvyQOyg4gSyIFCxk
ODxoMFkyIyuoOLQSK/TigzE0QsfSe7NXaYwmSR2lW3vTIHDDEJZmINqCQLJ3cwzHSAfEcovmUrUn
Ug+hEJWGAKx3N1gIfnXIEMuXhUt2YtoHB5W2hye1DHnofin3PxoHLXdYSYwGOClFLQi0LXIThsPX
SF4YN3lDiT8RFH7zc5LEN3gDhog4LhyjRIajMlCUJlIEDkBTVv//oEsUUzIWmISziA2vZCXZNChg
xycnSEN3VE/npIs3gRU6k0opY4y+KDNWsjWr1DFsAzpbww/WsIsJdU/EsxVJ+DvgdVAj0w3qokc2
9IxWSGkDUI4SF21diEDXFoYGFBFBQRGq120/AUDF8EBz+IjFZTdyGC7mSCGaFhHZYo4RYY8jp2/P
EhT3CIjN5iHrOIqYplKWplL96IaQCI8JInBCh0Dp2JCOtIYKVCClBopreEAdyVznY4q/gzmdhBQw
JkSkcx7WMxWjwzuU1TRRgjlSVESuIZN9xDS+iEbzcz1t9Q5ZREHOw4rccTRwZUS2MzlFNDyJ4R7t
okfWmA7ZaJT/TIg6PZlQNrQ/U3SFlqYh+TaKjlSG3gItBnRzZfgTF8JoAZSHi1SPCklJ01eG+/gT
27KIeNkhBMlwyUCPCSlSC/lA69cMZ+lID1lJEamYy4BA+ohAaEiSJiZAl0gthqmJD8SJlYRymCaS
ZomZpKhBKElBQUMboAd6MANGQzNGPnlGtciN/nJalddCTNmLNtg4fUSby8MWWLlOPIOUVfNE3tgx
XFRETzQNuUEN/1RISuNL3AQ67NONv/CNXNk6xfmV/kNSzeBRy0eHZHmJklQ3b3gtuKd79VZt37Jy
3TaJyWAgdAkhjLaPXwiH1xJ91KIhcdgMpfaWCRSXnamfI6ct/+63cuLphYm5fAGoneBCl55JN5So
hulIoJbomJrZe8AnkhI6ioIjUKOZThZ1MDqYM2nyTlzxG1X4JtbkNK5IPHolTsOSPiZaL/lEHcN2
m/h0GHAyR2KXD0vCKOZRUD/6kwA1IwaFFDnagxhVRAYFYzaiHj9JQx0EAdnkI4LyVNGpLyYIjqgz
UWGhaMVVUqTGQIuWIMaQjvBIIenZLQxUagiiIIS5npPIQM2wnnTIQKeWQMZwfXAgnyf3LfqGhn1a
cy3ne3bKeggZniBZkHaacgKXDIjJhd0SpmgoqY4ZN8YVXBdSLfT3nYyaphSKp8jVll96po2qocxF
VvlUGm9VU/9G9FMlBDOIpVNSFVQu6SlX9VWXw1n5gSI06FeLVRM09VPWyFr80BS+ehNBVUKI8UrL
SjvtoFmwlRTZsFadBVtCpSehRSW+kkQ2ClUzog9LNSKClZXtIx05MR4zVFvYqXDClwCTJnyJsGJv
Boh0Y49uKQfuegd6WG2WsGJGBwfEdWLwCmZ1MLB1IGfLEGbyiggGm692sLAkFmQLewgLW7EG+1Ia
xgn4lbFOUGAF9hwfu2HlghUV1l/nxV35QGFLgGEwUQv0sg0vmwrdRV7olWCKM2FOwLGExgtLoBlL
oz0Vpjgd4aXLhgcQQiA4F5mXsFxAhiALUodFG7VSO7VAFgj/rlZly6lHWCsMs+SkUUC0VDsHcxhA
/IoI/+pkRtdkYbu2bNu2gTBlW4sE1xS3wnC1ULAJuxBgQgtdgIZEYJC3OGsEnxC0W6C3WsAKnTC4
h8azMPExXICNcFu4gdtegwYgIwZnbftIZXYMmMu5dUBiZbtpSztkz5Bmn7stnXuwqZsHm6ASxLZU
ACFj17AYXhsGHWQenNRr16CrWzBsSbkF6TAN1XANk/tuXwFai9uz2xCut6oJtUsOudsEItgKezEH
F5K5jwSpiDBtC4FqctCZTwandRAuIwlklEkH9wotTKtwDzJyLNa64fW7WwQFPjJPlduxSZluSAAS
DZYF+msF//NgvL9Gbr1AhFNglSKCa3A0awe8SkbwEvg6XNibmMu2XNy7ttu2tN47B+K7vo55CSNU
RNQEHaMxPdLDF150EAjzXP5BGEMUWGSBHWwBFhczjZjnFPfhd3HyONBZQtAha2qhlHKRHusxFkIM
eKlRH3y3efAReFMjwilceJmHGjvcNqNQCt8hFVGaGLJhG3vVCyrBEiWkHIyhHFpcxHLBGUhcxYOi
HW7XJJO3UQppABIRc+5qaZUUB/8omAnickD3UX8zc/wGcCSnIA7XQAdgccD1cwPXpiA1YirHhYV8
cS9HXCRlyODij3KKLFlIyC93jgxkcfVGXHZ8sBHCIJdcfv89R2oVV6dB53Ozd8mVtnGG7CAH9yHw
W0SagkLn4SpcA1AJVQQycipLISU4glSdkCMhuCsiCA7FpCcm8nZ7wb/itIxSeCZnw4FNSCW+xIFt
0ysWpBjacM1nwiUDXCupwotGMiJ7kkLJQVHKNCa9wRWvxIFzsTmcVIOKwcw9siu3BILd7IHfHIwY
UQ6vdESo4iKWW1xGx2iwVyGc2GyaJoclRZ6yR56KpADm53rTd3/Bx2TNIoAgRYADYp7ft36fGFIe
VTe953yf6H+vl9IPjXskR1LFJ1IldXszjb7UZ4krx53YIqAAKXHo94gQkrYd3UD8Z4iCk8sjjIJa
czOvMhP/mRUxleNMMEI0BNU46MJT0ji/tXMNO+U4FlMzFLUkxpNH7yMzOgPWFdQfOTkxJHrO8CPV
VpyjqEijp4GKK1QyyhhsMmENOsXDWh1sS9HXXG2LeJFFL1EzNaOMO2q5y4cgeAqZhanHliafBySJ
2eKQ2ssQ3mmAa6hpqjefZ1mGdUOIbUiSEyfaqAuXHolzMu2FnE2JD2ogJZkQ9YqWrY1SeBrajvjb
GreHK0WXTV0LrltHP7k+o1U70xXZwNlKo5UmorPV8naS0DPNnxDM9yNMRog8M/Q+GUFBLyE512BD
/xDAp3UWzPM8KtleewI8hwQ+OElasuEJd5Evw8A+O1kl/zkh3utN1lb0DowVExAcQBRSqog5IN47
0YK5p5MMmhQM2oTpn2OY2f24hkPxE+BLUivnLL8XkOUYl3EDvo6UyrYtdAPphXTwjpbo4ZldqQJI
kJREQC5F4ZV93Eqsy3fUDmQ31b+bDrFk1YQ93apaQdatjXMk4FqrtSJUKMSREbH5SwXzmtmtxMaI
3gglwhlxRc9TH+UCSqSJCs0ji3Vt3/Kr3ySajQtT5olt5W49F58gb3F04AuKACd14gpSkDHu4JEp
4Z8dEbB9qKIN4Y3p4pWokAf0l/yGuqS2l7H94KC5nymelqD9wcdGmYwehzL+E8GtvhoX2jiekSFc
O71gP/89XlDmFJ1hjhXjcxU6MlSwggryFOt1JG8ceuXBrLXG5C7NGE7h/TsrquvapBFx7QlGdWEB
ftc4WqUeOk1xVSeC8qGwdE/hhOZGAD2BJW/1K1rndN3D7tZE+DDDEk2o4D+q3ZECt7m919kOjtpw
E56JWJaOmtKCWZ8BIkneuXKPvKftmdI3x5cnddr4Gekm7oXw/ph1g9G0DWf8boloCEA13n7uyXre
MuOSXu90aQyl7ilMZSupHq2ixWvtcR2y5R6VJ91Zh/Ksxas+blqGtSbEfkg8bK2N0QuLwVlWBfN7
xaxubVvuAfPEw1V0ffJ/5Vgxfw42ElQAA1e0cVb/kPP/a9Iew8BrT7NWpumABJ7GsWVb6cP0TP5O
d1En0PpZ7QCI3qstHZnakJwsmq0QYToh0bfIBLIsBrqmc6qQBGKO3SdwebqmDb6mKX1yDXQtwxWe
wvUtminpoxj32vLoCoEgZOrZ+Ar4imhzknSpv72mjAb43TcgiC+nDMpcm+RetjC5FlY0NhtT6yVe
HlZhOksKOkYLFlGylRuy6YVdAEaz+PWxrl+zFYb7SPD7KCuyUWH7VGCyJosJg7hkoZuw+ApnEctm
z+8MZxYHCPtInSuvHRJm7rq5WgZn1z98q8tkKrb98DqxI/auZeawy/D8ktTxjSDAdFv/9n8EhkBq
4I+9//wPAos4kqV5oql4KKr7wqlyLAHDBLm+873/A4M5xkNoPCKTyiWz6XxCo9Kd65CIYbPaLbfr
/YJdNkZYlGiV0yTEtYSInU8JBLocV8feWb25ruKLAOJxCboUqtxxJZosdi3GCR6eFNo05DQ44EA5
TD01aB4xWOrcpB3QDJYZEKAuHLwNxBQUKgwUtH0l0MymjryexGYFr7Se/A6LIPcKwxxn8cYYlECT
/FJ7nVbTKMcqSKso1zhE2FBEjD5RdDo9FCGN75Quz2td84bvFZgWL1974ae4R2+gCH+pAE57Y3BL
NhP4EOgDZyIAPHhS1K3L6MPiEDK+BhC4oqCArRYGDv+AnIMKwaldKAu0eGkA14IEBAZ8K7DKFyp9
NkvWvPltxE9pKEOuSIkTaNESM0/d3IVzgYGUrqoiOAkSwc03I0G+IsBqJlWrUFk5ZSq04EtXKX8i
1XcWVVWkZatqW1DgZZ2jCZbC1Ot2ajWrXwNrJcB1wJvEixUS08tXcNnAcHWl1HfYpF8SM7/aTTq1
6q1VBsj69bs34kgSe20V3Fn3yoECYmlkW5pT72ird8NRJBeBAoQh5GyQazCBeI7j7XYQN4dDOYUJ
DR5wCoA9AITq6LR3d0C9OMUJE9x1t679QQRNED4Nb29jOYTjHYmGPECAqrTTevef9hdbubn0lwII
MEb/AisKoMVYX6jEspdkCywo4QgLVsiCCCOxMIBLFLJgYUEsEXDgfvrpApN+rgRWgD62zaCPfwIG
OIt+M5xYIoLVwKQTiAxuU+BeQLK4QCw37libiSx6gwyBE244pIcTxjLAGaHZpAuA/Unj4n8x6vVi
ibUZGdmUEh7ZozRoKSklf296SeYINso1lJFXJvAXAggqMBIb+ZU45CxIHWAnThwaSYeSKyJ54jYG
IHpkfjBxxSReJQSnnXo5qPdAcecxcF4AGD2nAwVFRFCEqOx5yul1EzDgwAQ7sIcDqKkGMIEDDlBA
RHuyrgdBEcpxVxwExhYXgX1j+PLNNlcIaGEsitUy/8M2xBQqgmL4BaKPMg1FSAO0+y0AEbflvgiI
QK5YQa65c7IEIbpQ5tfTG9mY22e5R+6SFSqKgeuaV392Wya7er0hEpn8JkNvArwIyJPBDY048bVW
1lSNs3fWFOG9NJjLC77emlkyLwcu0AKYAmEc7RvvjkimviO03PC7Nm7Myyz+bUvzFeYGYyHA8ub2
M8kh//twwsBVtOyxue46a6akupMD1TbYUKs6wArrqg7PARscsRQFgGuu12FHTqsUWMKAOr1qt6w8
B9NcNzRHniTXtew2RM27QJcQsE1oITiA4RHNO689sBBT+OECBxyyHjbae7C5P5F08CzQUN4wvCP8
Tf+y5vfe5CXDZZJkOGN35xUMxQhbXKZ+17w+jMeWp4t77K5fSztIXrJs98uIIzzSgtUQwPrN8QqM
cJbcFBz05MzLvjfgIau+uh5Mk8NRAMo1sPVx8Fxtag7PPVCdsme3OhwF72e3HkXvvx+B9+7D347b
ZXNC//uj5sB7c2vINlR2uzL95SQH4122KMSHSs3rW/IymgHeNbNyuSt3n+OdBf3QuTJJTlvUExnI
9NEzhm1OD0PzXMXmAEHAja4WRqtew6BxBdZJjHfN02EszlCbVhDQSAaE3ciIWMLdmSxhf5ohy4bI
C5gVTwEJ2AlRYnSt5QVRZ28ggH9IEAwYQmOFNPz/4tE0eMPtTaRpPJjA08JGvvNVDYDrAV+mjqUr
/l2CVkWwyA0skgn75fE5qYIbRr4nRwF6JCgYnBCZfCSnm5SMXQZCECAwhqbASWNH2wIabQx1w37t
0EydhJy8zEUmAfXtYxGMCQpZ4pPTOcko0rDk3rIxCwiajm5pStkAZmAUJ9WyGOsqWomo0gqbLFJC
jVRlCItISyRmq1C4zF24ivRE4u2MBrXAD2dAGJFZILNSWiyLIKakQNe9UpcL/FAsTKmZXkazG7jI
lPe4Q4HssK1sRcin2awGx7CtTzlSY085QFGqfK7tBmwjqNuIUIQHTOA4uAIWruoTj0RSpSsdI8kN
/8ViFznlJjJH6VkgQFJMZfzFRUeyxbZegjHQmbQF11jFjg7mUpp8sJ2a8ShuKlfEVXDRSiipDR14
qs4RMIij+xJLC3RIU9twcT+wTBlUpZFUSOYwMiOgKQ8zahuarCJBKbUkM3P3U7FccoEpSx7GPCob
xfTQFmRN3IhSipatJg8pYlleRhP01JeFg6Un3ZBRA5abvDa1Y5Cq6lpto9MR0HNZ8/uaeWDFHfP0
U47PqSwEpGYO45iHPHA8nzkQGlrknPY54XNH+IbDCYFG9KJuqMOB0HDLOigwBbrQFk1qIokNAaK2
SKUDI35brt4C1w95QC4iaJKnNTC3BMI1g3HZcP9cGFgXdISIbrkOQdzkeuG5LphuufyQ3ZR99wUH
Qu6ehqvcQNThvA30Isomwd3hFjcQNJGEEFqlA0zsoAHfAUImgiCeIMQKFALewYERXOAhDJhZsgDE
Kt5LgloYwDYE2TCHO+zhD4M4xK4gad1EPBEgQDR+GllxJ+b2Ag354r4bOoWFTWzjG+M4xzouQ3tN
wA8bG1jFLB4yFG7QA1HEI8JENoKQEaxkIHxiyQaWsg+Q/L0m88DKQ9ayk5fMCS4nAcwQ3ggUFkyK
J1P5yGhWsxKw/AQkRxkJYjaCkXVQHO/VM81AKGQQ7ixZIQBSzzzgM5X9PL8/2zlTRM7zRhC9DnX/
lGoJkdajDwg9BNFWuTiTnrSgG01nTcfRCJbehHCwjGkdMFoIdfZnqjsdhVG7egmwHjKfOT1oRQ+5
1Qx2dEZsfQRf+3rUuoaHr2P9BF3rWdfC5jUQVt0d+0WUOQ3QNH14ANE7jqc56UuVeXAwSG5b1jmo
2ra3kcMcTUnn2dM2t3yE5Z0dvGfawzk1RE/1vc4eqzuiqPa02diDb/vTnpvqjrSXI596x1He50a4
Pc/xHvOUygFVe7as5n2+5cSRAcNRj8alw530cZw+yal22TqLavPYWz5lA0XH2w1yWd3ze8tRj9oS
PnNLfHs66kv4zmV+boykxxIYF/h3MM6eoT+H/+AZtzi6h1WfUz373sPx1GfXzR0BP70466YOet73
qVOpluQ53wE53K2r5XDC7DD/cnxwECrilN0S6Uv3Zxk+DokHMNRVVvA9eWUJtpGvf+hw26ty9QCN
7/Pw/sbVqUKVrH2ONuWQP1aoMsHPB4RvV2VHVtnUtiz7+Z3wpGAb+HjlbQjYSvHY6RUoTIV6xmuK
CLOqVagagKtUEZ6OAWQb4d0mHutkfhwMOFb4tP3fvueT96TfVNzAU6znr4+gwtI4OW61zwfPD/PW
6drYcvC0p60vArAi6B0JCuk4lp8ckoea29BveVUdHvYQlb2mXkV/ykocVsBqh3JiJTXvo56u+P9e
6ZFe41mH361W7VkE6CkfJlSfePQK7VkHRKGN4SHeqIwbdHRe2YyfcAhHBz7f98VfqTWUPmVe7h3g
OWBEZv3AqgHQAmreqFjCd/iX9p2P+jUHJzzHCuog5MnP1bwNDhzYDMIe+cygOgDS/cQgHp0PeQgL
DMpcE6ZaPr1RoHGczI3DsDjfx6GaREmcE0IesamK5bWe+OSgf3XNDY6BDJYDHpEPDrDH2LwRg0nN
E87K05hK2yBhD2ZK25if/PxX1uDgHNVh1YyNsMghDlqhAzIh84mhP/GfZX0H3IgHGqZNwIHecfAg
DHLiOUhNgU2Hrojh2PwhIPoTIIFNqcmPEbb/IdwQFCBNh/yBITwIINyoWhkqWiZqSqCNVgCNzyCi
og8Go2b54A7KkZ1Vh6iYYSHtIa7xDxSSFv1cohv+4hT6IgDhzz11nHn8Hq7M3ftUDQyWijE+oqcQ
lAaKo/9UjcaByqj4DzUekv34zyB2YeTpntW84zASW/3g4KbxIzFaRKQF5OrRjyL6TwxmY/w8IgAl
HXFMIqWth0VsoibmYCdWpP3IzcaJYs350SBOWjOmIh6FpP+8zTUCUnooo3aoI7EJC7ORAi5a5Cew
yte4A3Z8IjDyIQ/+YOTxJEZU4sGFofq5XTMqITQCoiVAoRth5A/4pCJmhyXgof0gZQQIC2vt/9oZ
guEL1tz3EEeomSH/lMp33EC/HSPOccIc3t1xGBmhWUTX2NGt5ZE+euJUMqQhqscctsNA1mNEqiUO
NKMhwUOgfcdCnt/3EIEtHtJ1zCJFPiNj6mJjXqQfDR956GJe3iQxaqBciuQe0ePfmaTEAWVd5hE8
hE8a3iI6euE49B8XXsKsAMvlydEw6uQO4lwxQh4gpUqrhEpQ6lPzJeHnLSEvyoq3TWOgXZ5FxJnV
FEHXQJom2t5r3ZMAqma4haMX9l/taSUgLkfrZSf/rGY/dc3+TNSs/GZvWhRCFQdb8t5dnpsOjOdm
BgdA9WM4Ss36AKHQxVE+KaPcpWfzKaDnzf8HOhDmepzjHeWgCcLKf2LiEm7irPieRbIe2wBS8G0l
bJbPKfJhYGaocOwReS5nqelmSg6nPi0gJZ6mDnBjapZdRDHfZcXctVnWbAojH3ZWRNkmAMFWOYjf
06QoVw6HWTrjY/LiZZlHLmYHjMaKF0IHi/rlfOzoodkoRInfclbWVeJRjaJerujKVjbfGm3pgdbo
//moqLRWzJUnbKlNtHkmHYaWJuRTgJUWJ2gmZ81KYaJoaNXpaMFoHO3pLiafk/pbaYbKkx5fVUKi
4mFWgFUpkaKeRF7kgmqp+AVnDF7bnZmDjbqNoSIpZpqPZmpmmb5WZZWacuzop8BKmCraOc7/WkfE
A/b1wK5sBDoAmCes2SXET4KRAvbhahTMKpQ1WYNZTazE6n+pGCYomJvxQK/uKrzp3bKeWZPFymCi
GZcZaxCYWRQOqxAAK4Gt2bUG2HdUKw8A66xuq60aWIT16pVtAnf6wLWm67siqxRE65kdma4WWLp6
n961ILsaW792mlf6KxB0Fr8GLJOxYMEibMIqbJoNrJwR7MJCbK9FrHbU6sR+j75abMZq7MbSSsW+
JMeCbMiK7MiSbMmaLBO44Mmq7MqybMu67MvK68PC7MzSbM3a7M0qbMri7M7ybM/67M+irMwC7dAS
bdEarcrq7NEq7dIybdMWbNI6bdRK7dRS/+2bCW3VYm3Wam3U6qwE7IDXAgHYBoHXiq0EmO3X8oDZ
qq3YCkHZrq0OgO3anm0AsK0P1C3coi3czm0OxO3b8u3Xym3Y7q3bsu3dBu7fhm3b9oDh6q3a4i3d
+i3d8u3bxm3aPq7kjm3aRu7dQm7hNm7eJm7nDq4TRK7dYi7g+i3hgu7lli3qHu7klm4SOC7r7u3p
/gDnrqHlPu7rGu7ski3inq7n6m7jUu7wIi7n4u7k3i7otu7xsu7lQu/z2u7iZi7wzq71bu7iym3t
Tm/vXm/wAq/10m7g1m3zTm/wpq70gq/zii/1Gu/Ytm7ysu/yDq/50u/5Iu/2yu/+ou7qXv+U+4Zv
++Zt5VauAOPv/XYv7Bbw+w4w9ZrvAwtw4b5u/f6t/gaw5vqu+kIwA5evAgOw8IouBg9u7YJwBH/w
7hLvBmOuCvsv+m4v+/6u6a6w6GawCE+w/kpw7Oou4aavBa/vD2cZd8Zw5zKv+xKwCbsu966u5wrv
C58v5AIu2qpw8z6wElfvDFdw/wIwFv8wD3vvDdtuB0MvFVPwBZdwF39w+iLx+rJwCn8vF2PxEFsu
BOdwEYev/C7BAmfx58qwC1tx7rYv45qxB6tu9MquHQNxGDMBGSPxBuOwFV/vAtuv/0qyBhuy4hpw
345uAYtxIityEl/y9xYy9kayAk/yII//8e46Lu6Wbymjchc/Mg1PcANbMuwi8imzagDL8SfT8i5P
wRDrMRzzMhJ0cB2rsitHQSWbsSBPsfoegRj3rRHjbTDz7hxf8hZfcR+38TNvMQhzMv6+sDKDMzLf
cRPgcCOPLxrvXR638Dd7cSTHsjVf8O2esw3PcgszMPP6cBKf7Sg/sQw3synbsw4XLDALLh6Trgbv
Mz9zb+m6MzHz8TwbQT3L8h8bsiivsRfvqz2/LzPvMQJD9PyaMh6TNDdnMzbnczmH7kpntDOj9Ehz
dExrb+wyMumCcRl7Mj7rtC47L0JL9DwLMku/9E5rcy3/swsyc1AT70dT9D9T8jAbcEgT/7VTU3VT
Gy8uw+9M6zM5v3RQK7VSv3Ix260Tc7AbjzAyW/VQL/M093Fbwy9ZV/Q7W/QykzVGR/RRtx5Yp7QU
X3NfY3JYL7Ja/3RVK4E3F/ZgIzb/ovQpn/EB7/VP+/JFS/YV+/Qjk208y/Nj+7RjD3Zlx7NeTzXu
MkAL8PNf/3VTp7Vbw3Vqt/NCU/RrLzRlx7by6u1JCzYrzzJcw/RYEzQHnzVvi/Js169wa0T+1rVw
o/Y+s/Zb33NotyBpb210S/d0G+1o1wB1Y3d2azfMWvd2e/d3gzfHdnd4k3d5m3esjfd5q/d6s/cU
jLcTa/Lo3rJAQzZV+/Vmi/BEV+9X2/92URuBAAC4AOgAgA94gBd4EBB4AAS4gSu4gB9Bgjd4gUM4
hPsAhR84ECx4hu9Ahlu4Eiz4hROxX/P2Ejc3Udv1Y9+3UI9zidc356Y3LUtxQ7u05AY3W/fvKtM3
Z4v4Uusyjuu4P39xP+94gnN4DhC5gx+5kSP5kit5kz+4g0d4lCd5g394lEs4g/dAh284lDt5lnO4
loO4Nsd2QO+0RW+zjBtx9tKzbv/4VcdvlUE3DJ8wQ89tNct5JzP2ZG/14TbxVb8yF+c5TmM4k0v5
klf5lCM6of83lCd6lW95l2M5lXu5EHw5pQv4hFc6gfuwYhu1LIcuK7u0HiMvUKu4Xp//MSNH9osb
NA1HryNjMArTOE579UzntkqL9CeLtQdHNWdb9ZEfOqEnupMH+6L7OoNP+aNbuYd/OZczAYFbuKM7
umbLeh5L8JyjbxQ/cTBD9myjdhkf8ZHFefe+8bhL76gfr4/Xsp238xKncgLzeCCvsZ4jAbQzOpYX
e6MbO7P/wK9feZgLu6Ev+xIse6TzgLNz+bCHeGdr9TET90STsEnvsFuD9GGH8LkLObhftwVru7i7
MnzD+i5XMSQ/vJ+PMVf3OU+Lc5BHtsDrO7Ij/BMkOZh3OaS3vMwPvMwjeMAXupOHPCL395DFdzgD
9Ij/vGV/NBsfPSmEe5qrcSc89Hxn/zut0/QbqzaMn3ZfUzFmTwHCD7ylbznOV3i9X7mGN7vO57yX
Y3q873rbjrnWJ/PQD7XRT7wco/oTv/htL3Zpf7y7I70WT/xU8zSsu3GnC/q8F7m/DzvOg/2+iz2y
z7zitzyVR3vYLzo77/rGr72J67etC74tc/w64Hm5J30uK7zD13U3v/mNX7zHqzglC73eNzaQD7R8
e73jd73kH/vtJ7u/F7zOEzymV/qk277ZDzraH37C6/j95jCL2zcQ1zPrQ79gOzM0Y3us80DK5PXP
l/WfZ7b2c7zGu73mQzVhb37z737aOz7lz7zw9/7Zpz/7L/76oz+x+z6z43zQ3/Pvrv/6IWcuCEiB
KAajiZ7pWq5o2b7uHM9unZLuojC5BAy2hMIbEfgr2mRLpg3XjD6lqhcxCr1ZjzOB9ytIgcdNL2oM
Npm76HWg7Waf4ba2mE51wcPLbN8Jc+RXRQNoIjiY2CdoxPXXhMPjk0dZaXmJmam5ydnp+QkaKjpK
Wmp6KiWJusra6voKGys7S1tLqmqbq7vL2+v7CxwcgCtcbHyMnKy8fNvD/AwdLT1NDUssFZQzckW4
nX2YOeQ4pEU5uKXdXYW4sqeG9sZnmpYXd2f/jh9v1x6mL/evnrx3ZQYKzBSHXz55awLe+0JwIUQ2
bszAizenosF9F+vwucbuD5SRLMD/lTz0TV0NcY7QKVFXbh3KloXu9ItoMyM9jmQeWpyYZg/DhhDJ
7Izy0+jGORwxSjyqBw9TnDp7OqWicapWOVcPOrWHjyhVnku3LiGK55pJlkp0xEzXtlwMGHJT4ljp
JO8UkyrubuFmVuzNsQH1afyJMyvGpAMZF6QatOziogYRI62M2ezXjQ4HXwXrz45gShdBR306mHFk
rJkjqu1bci4jlYQCjYMbO503wHzvzja09vc5skA5U04tNWdT5YoRH3V8NnQ/ywCP2+xM3PTYzVEV
ek7Y0ePTiVw/h5862vzjy6ddOzs5FzjfbuTWysUtf7hu/TSQ6O0fEmsPBcYHduNp/6feZFYRt153
UPm04GSV/KNYTgY2aBpoFU7YmGTRVaiaTgS6o9UaPCiwwF9x9aZbbfDN15tdetFlzm/GiNahVRce
ViB59MAD3WZhCUUQdaetdqBkQg2FVo7nCdTkktwtx1prnCSFXEQXTtcjCgygWFMS2iDC30y8vbUX
mVmsRCYLjKhp5kvZkdeeFCQOSKWWxRUZWnN0kiZdYX1KV+eVe0bHpXcLbSced1LaOaiihuqJyY/y
fJkimpeMdCaMe0ES5iOe+IUNopBeImiTN4nF6qCJ/VmVn12tap1nBSnUaoOodgmejl3OasmWDvZE
omBD4srrpWBqGpJ+pLa4WzZ4Uf8x3LOQ2OhpgIUyumujjqkqYj6L9rpUhkNNGSuhtgLLFbm6cqsc
lQjulF6V65qqWYk+GpdluAFgGic3pDqrBZyfenqwigJTy/BJXsWb6JJPcrloow5SVK6VTNVLa5JG
4luex792S5iHHD8G3sPwOjTkvcoBTO1s2iqsCZs0/RfzzdGm9N/MEM/JypYsK1mWpNd5+HPI77p8
mdGFOo1echlNDfSwD+ar2Z3lwVxN115/DXbY0XAtdtlmn4122qSQrXbbbr8Nd9psx0133XbfLczc
eO/Nd99+r71stAjjDG3CMOU2U+GFv6mwf40j7NuKKs7Y6X4z7uf44SesCRPPirj/ia3DNeqs+Hyc
s1R6zz6nrjl8L30uKi1cDxwmYM6GHheNMiVOuIvZJuybpprzZq3D9eWl+/HbyGAbXc/WZzuoB7Ml
p/Cmx05C7tLzPnj38Qn+O4vGQz55964wMEn4JJFfquj2bS4+bPG/Ja31zb+ouB/KF5+E49+4Jb/d
yQ+A9nkeOuRTsOltr2Dr856Y4pO9hcVPf4f7nuXGFxy78AyBvTtf+sCnuwu67wm4K+AET1iI462O
gOIAh/8kSD/QbRCDLoJefkyIGwP+bobzQ94CrfAD0Z0OgQSMCfU+1UDahG9362tgEmeBvhh2Dmdl
cuBu1pG55KkOiE8UYRd9WJfM/1kieuLTYhnr17/OZTFOWwxii2A3xvwxgRxFQN0Ns8UmIRqxEf6D
0f9qFyoopo9xU4ScGH+InyIisYMAstG0mnczC6LEep3Aix3L6ELLVbGQcVReD3f2OgFS0Ydm9IYA
N5lJPy4OEM1inxpRGYooNoyGrAtY9WgEwFZ+EpSwpKQMK3et1dkSjnuEjQUVyUs/ilFNdOwZI6fg
yVI185Ss3CAzmXc5Z+5SeNFsXStkqT7QUa6XNXGe9FSYhy8ukHQj3FnsKkFMDJrzevwJYQedGM5G
hvJ9v/zjNNGJQsMxEVo6FCU/uWezXIAzme7E4ori2chUMtSUVCwhIlf5TCWiie1TLYGoG+FHn1cK
jAvxtKQv04Q4ac7RoW9c4ztDGghm7ZOhtwnYQWGxUP7V0p7tVKn5AvnTzVHwpZIkKvCAyroqIhOk
PX1pLefYpvYJFKlMpeo903lRQDbVmzz1YP+qt1VvDhOrY3VqgLLIUeKdaYXA9B0fXyec0G01rWBN
Klk54VFf5tV89cyqEeXKSHKCYqF/K6xhD4vYJRA2sYxtrGPrttjHSnaylPVaZCuL2cxqNm8f3Kxn
PwtaQYZ2tKQtbSnQh9rUqna1rG2ta18L29jKdra0ra1tb4vb3Op2t7ztrW9/C9zgCne4xP1tCAAA
Ow==

--=_NamoWEC-qrem077x8a--




From nobody Sun Jul 20 20:30:48 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40641B2B16 for ; Sun, 20 Jul 2014 20:30:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 2UuhsfV_C08b for ; Sun, 20 Jul 2014 20:30:41 -0700 (PDT)
Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC0A41A033E for ; Sun, 20 Jul 2014 20:30:40 -0700 (PDT)
Received: by mail-vc0-f176.google.com with SMTP id id10so6460269vcb.7 for ; Sun, 20 Jul 2014 20:30:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IzcqxdQFKKzNK4+08XAayo86IfL6UsC0Linvs8TeXLE=; b=GwIR7Ah0k2StJlQlbRpL4VN9ha043UgesLBqEU5iO2d9oa8KV6XzTx7q5zVrlIekwB rUQK11bMivaMoyTJHDjydSB4h8uUU9t0JYYHjWdln1GsGAxaKaEfbBan7MaUIj/x3aFe 3AElHveMFjlplWfX9y/d1yx6kHzrAcNIi06jIpTEaKwTlVMyjyhdC46tq28crPIy+oQn 0TYqGd4sTh4QScHjxCs651I5RtxApSeaFLqZ/7xe0gey+DgYAArGwm2XN3Izo29x138A pO1sYeEiWiB0syQlf7bAN/9VUmH5KQGFxHMPKJL/thj6faaDfz1ct3N2Bb467oxjKMUY o2Iw==
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:content-type; bh=IzcqxdQFKKzNK4+08XAayo86IfL6UsC0Linvs8TeXLE=; b=TJo0xOzGEPrXAseftRT6LXvvNyF+ByILAeupl73getdB12iJdvfZ+SlpqPnnwOr7YV Emdipy3eGYe0mM6cfckN7jgk9ikB6NIZxHyQYqkuuIaF765yDX0rB3ZLyIEuFTxqgSg3 18b0qvm9XSkr5mS0upBAN8Qq6KkiznULu6k6UARPtBox+jRsDAfPZ6dsQj6ld8kzt8pF 0YLREaV9Ea8HytMcuQnCrc2kHOH1KpErlncT8pLh7N47MQd16WE6WDa0ZlZVxChdirNy DO2q9ulaI8jtPgvL9kAM3+RkvbntD8WyrW5xRpVJAbqBFQJWkcFIQAij7f8SeJKyGnFZ x43g==
X-Gm-Message-State: ALoCoQlOthKFNoxoDk+y0oZxaXLvCAGpNWbiLZNl7fdinSWpJ30tgNaHmRTb9Bh3zrrniZOJGh+/
X-Received: by 10.52.166.10 with SMTP id zc10mr7005953vdb.61.1405913439938; Sun, 20 Jul 2014 20:30:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.66.242 with HTTP; Sun, 20 Jul 2014 20:30:19 -0700 (PDT)
In-Reply-To: 
References: <74.10.26169.C4457B35@epcpsbgx4.samsung.com> 
From: Justin Uberti 
Date: Sun, 20 Jul 2014 23:30:19 -0400
Message-ID: 
To: franklin blek 
Content-Type: multipart/related; boundary=001a11c2bdaa2c5e7304feabbb21
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/x-IEpHrpZdiCgD1WRhW8gXpik4s
Cc: "rtcweb@ietf.org" , Kiran Kumar Guduru , "public-webrtc@w3.org" 
Subject: Re: [rtcweb] New Version Notification for draft-guduru-rtcweb-codec-preferences-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 21 Jul 2014 03:30:43 -0000

--001a11c2bdaa2c5e7304feabbb21
Content-Type: multipart/alternative; boundary=001a11c2bdaa2c5e7104feabbb20

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

This seems like a pretty big hammer to solve a fairly small problem. This
proposal adds 6 new API points for the purpose of changing the order of
codecs in createOffer, which seems like a high cost-benefit ratio. And
while the use cases listed here are helpful, they seem somewhat contrived
to me, since it seems unlikely that the application can make better choices
about bandwidth or power consumption than the browser.

Without a specific, concrete example, I remain unconvinced that this is
worth doing in the 1.0 timeframe. Post-1.0, we can probably find a way to
provide this sort of lower-level control.


On Sat, Jul 12, 2014 at 9:41 PM, franklin blek 
wrote:

> Hi,
> The draft seems to explain codec preferences in a good way.
> I think this has a good potenitial to be a part of WebRTC1.0.
>
>
>
> On Sat, Jul 5, 2014 at 10:26 AM, Kiran Kumar Guduru <
> kiran.guduru@samsung.com> wrote:
>
>>  Hi,
>>
>> A new version of codec preferences draft has been published, by modifying
>> as per the review comments received.
>>
>> Please review and let me know your comments.
>>
>>
>>
>> Thanks & Regards,
>>
>> Kiran.
>>
>>
>>
>> ------- *Original Message* -------
>>
>> *Sender* : internet-drafts@ietf.org
>>
>> *Date* : Jul 02, 2014 18:28 (GMT+09:00)
>>
>> *Title* : New Version Notification for
>> draft-guduru-rtcweb-codec-preferences-01.txt
>>
>>
>>
>> A new version of I-D, draft-guduru-rtcweb-codec-preferences-01.txt
>> has been successfully submitted by Kiran Kumar Guduru and posted to the
>> IETF repository.
>>
>> Name: draft-guduru-rtcweb-codec-preferences
>> Revision: 01
>> Title: WebRTC Codec Preferences
>> Document date: 2014-07-02
>> Group: Individual Submission
>> Pages: 7
>> URL:
>> http://www.ietf.org/internet-drafts/draft-guduru-rtcweb-codec-preferences-01.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-guduru-rtcweb-codec-preferences/
>> Htmlized:
>> http://tools.ietf.org/html/draft-guduru-rtcweb-codec-preferences-01
>> Diff:
>> http://www.ietf.org/rfcdiff?url2=draft-guduru-rtcweb-codec-preferences-01
>>
>> Abstract:
>>    WebRTC specifies to implement a minimum set of required codecs to
>>    ensure guaranteed interoperability between WebRTC peers.  WebRTC
>>    allows browser implementers to support vendor specific codecs apart
>>    from mandatory codecs.  This document specifies the way for
>>    JavaScript applications to give preferences for media codecs in
>>    WebRTC context out of the available codecs in browser for creating
>>    the offer / answer.
>>
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>>
>>
>>
>>
>

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


This seems like a pretty big hammer to solve a fairly smal=
l problem. This proposal adds 6 new API points for the purpose of changing =
the order of codecs in createOffer, which seems like a high cost-benefit ra=
tio. And while the use cases listed here are helpful, they seem somewhat co=
ntrived to me, since it seems unlikely that the application can make better=
 choices about bandwidth or power consumption than the browser.



Without a specific, concrete example, I remain unconvinced t=
hat this is worth doing in the 1.0 timeframe. Post-1.0, we can probably fin=
d a way to provide this sort of lower-level control.




On Sat, Jul 12, 2014 at 9:41 PM, frankli=
n blek <franklin.blek@gmail.com> wrote:



Hi,


The draft seems to explain codec preferences in a good way.


I think this has a good potenitial to=C2=A0be a part of=C2=A0WebRTC1.0=
.




=C2=A0


On Sat, Jul 5, 2014 at 10:26 AM, Kiran Kumar Gud=
uru <kiran.guduru@samsung.com> wrote:






Hi,


A new version of codec preferences draft has been published, by modifyin=
g as per the review comments received.


Please review and let me know your comments.


=C2=A0


Thanks & Regards,


Kiran.


=C2=A0


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


Sender : internet-drafts@ietf.org<internet-drafts@ietf.org>


Date : Jul 02, 2014 18:28 (GMT+09:00)


Title : New Version Notification for draft-guduru-rtcweb-codec-pr=
eferences-01.txt


=C2=A0

A new version of I-D, draft-guduru-rtcweb-codec-preference=
s-01.txt
has been successfully submitted by Kiran Kumar Guduru and poste=
d to the
IETF repository.

Name: draft-guduru-rtcweb-codec-prefere=
nces



Revision: 01
Title: WebRTC Codec Preferences
Document date: 2014-07-0=
2
Group: Individual Submission
Pages: 7
URL:=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http://www.ietf.org/internet-drafts/draft-guduru-rtcweb-codec-p=
references-01.txt



Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc/draft-guduru-rtcweb-codec-preferen=
ces/
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/draft-guduru-rtcweb-codec-preferences-01



Diff:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://www.ietf.org/rfcdiff?url2=3Ddraft-guduru-rtc=
web-codec-preferences-01

Abstract:
=C2=A0=C2=A0 WebRTC specif=
ies to implement a minimum set of required codecs to



=C2=A0=C2=A0 ensure guaranteed interoperability between WebRTC peers.=C2=A0=
=C2=A0WebRTC
=C2=A0=C2=A0 allows browser implementers to support vendor =
specific codecs apart
=C2=A0=C2=A0 from mandatory codecs.=C2=A0=C2=A0Thi=
s document specifies the way for
=C2=A0=C2=A0 JavaScript applications to=
 give preferences for media codecs in



=C2=A0=C2=A0 WebRTC context out of the available codecs in browser for crea=
ting
=C2=A0=C2=A0 the offer / answer.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0


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



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

The IETF Secretar=
iat



=C2=A0


=C2=A0


















--001a11c2bdaa2c5e7104feabbb20--
--001a11c2bdaa2c5e7304feabbb21
Content-Type: image/gif; name="201407050656727_QKNMBDIF.gif"
Content-Disposition: inline; filename="201407050656727_QKNMBDIF.gif"
Content-Transfer-Encoding: base64
Content-ID: 
X-Attachment-Id: c52c5aec3d8c59b0_0.1

R0lGODlhCAKQAMQAAAAAAP///8k6OspMTNRiYtt0dOSOjumiovLExPfZ2fvt7f/+/uvr69TU1Lm5
uYyMjG9vb0dHRzMzMyoqKgICAv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEA
ABUALAAAAAAIApAAAAX/ICOOZGmeaKqubOu+cCzPdG3feK7vfO//uYBwSCwaj8ikcslsOp/QqHRK
rVqv2Kx2y+16v1YReEwum8/otHrNbhcX8Lh8Tq/b73al2M3v+/+AgYKDVniGh4h1egyEjY6PkJGS
k0OJlpd5SXsBDQ6engwNjFKilHoNSaVYqkisTK5CoUqdo02waLJMubGogg6Nt1S/a3IIeAoJmHAJ
CnTIipq1EBETFBERDRHDUdqmSQ8PSd1GENzbR+NN6UPgqRPYr+Hrae1MDhFE94MUfA3hRvOKlHPC
z8xAIXIG4EFQAJGBOQWMzWEIDckmIfqEBFR3zhuWgk82DhGJrmOAekcy/zJpR5IMSiUqA8T8A5LN
yyc1l+QEU9MSxUMKD/2cs6iIyggQKExAxSCCtVoBmlKgIC/pBEZSIzBw8I/ryWr/hDSYRjUpvq9U
ozpdGiBp2rZTyzUAO9BqLyHt3IZt22Cs03Jm0YbzS2HgA2sTfj0AixfxNqlsszLqtjgtuAfDMA+p
BlgpqgdJh82d8ACpZ7VPiUA4HNlp2tVKHVT7NbewWKUR9kpNy4Azvt6F8SGdIBg1W71C7CY/rTru
ycr/kiYlAm620+hxm4o9K5ax5Las+04gvTschL5kD8LFBmFCZ9twp8NlO6S21uJfE7dNygD6+kpx
NGTAAQMQkIwCBAxggP+AySTw0AEJPmTAAAU4SIABBiQDIYUKDCVHUflwd81JgJWomlz8UMMABCay
OFdyDzBAgXh3OTBjA1T1JsqNS5VG4lxbEVeaCEut1hQ+i/VHHDsPACkbEdrYuGNfFDggI41SXnml
jVbyiGWV7CDZYjnaXDmXP+CcNWOY/ly12En3xeLiiKDtZ+dISOLDIicpCucmPuTlFkBiMu61J47g
HZnoiFWK4KWPoDkppJuTKkmdVjomieiQ8uHl5o38DKkjW3Vu5gCOK5pIp1YuHpqiJzNeWV+VNjIi
ao+shkoplPLE6OWVbyLlKI04bpPQAgU0dICAByiQLLLGUDSAMQMkkMD/tAgMoICzCChQLbIHeBgH
iEMc9Ys+a8pIhBg2BiCoumsiqh8F/dUVVkYFaVPqaj6KIBsjvQCcGL0yCTcMfc8ByQmUnpzVTaj2
ZqTvQIntCw7F2/TLSLyvWgyOjEGG6O7BaBbB0rn4pFtTN/qw++pzBb8Y85KrrctIuwT7mHPKeNmr
8b8Lj7OU0HdFxUnF/7yMKJMFC1GQwA7sqV93GMmKKMtIhuPyyBKfw49KUHdzNckjDUYijKXKo5i9
AfQUh0IRLSBtM8tCK3dD3yazgEI/xd3ggOLCQS5GIqLc9lRTEWHfy2037jR4Lx6G+L1qasQV4jlS
E2N8TK01MOHuYp6x/3mFFR2lw7+EijlmqNej7+quP6b5xkN0DHuvNZdrsOU3ndw05isbvvjIMN9j
I+LanPXS8AWhC3pBkk8V4+ych474PaIPARnSj49TUzv4GpcYkDXFBNLL+rQz/OmWE/H1Wdsb3332
3QkaPVUvUba64wi9bbe0cKBI3CgCobjt7W5wiNuECECAcDWEDoNrWvucJxYiTO1l8MLK19xTjnoU
LXwj82BUQtGeqPiDXnsaGcH0MY6iqa8/BLNc1xonwq7FToSx0x4JiUMwdenrH58JB2jWpDviDYor
e4EZ1vhnOsNdkHjgS14stqK8vTyxeTz7HV6AOMKxECcUh2mKaIxYtP8U/rB7w/heOMJnxl9wUGQy
AVlU0Je1QSWNa6hznwTb6D0yKq5g/KpgPdQGs4XxLwDHGiDeAtgQRS6AGcs6wAH7hoBl0c2BFTnC
RSRIPBaucUlOs1WKOigcIZ5lPKgAmqBA57goXcVdoNEaVU4pv2KxSFH9QthlaDmShrVvg5NhneVe
VCxVYoY4xRpCzXxoSq69MjftkBEoQeejTSXRd56UyTSXmLOXRbFtnynHmkjjPlHCsi2lRKfjjLnM
WQqhYr/BVVQQJrYq1QNiJ1GjBJUGptAUgV4gs9/u0heObuKxfbWTYD250sFQxfMuhLqHwnLzoiex
7JkFxQgi/efIAkj/ckHgWsCyEkCAZgxokg+MyAEegiBMQjAaRilc03DklHO0xz30okY1UEFTIjpF
meOZJgi7cVNkIiZGQcWHjaiRG+BMY57UUM/HksqwGY5nRUFV6C+KutWstiWo26ApOXuKCqJm1XVJ
bNl4wNS7WQrPGmDqZdNuyh/KrBFJ71jTYsZjqPHwR6z4GM07+FdUPs2Oqr2JKlTdkw/EQPOOvckr
de76uKW+Y4072SuKnFJWwx0GNH7NqS+N+M7EnMWyTR3PTxPLWHYc9avjSc5sjFjYQV2FH4mMVkNI
ysCGZCtZAiJAAQy0AAZS0lvDxVDgFhDBJpzKCH0xSi22ApUidAIK/9eNxXMxcpfsnsRW3NluSoqm
BytxwiT5gIp342iErdyFutA1CcLGOwvylsu+0MVvfGsR3fyuq2i7sO5jxCtemXzQvutNCXbPUSrr
vte8reCpfjUJYbF05ML2ha+F84Ff71I3HIh4RhysVQyJLKBDzZgDig3RXI9MYTGHQa+Ln+CXGdsY
DIuR8Y2x0B+PiEAZQA6ykO/AJB0bYchITrIcFNAsJTs5yDvOgieiTGUt/BgTzLhElp9siS0X48R6
C7KXtZxiMSNgzGM2hIjn4OU1TyTMSXYzi1NRXezWeRBGhgkYaHNn66q3zyaUQp4DrQmeArrQTbgy
HB5yCAMmwtFcbv+0if13AEkKudJAxnSQfwtpSN/hIct19HIN0EAlg/qBiDiCP0grhZtoQTNLWJFO
qLATLYQqiSVhWBJm0oRaxxQmu3tCOXitSQYcS9KX8HSkM23pIGsaE89WRrQDNOk7BMUOyqZDtoF8
bUscwXeEaAkrk+BrJpT7CucuwjpIQmwstHvcUHhfoo29aAqJtECWJhBxC7DAZAyoQAcqAIfs1u9H
ChxDzoJDwkccoQSSesQLGoAkLYShBBQgxRlS1sQbfm9+N4jj1xJusx+ZoH0T6OKPLJBHi8FASTpr
4P82EG9XqiEKEcAYG5p4xCVEIQedWOASt9syJKTvBBT95SjHULX/Ir5Se9+bQxOqEEsFnvSij0sy
siGNaVqTGhY9JRtb7Q/pyDkfF1ZmbVWqTUOXovbupOUvZV9OpwqZNb7KvSDKGWJYq8GW3FhDI4ep
HPjsXh53WWUyilHKXlrmGsw00ysjeY7d10NFvnCiHE7VE3rgHrqnKtMasuE8a3RD75SfWebaIqnR
CYAsZT3kWXXD0AJkr9KLQ2j2BnBWQ4i7Ujk0sKV761YcstUsbWVrWxE5KUkPiOnfe9RbHZpWcZu1
8ptfa+SlrlvQq3/moMfh5seXPe2VdfGKR0T12Tp9t4xfLW9ZC1sCesjyRd1I8jurWeJ/fe6z9f5m
ydzk14IAFJF//60nUqhmJ7c0J2KCgGQCAWJkI76SMFfxJEPyJK7VCUJyH+QRKEg1PeEwPvSyGP6g
FRSYK5P1OEnSLpziUCHzJhbUTIXRFAXlgIJya0dUK4dCHCqyJ9pwJqhSRK7CQvyQOyg4gSyIFCxk
ODxoMFkyIyuoOLQSK/TigzE0QsfSe7NXaYwmSR2lW3vTIHDDEJZmINqCQLJ3cwzHSAfEcovmUrUn
Ug+hEJWGAKx3N1gIfnXIEMuXhUt2YtoHB5W2hye1DHnofin3PxoHLXdYSYwGOClFLQi0LXIThsPX
SF4YN3lDiT8RFH7zc5LEN3gDhog4LhyjRIajMlCUJlIEDkBTVv//oEsUUzIWmISziA2vZCXZNChg
xycnSEN3VE/npIs3gRU6k0opY4y+KDNWsjWr1DFsAzpbww/WsIsJdU/EsxVJ+DvgdVAj0w3qokc2
9IxWSGkDUI4SF21diEDXFoYGFBFBQRGq120/AUDF8EBz+IjFZTdyGC7mSCGaFhHZYo4RYY8jp2/P
EhT3CIjN5iHrOIqYplKWplL96IaQCI8JInBCh0Dp2JCOtIYKVCClBopreEAdyVznY4q/gzmdhBQw
JkSkcx7WMxWjwzuU1TRRgjlSVESuIZN9xDS+iEbzcz1t9Q5ZREHOw4rccTRwZUS2MzlFNDyJ4R7t
okfWmA7ZaJT/TIg6PZlQNrQ/U3SFlqYh+TaKjlSG3gItBnRzZfgTF8JoAZSHi1SPCklJ01eG+/gT
27KIeNkhBMlwyUCPCSlSC/lA69cMZ+lID1lJEamYy4BA+ohAaEiSJiZAl0gthqmJD8SJlYRymCaS
ZomZpKhBKElBQUMboAd6MANGQzNGPnlGtciN/nJalddCTNmLNtg4fUSby8MWWLlOPIOUVfNE3tgx
XFRETzQNuUEN/1RISuNL3AQ67NONv/CNXNk6xfmV/kNSzeBRy0eHZHmJklQ3b3gtuKd79VZt37Jy
3TaJyWAgdAkhjLaPXwiH1xJ91KIhcdgMpfaWCRSXnamfI6ct/+63cuLphYm5fAGoneBCl55JN5So
hulIoJbomJrZe8AnkhI6ioIjUKOZThZ1MDqYM2nyTlzxG1X4JtbkNK5IPHolTsOSPiZaL/lEHcN2
m/h0GHAyR2KXD0vCKOZRUD/6kwA1IwaFFDnagxhVRAYFYzaiHj9JQx0EAdnkI4LyVNGpLyYIjqgz
UWGhaMVVUqTGQIuWIMaQjvBIIenZLQxUagiiIIS5npPIQM2wnnTIQKeWQMZwfXAgnyf3LfqGhn1a
cy3ne3bKeggZniBZkHaacgKXDIjJhd0SpmgoqY4ZN8YVXBdSLfT3nYyaphSKp8jVll96po2qocxF
VvlUGm9VU/9G9FMlBDOIpVNSFVQu6SlX9VWXw1n5gSI06FeLVRM09VPWyFr80BS+ehNBVUKI8UrL
SjvtoFmwlRTZsFadBVtCpSehRSW+kkQ2ClUzog9LNSKClZXtIx05MR4zVFvYqXDClwCTJnyJsGJv
Boh0Y49uKQfuegd6WG2WsGJGBwfEdWLwCmZ1MLB1IGfLEGbyiggGm692sLAkFmQLewgLW7EG+1Ia
xgn4lbFOUGAF9hwfu2HlghUV1l/nxV35QGFLgGEwUQv0sg0vmwrdRV7olWCKM2FOwLGExgtLoBlL
oz0Vpjgd4aXLhgcQQiA4F5mXsFxAhiALUodFG7VSO7VAFgj/rlZly6lHWCsMs+SkUUC0VDsHcxhA
/IoI/+pkRtdkYbu2bNu2gTBlW4sE1xS3wnC1ULAJuxBgQgtdgIZEYJC3OGsEnxC0W6C3WsAKnTC4
h8azMPExXICNcFu4gdtegwYgIwZnbftIZXYMmMu5dUBiZbtpSztkz5Bmn7stnXuwqZsHm6ASxLZU
ACFj17AYXhsGHWQenNRr16CrWzBsSbkF6TAN1XANk/tuXwFai9uz2xCut6oJtUsOudsEItgKezEH
F5K5jwSpiDBtC4FqctCZTwandRAuIwlklEkH9wotTKtwDzJyLNa64fW7WwQFPjJPlduxSZluSAAS
DZYF+msF//NgvL9Gbr1AhFNglSKCa3A0awe8SkbwEvg6XNibmMu2XNy7ttu2tN47B+K7vo55CSNU
RNQEHaMxPdLDF150EAjzXP5BGEMUWGSBHWwBFhczjZjnFPfhd3HyONBZQtAha2qhlHKRHusxFkIM
eKlRH3y3efAReFMjwilceJmHGjvcNqNQCt8hFVGaGLJhG3vVCyrBEiWkHIyhHFpcxHLBGUhcxYOi
HW7XJJO3UQppABIRc+5qaZUUB/8omAnickD3UX8zc/wGcCSnIA7XQAdgccD1cwPXpiA1YirHhYV8
cS9HXCRlyODij3KKLFlIyC93jgxkcfVGXHZ8sBHCIJdcfv89R2oVV6dB53Ozd8mVtnGG7CAH9yHw
W0SagkLn4SpcA1AJVQQycipLISU4glSdkCMhuCsiCA7FpCcm8nZ7wb/itIxSeCZnw4FNSCW+xIFt
0ysWpBjacM1nwiUDXCupwotGMiJ7kkLJQVHKNCa9wRWvxIFzsTmcVIOKwcw9siu3BILd7IHfHIwY
UQ6vdESo4iKWW1xGx2iwVyGc2GyaJoclRZ6yR56KpADm53rTd3/Bx2TNIoAgRYADYp7ft36fGFIe
VTe953yf6H+vl9IPjXskR1LFJ1IldXszjb7UZ4krx53YIqAAKXHo94gQkrYd3UD8Z4iCk8sjjIJa
czOvMhP/mRUxleNMMEI0BNU46MJT0ji/tXMNO+U4FlMzFLUkxpNH7yMzOgPWFdQfOTkxJHrO8CPV
VpyjqEijp4GKK1QyyhhsMmENOsXDWh1sS9HXXG2LeJFFL1EzNaOMO2q5y4cgeAqZhanHliafBySJ
2eKQ2ssQ3mmAa6hpqjefZ1mGdUOIbUiSEyfaqAuXHolzMu2FnE2JD2ogJZkQ9YqWrY1SeBrajvjb
GreHK0WXTV0LrltHP7k+o1U70xXZwNlKo5UmorPV8naS0DPNnxDM9yNMRog8M/Q+GUFBLyE512BD
/xDAp3UWzPM8KtleewI8hwQ+OElasuEJd5Evw8A+O1kl/zkh3utN1lb0DowVExAcQBRSqog5IN47
0YK5p5MMmhQM2oTpn2OY2f24hkPxE+BLUivnLL8XkOUYl3EDvo6UyrYtdAPphXTwjpbo4ZldqQJI
kJREQC5F4ZV93Eqsy3fUDmQ31b+bDrFk1YQ93apaQdatjXMk4FqrtSJUKMSREbH5SwXzmtmtxMaI
3gglwhlxRc9TH+UCSqSJCs0ji3Vt3/Kr3ySajQtT5olt5W49F58gb3F04AuKACd14gpSkDHu4JEp
4Z8dEbB9qKIN4Y3p4pWokAf0l/yGuqS2l7H94KC5nymelqD9wcdGmYwehzL+E8GtvhoX2jiekSFc
O71gP/89XlDmFJ1hjhXjcxU6MlSwggryFOt1JG8ceuXBrLXG5C7NGE7h/TsrquvapBFx7QlGdWEB
ftc4WqUeOk1xVSeC8qGwdE/hhOZGAD2BJW/1K1rndN3D7tZE+DDDEk2o4D+q3ZECt7m919kOjtpw
E56JWJaOmtKCWZ8BIkneuXKPvKftmdI3x5cnddr4Gekm7oXw/ph1g9G0DWf8boloCEA13n7uyXre
MuOSXu90aQyl7ilMZSupHq2ixWvtcR2y5R6VJ91Zh/Ksxas+blqGtSbEfkg8bK2N0QuLwVlWBfN7
xaxubVvuAfPEw1V0ffJ/5Vgxfw42ElQAA1e0cVb/kPP/a9Iew8BrT7NWpumABJ7GsWVb6cP0TP5O
d1En0PpZ7QCI3qstHZnakJwsmq0QYToh0bfIBLIsBrqmc6qQBGKO3SdwebqmDb6mKX1yDXQtwxWe
wvUtminpoxj32vLoCoEgZOrZ+Ar4imhzknSpv72mjAb43TcgiC+nDMpcm+RetjC5FlY0NhtT6yVe
HlZhOksKOkYLFlGylRuy6YVdAEaz+PWxrl+zFYb7SPD7KCuyUWH7VGCyJosJg7hkoZuw+ApnEctm
z+8MZxYHCPtInSuvHRJm7rq5WgZn1z98q8tkKrb98DqxI/auZeawy/D8ktTxjSDAdFv/9n8EhkBq
4I+9//wPAos4kqV5oql4KKr7wqlyLAHDBLm+873/A4M5xkNoPCKTyiWz6XxCo9Kd65CIYbPaLbfr
/YJdNkZYlGiV0yTEtYSInU8JBLocV8feWb25ruKLAOJxCboUqtxxJZosdi3GCR6eFNo05DQ44EA5
TD01aB4xWOrcpB3QDJYZEKAuHLwNxBQUKgwUtH0l0MymjryexGYFr7Se/A6LIPcKwxxn8cYYlECT
/FJ7nVbTKMcqSKso1zhE2FBEjD5RdDo9FCGN75Quz2td84bvFZgWL1974ae4R2+gCH+pAE57Y3BL
NhP4EOgDZyIAPHhS1K3L6MPiEDK+BhC4oqCArRYGDv+AnIMKwaldKAu0eGkA14IEBAZ8K7DKFyp9
NkvWvPltxE9pKEOuSIkTaNESM0/d3IVzgYGUrqoiOAkSwc03I0G+IsBqJlWrUFk5ZSq04EtXKX8i
1XcWVVWkZatqW1DgZZ2jCZbC1Ot2ajWrXwNrJcB1wJvEixUS08tXcNnAcHWl1HfYpF8SM7/aTTq1
6q1VBsj69bs34kgSe20V3Fn3yoECYmlkW5pT72ird8NRJBeBAoQh5GyQazCBeI7j7XYQN4dDOYUJ
DR5wCoA9AITq6LR3d0C9OMUJE9x1t679QQRNED4Nb29jOYTjHYmGPECAqrTTevef9hdbubn0lwII
MEb/AisKoMVYX6jEspdkCywo4QgLVsiCCCOxMIBLFLJgYUEsEXDgfvrpApN+rgRWgD62zaCPfwIG
OIt+M5xYIoLVwKQTiAxuU+BeQLK4QCw37libiSx6gwyBE244pIcTxjLAGaHZpAuA/Unj4n8x6vVi
ibUZGdmUEh7ZozRoKSklf296SeYINso1lJFXJvAXAggqMBIb+ZU45CxIHWAnThwaSYeSKyJ54jYG
IHpkfjBxxSReJQSnnXo5qPdAcecxcF4AGD2nAwVFRFCEqOx5yul1EzDgwAQ7sIcDqKkGMIEDDlBA
RHuyrgdBEcpxVxwExhYXgX1j+PLNNlcIaGEsitUy/8M2xBQqgmL4BaKPMg1FSAO0+y0AEbflvgiI
QK5YQa65c7IEIbpQ5tfTG9mY22e5R+6SFSqKgeuaV392Wya7er0hEpn8JkNvArwIyJPBDY048bVW
1lSNs3fWFOG9NJjLC77emlkyLwcu0AKYAmEc7RvvjkimviO03PC7Nm7Myyz+bUvzFeYGYyHA8ub2
M8kh//twwsBVtOyxue46a6akupMD1TbYUKs6wArrqg7PARscsRQFgGuu12FHTqsUWMKAOr1qt6w8
B9NcNzRHniTXtew2RM27QJcQsE1oITiA4RHNO689sBBT+OECBxyyHjbae7C5P5F08CzQUN4wvCP8
Tf+y5vfe5CXDZZJkOGN35xUMxQhbXKZ+17w+jMeWp4t77K5fSztIXrJs98uIIzzSgtUQwPrN8QqM
cJbcFBz05MzLvjfgIau+uh5Mk8NRAMo1sPVx8Fxtag7PPVCdsme3OhwF72e3HkXvvx+B9+7D347b
ZXNC//uj5sB7c2vINlR2uzL95SQH4122KMSHSs3rW/IymgHeNbNyuSt3n+OdBf3QuTJJTlvUExnI
9NEzhm1OD0PzXMXmAEHAja4WRqtew6BxBdZJjHfN02EszlCbVhDQSAaE3ciIWMLdmSxhf5ohy4bI
C5gVTwEJ2AlRYnSt5QVRZ28ggH9IEAwYQmOFNPz/4tE0eMPtTaRpPJjA08JGvvNVDYDrAV+mjqUr
/l2CVkWwyA0skgn75fE5qYIbRr4nRwF6JCgYnBCZfCSnm5SMXQZCECAwhqbASWNH2wIabQx1w37t
0EydhJy8zEUmAfXtYxGMCQpZ4pPTOcko0rDk3rIxCwiajm5pStkAZmAUJ9WyGOsqWomo0gqbLFJC
jVRlCItISyRmq1C4zF24ivRE4u2MBrXAD2dAGJFZILNSWiyLIKakQNe9UpcL/FAsTKmZXkazG7jI
lPe4Q4HssK1sRcin2awGx7CtTzlSY085QFGqfK7tBmwjqNuIUIQHTOA4uAIWruoTj0RSpSsdI8kN
/8ViFznlJjJH6VkgQFJMZfzFRUeyxbZegjHQmbQF11jFjg7mUpp8sJ2a8ShuKlfEVXDRSiipDR14
qs4RMIij+xJLC3RIU9twcT+wTBlUpZFUSOYwMiOgKQ8zahuarCJBKbUkM3P3U7FccoEpSx7GPCob
xfTQFmRN3IhSipatJg8pYlleRhP01JeFg6Un3ZBRA5abvDa1Y5Cq6lpto9MR0HNZ8/uaeWDFHfP0
U47PqSwEpGYO45iHPHA8nzkQGlrknPY54XNH+IbDCYFG9KJuqMOB0HDLOigwBbrQFk1qIokNAaK2
SKUDI35brt4C1w95QC4iaJKnNTC3BMI1g3HZcP9cGFgXdISIbrkOQdzkeuG5LphuufyQ3ZR99wUH
Qu6ehqvcQNThvA30Isomwd3hFjcQNJGEEFqlA0zsoAHfAUImgiCeIMQKFALewYERXOAhDJhZsgDE
Kt5LgloYwDYE2TCHO+zhD4M4xK4gad1EPBEgQDR+GllxJ+b2Ag354r4bOoWFTWzjG+M4xzouQ3tN
wA8bG1jFLB4yFG7QA1HEI8JENoKQEaxkIHxiyQaWsg+Q/L0m88DKQ9ayk5fMCS4nAcwQ3ggUFkyK
J1P5yGhWsxKw/AQkRxkJYjaCkXVQHO/VM81AKGQQ7ixZIQBSzzzgM5X9PL8/2zlTRM7zRhC9DnX/
lGoJkdajDwg9BNFWuTiTnrSgG01nTcfRCJbehHCwjGkdMFoIdfZnqjsdhVG7egmwHjKfOT1oRQ+5
1Qx2dEZsfQRf+3rUuoaHr2P9BF3rWdfC5jUQVt0d+0WUOQ3QNH14ANE7jqc56UuVeXAwSG5b1jmo
2ra3kcMcTUnn2dM2t3yE5Z0dvGfawzk1RE/1vc4eqzuiqPa02diDb/vTnpvqjrSXI596x1He50a4
Pc/xHvOUygFVe7as5n2+5cSRAcNRj8alw530cZw+yal22TqLavPYWz5lA0XH2w1yWd3ze8tRj9oS
PnNLfHs66kv4zmV+boykxxIYF/h3MM6eoT+H/+AZtzi6h1WfUz373sPx1GfXzR0BP70466YOet73
qVOpluQ53wE53K2r5XDC7DD/cnxwECrilN0S6Uv3Zxk+DokHMNRVVvA9eWUJtpGvf+hw26ty9QCN
7/Pw/sbVqUKVrH2ONuWQP1aoMsHPB4RvV2VHVtnUtiz7+Z3wpGAb+HjlbQjYSvHY6RUoTIV6xmuK
CLOqVagagKtUEZ6OAWQb4d0mHutkfhwMOFb4tP3fvueT96TfVNzAU6znr4+gwtI4OW61zwfPD/PW
6drYcvC0p60vArAi6B0JCuk4lp8ckoea29BveVUdHvYQlb2mXkV/ykocVsBqh3JiJTXvo56u+P9e
6ZFe41mH361W7VkE6CkfJlSfePQK7VkHRKGN4SHeqIwbdHRe2YyfcAhHBz7f98VfqTWUPmVe7h3g
OWBEZv3AqgHQAmreqFjCd/iX9p2P+jUHJzzHCuog5MnP1bwNDhzYDMIe+cygOgDS/cQgHp0PeQgL
DMpcE6ZaPr1RoHGczI3DsDjfx6GaREmcE0IesamK5bWe+OSgf3XNDY6BDJYDHpEPDrDH2LwRg0nN
E87K05hK2yBhD2ZK25if/PxX1uDgHNVh1YyNsMghDlqhAzIh84mhP/GfZX0H3IgHGqZNwIHecfAg
DHLiOUhNgU2Hrojh2PwhIPoTIIFNqcmPEbb/IdwQFCBNh/yBITwIINyoWhkqWiZqSqCNVgCNzyCi
og8Go2b54A7KkZ1Vh6iYYSHtIa7xDxSSFv1cohv+4hT6IgDhzz11nHn8Hq7M3ftUDQyWijE+oqcQ
lAaKo/9UjcaByqj4DzUekv34zyB2YeTpntW84zASW/3g4KbxIzFaRKQF5OrRjyL6TwxmY/w8IgAl
HXFMIqWth0VsoibmYCdWpP3IzcaJYs350SBOWjOmIh6FpP+8zTUCUnooo3aoI7EJC7ORAi5a5Cew
yte4A3Z8IjDyIQ/+YOTxJEZU4sGFofq5XTMqITQCoiVAoRth5A/4pCJmhyXgof0gZQQIC2vt/9oZ
guEL1tz3EEeomSH/lMp33EC/HSPOccIc3t1xGBmhWUTX2NGt5ZE+euJUMqQhqscctsNA1mNEqiUO
NKMhwUOgfcdCnt/3EIEtHtJ1zCJFPiNj6mJjXqQfDR956GJe3iQxaqBciuQe0ePfmaTEAWVd5hE8
hE8a3iI6euE49B8XXsKsAMvlydEw6uQO4lwxQh4gpUqrhEpQ6lPzJeHnLSEvyoq3TWOgXZ5FxJnV
FEHXQJom2t5r3ZMAqma4haMX9l/taSUgLkfrZSf/rGY/dc3+TNSs/GZvWhRCFQdb8t5dnpsOjOdm
BgdA9WM4Ss36AKHQxVE+KaPcpWfzKaDnzf8HOhDmepzjHeWgCcLKf2LiEm7irPieRbIe2wBS8G0l
bJbPKfJhYGaocOwReS5nqelmSg6nPi0gJZ6mDnBjapZdRDHfZcXctVnWbAojH3ZWRNkmAMFWOYjf
06QoVw6HWTrjY/LiZZlHLmYHjMaKF0IHi/rlfOzoodkoRInfclbWVeJRjaJerujKVjbfGm3pgdbo
//moqLRWzJUnbKlNtHkmHYaWJuRTgJUWJ2gmZ81KYaJoaNXpaMFoHO3pLiafk/pbaYbKkx5fVUKi
4mFWgFUpkaKeRF7kgmqp+AVnDF7bnZmDjbqNoSIpZpqPZmpmmb5WZZWacuzop8BKmCraOc7/WkfE
A/b1wK5sBDoAmCes2SXET4KRAvbhahTMKpQ1WYNZTazE6n+pGCYomJvxQK/uKrzp3bKeWZPFymCi
GZcZaxCYWRQOqxAAK4Gt2bUG2HdUKw8A66xuq60aWIT16pVtAnf6wLWm67siqxRE65kdma4WWLp6
n961ILsaW792mlf6KxB0Fr8GLJOxYMEibMIqbJoNrJwR7MJCbK9FrHbU6sR+j75abMZq7MbSSsW+
JMeCbMiK7MiSbMmaLBO44Mmq7MqybMu67MvK68PC7MzSbM3a7M0qbMri7M7ybM/67M+irMwC7dAS
bdEarcrq7NEq7dIybdMWbNI6bdRK7dRS/+2bCW3VYm3Wam3U6qwE7IDXAgHYBoHXiq0EmO3X8oDZ
qq3YCkHZrq0OgO3anm0AsK0P1C3coi3czm0OxO3b8u3Xym3Y7q3bsu3dBu7fhm3b9oDh6q3a4i3d
+i3d8u3bxm3aPq7kjm3aRu7dQm7hNm7eJm7nDq4TRK7dYi7g+i3hgu7lli3qHu7klm4SOC7r7u3p
/gDnrqHlPu7rGu7ski3inq7n6m7jUu7wIi7n4u7k3i7otu7xsu7lQu/z2u7iZi7wzq71bu7iym3t
Tm/vXm/wAq/10m7g1m3zTm/wpq70gq/zii/1Gu/Ytm7ysu/yDq/50u/5Iu/2yu/+ou7qXv+U+4Zv
++Zt5VauAOPv/XYv7Bbw+w4w9ZrvAwtw4b5u/f6t/gaw5vqu+kIwA5evAgOw8IouBg9u7YJwBH/w
7hLvBmOuCvsv+m4v+/6u6a6w6GawCE+w/kpw7Oou4aavBa/vD2cZd8Zw5zKv+xKwCbsu966u5wrv
C58v5AIu2qpw8z6wElfvDFdw/wIwFv8wD3vvDdtuB0MvFVPwBZdwF39w+iLx+rJwCn8vF2PxEFsu
BOdwEYev/C7BAmfx58qwC1tx7rYv45qxB6tu9MquHQNxGDMBGSPxBuOwFV/vAtuv/0qyBhuy4hpw
345uAYtxIityEl/y9xYy9kayAk/yII//8e46Lu6Wbymjchc/Mg1PcANbMuwi8imzagDL8SfT8i5P
wRDrMRzzMhJ0cB2rsitHQSWbsSBPsfoegRj3rRHjbTDz7hxf8hZfcR+38TNvMQhzMv6+sDKDMzLf
cRPgcCOPLxrvXR638Dd7cSTHsjVf8O2esw3PcgszMPP6cBKf7Sg/sQw3synbsw4XLDALLh6Trgbv
Mz9zb+m6MzHz8TwbQT3L8h8bsiivsRfvqz2/LzPvMQJD9PyaMh6TNDdnMzbnczmH7kpntDOj9Ehz
dExrb+wyMumCcRl7Mj7rtC47L0JL9DwLMku/9E5rcy3/swsyc1AT70dT9D9T8jAbcEgT/7VTU3VT
Gy8uw+9M6zM5v3RQK7VSv3Ix260Tc7AbjzAyW/VQL/M093Fbwy9ZV/Q7W/QykzVGR/RRtx5Yp7QU
X3NfY3JYL7Ja/3RVK4E3F/ZgIzb/ovQpn/EB7/VP+/JFS/YV+/Qjk208y/Nj+7RjD3Zlx7NeTzXu
MkAL8PNf/3VTp7Vbw3Vqt/NCU/RrLzRlx7by6u1JCzYrzzJcw/RYEzQHnzVvi/Js169wa0T+1rVw
o/Y+s/Zb33NotyBpb210S/d0G+1o1wB1Y3d2azfMWvd2e/d3gzfHdnd4k3d5m3esjfd5q/d6s/cU
jLcTa/Lo3rJAQzZV+/Vmi/BEV+9X2/92URuBAAC4AOgAgA94gBd4EBB4AAS4gSu4gB9Bgjd4gUM4
hPsAhR84ECx4hu9Ahlu4Eiz4hROxX/P2Ejc3Udv1Y9+3UI9zidc356Y3LUtxQ7u05AY3W/fvKtM3
Z4v4Uusyjuu4P39xP+94gnN4DhC5gx+5kSP5kit5kz+4g0d4lCd5g394lEs4g/dAh284lDt5lnO4
loO4Nsd2QO+0RW+zjBtx9tKzbv/4VcdvlUE3DJ8wQ89tNct5JzP2ZG/14TbxVb8yF+c5TmM4k0v5
klf5lCM6of83lCd6lW95l2M5lXu5EHw5pQv4hFc6gfuwYhu1LIcuK7u0HiMvUKu4Xp//MSNH9osb
NA1HryNjMArTOE579UzntkqL9CeLtQdHNWdb9ZEfOqEnupMH+6L7OoNP+aNbuYd/OZczAYFbuKM7
umbLeh5L8JyjbxQ/cTBD9myjdhkf8ZHFefe+8bhL76gfr4/Xsp238xKncgLzeCCvsZ4jAbQzOpYX
e6MbO7P/wK9feZgLu6Ev+xIse6TzgLNz+bCHeGdr9TET90STsEnvsFuD9GGH8LkLObhftwVru7i7
MnzD+i5XMSQ/vJ+PMVf3OU+Lc5BHtsDrO7Ij/BMkOZh3OaS3vMwPvMwjeMAXupOHPCL395DFdzgD
9Ij/vGV/NBsfPSmEe5qrcSc89Hxn/zut0/QbqzaMn3ZfUzFmTwHCD7ylbznOV3i9X7mGN7vO57yX
Y3q873rbjrnWJ/PQD7XRT7wco/oTv/htL3Zpf7y7I70WT/xU8zSsu3GnC/q8F7m/DzvOg/2+iz2y
z7zitzyVR3vYLzo77/rGr72J67etC74tc/w64Hm5J30uK7zD13U3v/mNX7zHqzglC73eNzaQD7R8
e73jd73kH/vtJ7u/F7zOEzymV/qk277ZDzraH37C6/j95jCL2zcQ1zPrQ79gOzM0Y3us80DK5PXP
l/WfZ7b2c7zGu73mQzVhb37z737aOz7lz7zw9/7Zpz/7L/76oz+x+z6z43zQ3/Pvrv/6IWcuCEiB
KAajiZ7pWq5o2b7uHM9unZLuojC5BAy2hMIbEfgr2mRLpg3XjD6lqhcxCr1ZjzOB9ytIgcdNL2oM
Npm76HWg7Waf4ba2mE51wcPLbN8Jc+RXRQNoIjiY2CdoxPXXhMPjk0dZaXmJmam5ydnp+QkaKjpK
Wmp6KiWJusra6voKGys7S1tLqmqbq7vL2+v7CxwcgCtcbHyMnKy8fNvD/AwdLT1NDUssFZQzckW4
nX2YOeQ4pEU5uKXdXYW4sqeG9sZnmpYXd2f/jh9v1x6mL/evnrx3ZQYKzBSHXz55awLe+0JwIUQ2
bszAizenosF9F+vwucbuD5SRLMD/lTz0TV0NcY7QKVFXbh3KloXu9ItoMyM9jmQeWpyYZg/DhhDJ
7Izy0+jGORwxSjyqBw9TnDp7OqWicapWOVcPOrWHjyhVnku3LiGK55pJlkp0xEzXtlwMGHJT4ljp
JO8UkyrubuFmVuzNsQH1afyJMyvGpAMZF6QatOziogYRI62M2ezXjQ4HXwXrz45gShdBR306mHFk
rJkjqu1bci4jlYQCjYMbO503wHzvzja09vc5skA5U04tNWdT5YoRH3V8NnQ/ywCP2+xM3PTYzVEV
ek7Y0ePTiVw/h5862vzjy6ddOzs5FzjfbuTWysUtf7hu/TSQ6O0fEmsPBcYHduNp/6feZFYRt153
UPm04GSV/KNYTgY2aBpoFU7YmGTRVaiaTgS6o9UaPCiwwF9x9aZbbfDN15tdetFlzm/GiNahVRce
ViB59MAD3WZhCUUQdaetdqBkQg2FVo7nCdTkktwtx1prnCSFXEQXTtcjCgygWFMS2iDC30y8vbUX
mVmsRCYLjKhp5kvZkdeeFCQOSKWWxRUZWnN0kiZdYX1KV+eVe0bHpXcLbSced1LaOaiihuqJyY/y
fJkimpeMdCaMe0ES5iOe+IUNopBeImiTN4nF6qCJ/VmVn12tap1nBSnUaoOodgmejl3OasmWDvZE
omBD4srrpWBqGpJ+pLa4WzZ4Uf8x3LOQ2OhpgIUyumujjqkqYj6L9rpUhkNNGSuhtgLLFbm6cqsc
lQjulF6V65qqWYk+GpdluAFgGic3pDqrBZyfenqwigJTy/BJXsWb6JJPcrloow5SVK6VTNVLa5JG
4luex792S5iHHD8G3sPwOjTkvcoBTO1s2iqsCZs0/RfzzdGm9N/MEM/JypYsK1mWpNd5+HPI77p8
mdGFOo1echlNDfSwD+ar2Z3lwVxN115/DXbY0XAtdtlmn4122qSQrXbbbr8Nd9psx0133XbfLczc
eO/Nd99+r71stAjjDG3CMOU2U+GFv6mwf40j7NuKKs7Y6X4z7uf44SesCRPPirj/ia3DNeqs+Hyc
s1R6zz6nrjl8L30uKi1cDxwmYM6GHheNMiVOuIvZJuybpprzZq3D9eWl+/HbyGAbXc/WZzuoB7Ml
p/Cmx05C7tLzPnj38Qn+O4vGQz55964wMEn4JJFfquj2bS4+bPG/Ja31zb+ouB/KF5+E49+4Jb/d
yQ+A9nkeOuRTsOltr2Dr856Y4pO9hcVPf4f7nuXGFxy78AyBvTtf+sCnuwu67wm4K+AET1iI462O
gOIAh/8kSD/QbRCDLoJefkyIGwP+bobzQ94CrfAD0Z0OgQSMCfU+1UDahG9362tgEmeBvhh2Dmdl
cuBu1pG55KkOiE8UYRd9WJfM/1kieuLTYhnr17/OZTFOWwxii2A3xvwxgRxFQN0Ns8UmIRqxEf6D
0f9qFyoopo9xU4ScGH+InyIisYMAstG0mnczC6LEep3Aix3L6ELLVbGQcVReD3f2OgFS0Ydm9IYA
N5lJPy4OEM1inxpRGYooNoyGrAtY9WgEwFZ+EpSwpKQMK3et1dkSjnuEjQUVyUs/ilFNdOwZI6fg
yVI185Ss3CAzmXc5Z+5SeNFsXStkqT7QUa6XNXGe9FSYhy8ukHQj3FnsKkFMDJrzevwJYQedGM5G
hvJ9v/zjNNGJQsMxEVo6FCU/uWezXIAzme7E4ori2chUMtSUVCwhIlf5TCWiie1TLYGoG+FHn1cK
jAvxtKQv04Q4ac7RoW9c4ztDGghm7ZOhtwnYQWGxUP7V0p7tVKn5AvnTzVHwpZIkKvCAyroqIhOk
PX1pLefYpvYJFKlMpeo903lRQDbVmzz1YP+qt1VvDhOrY3VqgLLIUeKdaYXA9B0fXyec0G01rWBN
Klk54VFf5tV89cyqEeXKSHKCYqF/K6xhD4vYJRA2sYxtrGPrttjHSnaylPVaZCuL2cxqNm8f3Kxn
PwtaQYZ2tKQtbSnQh9rUqna1rG2ta18L29jKdra0ra1tb4vb3Op2t7ztrW9/C9zgCne4xP1tCAAA
Ow==
--001a11c2bdaa2c5e7304feabbb21--


From nobody Sun Jul 20 21:14:24 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854D31B2CA1 for ; Sun, 20 Jul 2014 21:14:23 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -5.184
X-Spam-Level: 
X-Spam-Status: No, score=-5.184 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJnjY7VyIStA for ; Sun, 20 Jul 2014 21:14:20 -0700 (PDT)
Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C381B2A9E for ; Sun, 20 Jul 2014 21:14:20 -0700 (PDT)
Received: from epcpsbgr4.samsung.com (u144.gpu120.samsung.co.kr [203.254.230.144]) by mailout3.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N91006RCNRU4530@mailout3.samsung.com> for rtcweb@ietf.org; Mon, 21 Jul 2014 13:14:18 +0900 (KST)
Received: from epcpsbgx2.samsung.com ( [172.20.52.124]) by epcpsbgr4.samsung.com (EPCPMTA) with SMTP id CA.13.13369.9939CC35; Mon, 21 Jul 2014 13:14:17 +0900 (KST)
X-AuditID: cbfee690-b7fb56d000003439-af-53cc939907ea
Received: from epmailer03 ( [203.254.219.143]) by epcpsbgx2.samsung.com (EPCPMTA) with SMTP id 28.D7.22787.2939CC35; Mon, 21 Jul 2014 13:14:10 +0900 (KST)
Message-id: <38.D7.22787.2939CC35@epcpsbgx2.samsung.com>
Date: Mon, 21 Jul 2014 04:14:10 +0000 (GMT)
From: Kiran Kumar Guduru 
To: Justin Uberti , franklin blek 
MIME-version: 1.0
X-MTR: 20140721034940086@kiran.guduru
Msgkey: 20140721034940086@kiran.guduru
X-EPLocale: en_US.windows-1252
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20140721034940086@kiran.guduru
X-ParentMTR: 
X-ArchiveUser: 
X-CPGSPASS: N
MIME-version: 1.0
Content-type: multipart/related; boundary="=_NamoWEC-fg44f0yf5w"
X-Generator: Namo ActiveSquare 7 7.0.0.45
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMJsWRmVeSWpSXmKPExsWyRsSkRnfm5DPBBl+n21is/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJ5nX9kK+r4xVTzcvZ+tgbH/DVMXIyeHkIC6xIbV99hAbAkB E4lTK5+zQ9hiEhfurQeKcwHVLGWUWDFnJlxR16cWVojEHEaJlY3tYB28AhYS2x/MApvKIqAq 8XjJF7A4G1DDrxNrGEFsYYEoiRM3IepFBEIlFiycCjaUWSBConHOGlaIi5Qk1l69yQoxU1Di 5MwnLBCLVSUufFvFDBFXk2ia3skMEZeTWDL1MhOEzSsxo/0pC0x82tc1UDXSEudnbWCE+Wzx 98dQcX6JY7d3APVygPU+uR8MM2b35i9Q/wpITD1zEKpVS+Lkmd9QcT6JNQvfssCM2XVqOTNM 7/0tc5nQnc8s4CRxcdkpqHpNiUeLWlkmMCrPQlKGzoZpgbANJb7Me8wIYStKTOl+yA5h20mc 3DODBVNcVeLKkWvMsxjZwWom52BTMWvxf9YFjNyrGEVTC5ILipPSi0z0ihNzi0vz0vWS83M3 MQJT2Ol/zybsYLx3wPoQ40RGYMxOZJYSTc4HJsG8knhDYzMjC1MTU2Mjc0szWgorifOqPUoK EhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cA4+5xZhs+k0MqvT+xmXOitaH/FwXnyW2fc+dZf pk931qqYhpxzlVtmtZzl5unaZZ+0eWR7LQwv19RXT/mx7xzrwbtxueWmSWVBuj0W3cysZxOn PHzZ33Fb73X/pWcq2/mS3fui+0xe+n6a2HHm/ZpkAbfNBzfX+Nx6JDE5Qb+pZbGHyq+MHD4l luKMREMt5qLiRADhdrYCpgMAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELsWRmVeSWpSXmKPExsVy+t/tft1Jk88EGzyZIG2x9l87uwOjx5Il P5kCGKPSbDJSE1NSixRS85LzUzLz0m2VvIPjneNNzQwMdQ0tLcyVFPISc1NtlVx8AnTdMnOA pioplCXmlAKFAhKLi5X07WyK8ktLUhUy8otLbJWiDc2N9IwM9EyN9AxNY60MDQyMTIFqEtIy ep59ZSvo+8ZU8XD3frYGxv43TF2MnBxCAuoSG1bfYwOxJQRMJLo+tbBC2GISF+6tB4pzAdXM YZRY2djODpJgEVCVeLzkC5jNBtTw68QaRhBbWCBK4sRNiBoRgVCJBQungg1lFoiQaJyzhhVi mZLE2qs3wWxeAUGJkzOfsEAsU5W48G0VM0RcTaJpeiczRFxOYsnUy0wQNq/EjPanLDDxaV/X QNVIS5yftYER5ujF3x9Dxfkljt3eAdTLAdb75H4wzJjdm79A/SsgMfXMQahWLYmTZ35Dxfkk 1ix8ywIzZtep5cwwvfe3zGVCdz6zgJPExWWnoOo1JR4tamWZwCg7C0kZOhumBcI2lPgy7zEj hK0oMaX7ITuEbSdxcs8MFkxxVYkrR64xz2JkB6uZnINNxazF/1kXMHKvYhRNLUguKE5KrzDS K07MLS7NS9dLzs/dxAhOmM8W7WD8d976EKMAB6MSD+8C5jPBQqyJZcWVuYcYVYDmPNqw+gKj FEtefl6qkgjviQygNG9KYmVValF+fFFpTmrxIcb9jMA0MZFZSjQ5H5jm80riDY1NzE2NTS0M DM3NzQaPsJI4r/ytpCAhgfTEktTs1NSC1CKYF5g4OKUaGC327Hk91eKzdfCZpxLlrx0Kbt7n rfad5RMxuXD6nB3Gnm989c4lXD+7gV9knfHiZ9HLH30K2m+WGL48wGL777s5yus8Mtctn/5g NbNcYanXG7OlJq9KLdjNOAOmV2loXOLYbrv40EU7eXuvsE/vL0+wm+semBNjw8i0VPfYt1l1 f6ZZPvq2S0yJpTgj0VCLuag4EQDyGXW9RQQAAA==
DLP-Filter: Pass
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/udQEPwYnw-MINeniboAtG-PpzxQ
Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" 
Subject: Re: [rtcweb] New Version Notification for draft-guduru-rtcweb-codec-preferences-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: kiran.guduru@samsung.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: Mon, 21 Jul 2014 04:14:23 -0000

--=_NamoWEC-fg44f0yf5w
Content-Type: text/html;
	charset="windows-1252"
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PHRpdGxlPlNhbXN1bmcgRW50ZXJwcmlzZSBQb3J0YWwgbXlTaW5nbGU8L3Rp
dGxlPgo8bWV0YSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9d2luZG93cy0xMjUyIiBodHRw
LWVxdWl2PSJDb250ZW50LVR5cGUiPgo8c3R5bGUgaWQ9Im15c2luZ2xlX3N0eWxlIiB0eXBlPSJ0
ZXh0L2NzcyI+UCB7CglNQVJHSU4tVE9QOiA1cHg7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJpYWw7
IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiA5cHQKfQpURCB7CglNQVJHSU4tVE9QOiA1
cHg7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJpYWw7IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1T
SVpFOiA5cHQKfQpMSSB7CglNQVJHSU4tVE9QOiA1cHg7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJp
YWw7IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiA5cHQKfQpCT0RZIHsKCUxJTkUtSEVJ
R0hUOiAxLjQ7IE1BUkdJTjogMTBweDsgRk9OVC1GQU1JTFk6IEFyaWFsLCBhcmlhbDsgRk9OVC1T
SVpFOiA5cHQKfQo8L3N0eWxlPgoKPG1ldGEgbmFtZT0iR0VORVJBVE9SIiBjb250ZW50PSJBY3Rp
dmVTcXVhcmUiPgo8L2hlYWQ+PGJvZHk+CjxwPkhpIEp1c3Rpbiw8L3A+CjxwPkkgZG9uJ3QgZmVl
bCB0aGUgbnVtYmVyIG9mIEFQSSBhZGRpdGlvbiwmbmJzcDtpcyBhIGJpZyBwcm9ibGVtIDopLjwv
cD4KPHA+SSBmZWVsIHRoaXMgaXMgdmVyeSB1c2VmdWwgdG8gYWRkIGluIDEuMC4gSSBkb24ndCBr
bm93IHdoYXQgbWFkZSB5b3UgZmVlbCB0aGUgZXhpc3RpbmcgdXNlY2FzZXMgdG8gYmUgY29udHJp
dmVkLiBBRkFJSywgYXBwcyBoYXMgdGhhdCBpbnRlbGxlZ2VuY2UgdG8gYW5hbHl6ZSBvbiB0aGUg
YmFuZHdpZHRoIHV0aWxpemF0aW9uLjwvcD4KPHA+Jm5ic3A7PC9wPgo8cD5PbmUgdXNlIGNhc2Ug
SSBtaXNzZWQgaW4gdGhlIGRyYWZ0IGFuZCBJIHdvdWxkIGxpa2UgdG8gYWRkIGluIHRoZSBuZXh0
IHZlcnNpb24gaXMsIHRoZSBwcm9ibGVtIGFyaXNpbmcgYXQgZ2F0ZXdheXMsIHdoaWNoIGNhbiBv
bmx5IGJlIHNvbHZlZCBieSBhcHBzLCBidXQgbmV2ZXIgYnkgYnJvd3NlciBhcyBleHBsYWluZWQg
YmVsb3cuPC9wPgo8cD4mbmJzcDs8L3A+CjxwPiJDb25zaWRlcmluZyB0aGUgdXNlY2FzZSBvZmYg
YW4gYXBwbGljYXRpb24gaXMgc2VydmluZyB0aGUgbmVlZHMgYmV0d2VlbiB3ZWJydGMgY2xpZW50
IGFuZCBub24td2VicnRjIGNsaWVudCAoSU1TIGZvciBleGFtcGxlKSwgdGhhdCBkb2VzIG5vdCBz
dXBwb3J0IHRoZSBtYW5kYXRvcnkgY29kZWNzIHNwZWNpZmllZCBmb3IgV2ViUlRDLCB0aGVuIGdh
dGV3YXlzIHdpbGwgc29sdmUgdGhlIHByb2JsZW0gYnkgdHJhbnNjb2RpbmcuIDwvcD4KPHA+SWYg
YSBicm93c2VyIGlzIHN1cHBvcnRpbmcgY29kZWNzIHdoaWNoIGRvbid0IG5lZWQgdGhpcyBraW5k
IG9mIHRyYW5zY29kaW5nLCBidXQgZ2l2aW5nIGxvdyBwcmlvcml0eSB0byB0aGVtLCB0aGVuIGFj
Y29yZGluZyB0byZuYnNwO2V4aXN0aW5nIHNwZWNpZmljYXRpb25zLCB0aGUgZ2F0ZXdheSBoYXMg
dG8gYWNjZXB0IHRoZSBvZmZlciB3aXRoIHByaW9yaXRpZXMgc3BlY2lmaWVkIGJ5IHdlYnJ0YyAo
Y29uc2lkZXJpbmcgdGhlIGNhc2UgZm9yIHdlYnJ0YyBjbGllbnQgYXMgb2ZmZXJlcikgY2xpZW50
IHRocm91Z2ggYW5zd2VyLCB0aGVuIGFnYWluIGdhdGV3YXkgaGFzIHRvIHNlbmQgdGhlIG9mZmVy
IHdpdGggaXRzIG9yZGVyIG9mIHByaW9yaXR5IHRvIGNoYW5nZSB0byBjb2RlYyBwcmVmZXJlbmNl
cywgcmVzdWx0aW5nIGluIGEgc2Vjb25kIG9mZmVyLWFuc3dlciBuZWdvdGlhdGlvbi4iJm5ic3A7
IEluIHRoaXMga2luZCBvZiB1c2VjYXNlcyBBUEkgYXJlIGtub3duIGFib3V0IHRoZSBwcmlvcml0
eSBvZiBjb2RlY3MgcmVxdWlyZWQgYW5kIHdlIGNhbiBhdm9pZCB0aGlzIGtpbmQgb2YgdW5uZWNl
c3Nhcnkgc2lnbmFsaW5nIGlmIEFQSXMgYXJlIHByb3ZpZGVkIHRvIGFwcHMgdG8gcHJpb3JpdGl6
ZSB0aGUgY29kZWNzLjwvcD4KPHA+Jm5ic3A7PC9wPgo8cD5JIGhvcGUgdGhpcyBleGFtcGxlIHdp
bGwgYWRkIHNvbWUgbW9yZSB2YWx1ZSB0byB0aGlzIGlkZWEuPC9wPgo8cD4mbmJzcDs8L3A+Cjxw
PiZuYnNwOzwvcD4KPHA+LS0tLS0tLSA8Yj5PcmlnaW5hbCBNZXNzYWdlPC9iPiAtLS0tLS0tPC9w
Pgo8cD48Yj5TZW5kZXI8L2I+IDogSnVzdGluIFViZXJ0aSZsdDtqdWJlcnRpQGdvb2dsZS5jb20m
Z3Q7PC9wPgo8cD48Yj5EYXRlPC9iPiA6IEp1bCAyMSwgMjAxNCAxMjozMCAoR01UKzA5OjAwKTwv
cD4KPHA+PGI+VGl0bGU8L2I+IDogUmU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh
ZnQtZ3VkdXJ1LXJ0Y3dlYi1jb2RlYy1wcmVmZXJlbmNlcy0wMS50eHQ8L3A+CjxwPiZuYnNwOzwv
cD4KPGRpdiBkaXI9Imx0ciI+VGhpcyBzZWVtcyBsaWtlIGEgcHJldHR5IGJpZyBoYW1tZXIgdG8g
c29sdmUgYSBmYWlybHkgc21hbGwgcHJvYmxlbS4gVGhpcyBwcm9wb3NhbCBhZGRzIDYgbmV3IEFQ
SSBwb2ludHMgZm9yIHRoZSBwdXJwb3NlIG9mIGNoYW5naW5nIHRoZSBvcmRlciBvZiBjb2RlY3Mg
aW4gY3JlYXRlT2ZmZXIsIHdoaWNoIHNlZW1zIGxpa2UgYSBoaWdoIGNvc3QtYmVuZWZpdCByYXRp
by4gQW5kIHdoaWxlIHRoZSB1c2UgY2FzZXMgbGlzdGVkIGhlcmUgYXJlIGhlbHBmdWwsIHRoZXkg
c2VlbSBzb21ld2hhdCBjb250cml2ZWQgdG8gbWUsIHNpbmNlIGl0IHNlZW1zIHVubGlrZWx5IHRo
YXQgdGhlIGFwcGxpY2F0aW9uIGNhbiBtYWtlIGJldHRlciBjaG9pY2VzIGFib3V0IGJhbmR3aWR0
aCBvciBwb3dlciBjb25zdW1wdGlvbiB0aGFuIHRoZSBicm93c2VyLgo8ZGl2Pjxicj48L2Rpdj4K
PGRpdj5XaXRob3V0IGEgc3BlY2lmaWMsIGNvbmNyZXRlIGV4YW1wbGUsIEkgcmVtYWluIHVuY29u
dmluY2VkIHRoYXQgdGhpcyBpcyB3b3J0aCBkb2luZyBpbiB0aGUgMS4wIHRpbWVmcmFtZS4gUG9z
dC0xLjAsIHdlIGNhbiBwcm9iYWJseSBmaW5kIGEgd2F5IHRvIHByb3ZpZGUgdGhpcyBzb3J0IG9m
IGxvd2VyLWxldmVsIGNvbnRyb2wuPC9kaXY+PC9kaXY+CjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJh
Ij48YnI+PGJyPgo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gU2F0LCBKdWwgMTIsIDIwMTQg
YXQgOTo0MSBQTSwgZnJhbmtsaW4gYmxlayA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1h
aWx0bzpmcmFua2xpbi5ibGVrQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZyYW5rbGluLmJs
ZWtAZ21haWwuY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbjogMHB4IDBweCAwcHggMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyBib3JkZXItbGVm
dC1jb2xvcjogcmdiKDIwNCwgMjA0LCAyMDQpOyBib3JkZXItbGVmdC13aWR0aDogMXB4OyBib3Jk
ZXItbGVmdC1zdHlsZTogc29saWQ7IiBjbGFzcz0iZ21haWxfcXVvdGUiPgo8ZGl2PkhpLDwvZGl2
Pgo8ZGl2PlRoZSBkcmFmdCBzZWVtcyB0byBleHBsYWluIGNvZGVjIHByZWZlcmVuY2VzIGluIGEg
Z29vZCB3YXkuPC9kaXY+CjxkaXY+SSB0aGluayB0aGlzIGhhcyBhIGdvb2QgcG90ZW5pdGlhbCB0
byZuYnNwO2JlIGEgcGFydCBvZiZuYnNwO1dlYlJUQzEuMC48L2Rpdj4KPGRpdiBjbGFzcz0iSE9F
blpiIj4KPGRpdiBjbGFzcz0iaDUiPgo8ZGl2Pjxicj48YnI+Jm5ic3A7PC9kaXY+CjxkaXYgY2xh
c3M9ImdtYWlsX3F1b3RlIj5PbiBTYXQsIEp1bCA1LCAyMDE0IGF0IDEwOjI2IEFNLCBLaXJhbiBL
dW1hciBHdWR1cnUgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86a2lyYW4uZ3Vk
dXJ1QHNhbXN1bmcuY29tIiB0YXJnZXQ9Il9ibGFuayI+a2lyYW4uZ3VkdXJ1QHNhbXN1bmcuY29t
PC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjogMHB4
IDBweCAwcHggMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyBib3JkZXItbGVmdC1jb2xvcjogcmdi
KDIwNCwgMjA0LCAyMDQpOyBib3JkZXItbGVmdC13aWR0aDogMXB4OyBib3JkZXItbGVmdC1zdHls
ZTogc29saWQ7IiBjbGFzcz0iZ21haWxfcXVvdGUiPgo8ZGl2Pgo8cD5IaSw8L3A+CjxwPkEgbmV3
IHZlcnNpb24gb2YgY29kZWMgcHJlZmVyZW5jZXMgZHJhZnQgaGFzIGJlZW4gcHVibGlzaGVkLCBi
eSBtb2RpZnlpbmcgYXMgcGVyIHRoZSByZXZpZXcgY29tbWVudHMgcmVjZWl2ZWQuPC9wPgo8cD5Q
bGVhc2UgcmV2aWV3IGFuZCBsZXQgbWUga25vdyB5b3VyIGNvbW1lbnRzLjwvcD4KPHA+Jm5ic3A7
PC9wPgo8cD5UaGFua3MgJmFtcDsgUmVnYXJkcyw8L3A+CjxwPktpcmFuLjwvcD4KPHA+Jm5ic3A7
PC9wPgo8cD4tLS0tLS0tIDxiPk9yaWdpbmFsIE1lc3NhZ2U8L2I+IC0tLS0tLS08L3A+CjxwPjxi
PlNlbmRlcjwvYj4gOiA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0
YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZsdDs8YSBocmVmPSJt
YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQt
ZHJhZnRzQGlldGYub3JnPC9hPiZndDs8L3A+CjxwPjxiPkRhdGU8L2I+IDogSnVsIDAyLCAyMDE0
IDE4OjI4IChHTVQrMDk6MDApPC9wPgo8cD48Yj5UaXRsZTwvYj4gOiBOZXcgVmVyc2lvbiBOb3Rp
ZmljYXRpb24gZm9yIGRyYWZ0LWd1ZHVydS1ydGN3ZWItY29kZWMtcHJlZmVyZW5jZXMtMDEudHh0
PC9wPgo8cD4mbmJzcDs8L3A+PGJyPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1ndWR1cnUt
cnRjd2ViLWNvZGVjLXByZWZlcmVuY2VzLTAxLnR4dDxicj5oYXMgYmVlbiBzdWNjZXNzZnVsbHkg
c3VibWl0dGVkIGJ5IEtpcmFuIEt1bWFyIEd1ZHVydSBhbmQgcG9zdGVkIHRvIHRoZTxicj5JRVRG
IHJlcG9zaXRvcnkuPGJyPjxicj5OYW1lOiBkcmFmdC1ndWR1cnUtcnRjd2ViLWNvZGVjLXByZWZl
cmVuY2VzPGJyPlJldmlzaW9uOiAwMTxicj5UaXRsZTogV2ViUlRDIENvZGVjIFByZWZlcmVuY2Vz
PGJyPkRvY3VtZW50IGRhdGU6IDIwMTQtMDctMDI8YnI+R3JvdXA6IEluZGl2aWR1YWwgU3VibWlz
c2lvbjxicj5QYWdlczogNzxicj5VUkw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3
dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZ3VkdXJ1LXJ0Y3dlYi1jb2RlYy1wcmVm
ZXJlbmNlcy0wMS50eHQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVy
bmV0LWRyYWZ0cy9kcmFmdC1ndWR1cnUtcnRjd2ViLWNvZGVjLXByZWZlcmVuY2VzLTAxLnR4dDwv
YT48YnI+U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ndWR1
cnUtcnRjd2ViLWNvZGVjLXByZWZlcmVuY2VzLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWd1ZHVydS1ydGN3ZWItY29kZWMtcHJlZmVyZW5j
ZXMvPC9hPjxicj5IdG1saXplZDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ3VkdXJ1LXJ0Y3dlYi1j
b2RlYy1wcmVmZXJlbmNlcy0wMSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9y
Zy9odG1sL2RyYWZ0LWd1ZHVydS1ydGN3ZWItY29kZWMtcHJlZmVyZW5jZXMtMDE8L2E+PGJyPkRp
ZmY6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWd1
ZHVydS1ydGN3ZWItY29kZWMtcHJlZmVyZW5jZXMtMDEiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8v
d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1ndWR1cnUtcnRjd2ViLWNvZGVjLXByZWZl
cmVuY2VzLTAxPC9hPjxicj48YnI+QWJzdHJhY3Q6PGJyPiZuYnNwOyZuYnNwOyBXZWJSVEMgc3Bl
Y2lmaWVzIHRvIGltcGxlbWVudCBhIG1pbmltdW0gc2V0IG9mIHJlcXVpcmVkIGNvZGVjcyB0bzxi
cj4mbmJzcDsmbmJzcDsgZW5zdXJlIGd1YXJhbnRlZWQgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVu
IFdlYlJUQyBwZWVycy4mbmJzcDsmbmJzcDtXZWJSVEM8YnI+Jm5ic3A7Jm5ic3A7IGFsbG93cyBi
cm93c2VyIGltcGxlbWVudGVycyB0byBzdXBwb3J0IHZlbmRvciBzcGVjaWZpYyBjb2RlY3MgYXBh
cnQ8YnI+Jm5ic3A7Jm5ic3A7IGZyb20gbWFuZGF0b3J5IGNvZGVjcy4mbmJzcDsmbmJzcDtUaGlz
IGRvY3VtZW50IHNwZWNpZmllcyB0aGUgd2F5IGZvcjxicj4mbmJzcDsmbmJzcDsgSmF2YVNjcmlw
dCBhcHBsaWNhdGlvbnMgdG8gZ2l2ZSBwcmVmZXJlbmNlcyBmb3IgbWVkaWEgY29kZWNzIGluPGJy
PiZuYnNwOyZuYnNwOyBXZWJSVEMgY29udGV4dCBvdXQgb2YgdGhlIGF2YWlsYWJsZSBjb2RlY3Mg
aW4gYnJvd3NlciBmb3IgY3JlYXRpbmc8YnI+Jm5ic3A7Jm5ic3A7IHRoZSBvZmZlciAvIGFuc3dl
ci48YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxicj48YnI+PGJy
PlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo
ZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp
ZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvIiB0YXJn
ZXQ9Il9ibGFuayI+dG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj48YnI+VGhlIElFVEYgU2VjcmV0YXJp
YXQ8YnI+PGJyPgo8cD4mbmJzcDs8L3A+CjxwPiZuYnNwOzwvcD4KPHRhYmxlPgo8dGJvZHk+Cjx0
cj4KPHRkPgo8cD48aW1nIGJvcmRlcj0iMCIgc3JjPSJjaWQ6QkVJMFhUNE5aNUpFQG5hbW8uY28u
a3IiPjwvcD48L3RkPjwvdHI+PC90Ym9keT48L3RhYmxlPjwvZGl2PjxpbWcgYm9yZGVyPSIwIiBz
cmM9Imh0dHA6Ly9leHQuc2Ftc3VuZy5uZXQvbWFpbGNoZWNrL1NlZW5UaW1lQ2hlY2tlcj9kbz01
YjBmNjdhZjkwOTBkYTM1Mjc1ODU1NTIyNzA1Yzk3OGE2ZWVjMjNiZmZkNmY4MjM1MmNjYWFhNWU3
OGQ3OTE3ZGU2ZWVlMmJlODc0ZTA1MjNlY2QzMTQ2YmExZWRiM2VmNGJjZGVjZWQ0NmVkNWVlMDhj
ZWNlODU0MWJjMTRlYWNmODc4ZjlhMjZjZTE1YTAiIHdpZHRoPSIwIiBoZWlnaHQ9IjAiPjwvYmxv
Y2txdW90ZT48L2Rpdj48YnI+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48L2Rp
dj4KPHA+Jm5ic3A7PC9wPjwhLS1TUDpraXJhbi5ndWR1cnUtLT48IS0ta2lyYW4uZ3VkdXJ1OkVQ
LS0+CjxwPiZuYnNwOzwvcD4KPHRhYmxlIGlkPSJjb25maWRlbnRpYWxzaWduaW1nIj4KPHRib2R5
Pgo8dHI+Cjx0ZCBOQU1PX0xPQ0s9IiI+CjxwPjxpbWcgYm9yZGVyPSIwIiBzcmM9ImNpZDoyTEw1
WE9LMExLN0NAbmFtby5jby5rciI+PC9wPjwvdGQ+PC90cj48L3Rib2R5PjwvdGFibGU+PC9ib2R5
PjwvaHRtbD48aW1nIHNyYz0naHR0cDovL2V4dC5zYW1zdW5nLm5ldC9tYWlsY2hlY2svU2VlblRp
bWVDaGVja2VyP2RvPWY0ZmI3MGJhOGI3MmM5ZWM1N2YyYzFlMmIxNzRlZjgwNTU4ODdjMzU1ZjA2
YzM5YTUyY2NhYWE1ZTc4ZDc5MTdhNTg2YThjOTlkZmJmYmFiMGVkYmU2ODNjODUzZmU3MWRiOWZk
ZGRkYTMzZTgyY2JlNGEzOTE0MjRlNjJmY2Y2Y2Y4NzhmOWEyNmNlMTVhMCcgYm9yZGVyPTAgd2lk
dGg9MCBoZWlnaHQ9MCBzdHlsZT0nZGlzcGxheTpub25lJz4=


--=_NamoWEC-fg44f0yf5w
Content-Type: image/gif;
	name="201407210944267_QKNMBDIF.gif"
Content-Transfer-Encoding: base64
Content-ID: 

R0lGODlhCAKQAMQAAAAAAP///8k6OspMTNRiYtt0dOSOjumiovLExPfZ2fvt7f/+/uvr69TU1Lm5
uYyMjG9vb0dHRzMzMyoqKgICAv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEA
ABUALAAAAAAIApAAAAX/ICOOZGmeaKqubOu+cCzPdG3feK7vfO//uYBwSCwaj8ikcslsOp/QqHRK
rVqv2Kx2y+16v1YReEwum8/otHrNbhcX8Lh8Tq/b73al2M3v+/+AgYKDVniGh4h1egyEjY6PkJGS
k0OJlpd5SXsBDQ6engwNjFKilHoNSaVYqkisTK5CoUqdo02waLJMubGogg6Nt1S/a3IIeAoJmHAJ
CnTIipq1EBETFBERDRHDUdqmSQ8PSd1GENzbR+NN6UPgqRPYr+Hrae1MDhFE94MUfA3hRvOKlHPC
z8xAIXIG4EFQAJGBOQWMzWEIDckmIfqEBFR3zhuWgk82DhGJrmOAekcy/zJpR5IMSiUqA8T8A5LN
yyc1l+QEU9MSxUMKD/2cs6iIyggQKExAxSCCtVoBmlKgIC/pBEZSIzBw8I/ryWr/hDSYRjUpvq9U
ozpdGiBp2rZTyzUAO9BqLyHt3IZt22Cs03Jm0YbzS2HgA2sTfj0AixfxNqlsszLqtjgtuAfDMA+p
BlgpqgdJh82d8ACpZ7VPiUA4HNlp2tVKHVT7NbewWKUR9kpNy4Azvt6F8SGdIBg1W71C7CY/rTru
ycr/kiYlAm620+hxm4o9K5ax5Las+04gvTschL5kD8LFBmFCZ9twp8NlO6S21uJfE7dNygD6+kpx
NGTAAQMQkIwCBAxggP+AySTw0AEJPmTAAAU4SIABBiQDIYUKDCVHUflwd81JgJWomlz8UMMABCay
OFdyDzBAgXh3OTBjA1T1JsqNS5VG4lxbEVeaCEut1hQ+i/VHHDsPACkbEdrYuGNfFDggI41SXnml
jVbyiGWV7CDZYjnaXDmXP+CcNWOY/ly12En3xeLiiKDtZ+dISOLDIicpCucmPuTlFkBiMu61J47g
HZnoiFWK4KWPoDkppJuTKkmdVjomieiQ8uHl5o38DKkjW3Vu5gCOK5pIp1YuHpqiJzNeWV+VNjIi
ao+shkoplPLE6OWVbyLlKI04bpPQAgU0dICAByiQLLLGUDSAMQMkkMD/tAgMoICzCChQLbIHeBgH
iEMc9Ys+a8pIhBg2BiCoumsiqh8F/dUVVkYFaVPqaj6KIBsjvQCcGL0yCTcMfc8ByQmUnpzVTaj2
ZqTvQIntCw7F2/TLSLyvWgyOjEGG6O7BaBbB0rn4pFtTN/qw++pzBb8Y85KrrctIuwT7mHPKeNmr
8b8Lj7OU0HdFxUnF/7yMKJMFC1GQwA7sqV93GMmKKMtIhuPyyBKfw49KUHdzNckjDUYijKXKo5i9
AfQUh0IRLSBtM8tCK3dD3yazgEI/xd3ggOLCQS5GIqLc9lRTEWHfy2037jR4Lx6G+L1qasQV4jlS
E2N8TK01MOHuYp6x/3mFFR2lw7+EijlmqNej7+quP6b5xkN0DHuvNZdrsOU3ndw05isbvvjIMN9j
I+LanPXS8AWhC3pBkk8V4+ych474PaIPARnSj49TUzv4GpcYkDXFBNLL+rQz/OmWE/H1Wdsb3332
3QkaPVUvUba64wi9bbe0cKBI3CgCobjt7W5wiNuECECAcDWEDoNrWvucJxYiTO1l8MLK19xTjnoU
LXwj82BUQtGeqPiDXnsaGcH0MY6iqa8/BLNc1xonwq7FToSx0x4JiUMwdenrH58JB2jWpDviDYor
e4EZ1vhnOsNdkHjgS14stqK8vTyxeTz7HV6AOMKxECcUh2mKaIxYtP8U/rB7w/heOMJnxl9wUGQy
AVlU0Je1QSWNa6hznwTb6D0yKq5g/KpgPdQGs4XxLwDHGiDeAtgQRS6AGcs6wAH7hoBl0c2BFTnC
RSRIPBaucUlOs1WKOigcIZ5lPKgAmqBA57goXcVdoNEaVU4pv2KxSFH9QthlaDmShrVvg5NhneVe
VCxVYoY4xRpCzXxoSq69MjftkBEoQeejTSXRd56UyTSXmLOXRbFtnynHmkjjPlHCsi2lRKfjjLnM
WQqhYr/BVVQQJrYq1QNiJ1GjBJUGptAUgV4gs9/u0heObuKxfbWTYD250sFQxfMuhLqHwnLzoiex
7JkFxQgi/efIAkj/ckHgWsCyEkCAZgxokg+MyAEegiBMQjAaRilc03DklHO0xz30okY1UEFTIjpF
meOZJgi7cVNkIiZGQcWHjaiRG+BMY57UUM/HksqwGY5nRUFV6C+KutWstiWo26ApOXuKCqJm1XVJ
bNl4wNS7WQrPGmDqZdNuyh/KrBFJ71jTYsZjqPHwR6z4GM07+FdUPs2Oqr2JKlTdkw/EQPOOvckr
de76uKW+Y4072SuKnFJWwx0GNH7NqS+N+M7EnMWyTR3PTxPLWHYc9avjSc5sjFjYQV2FH4mMVkNI
ysCGZCtZAiJAAQy0AAZS0lvDxVDgFhDBJpzKCH0xSi22ApUidAIK/9eNxXMxcpfsnsRW3NluSoqm
BytxwiT5gIp342iErdyFutA1CcLGOwvylsu+0MVvfGsR3fyuq2i7sO5jxCtemXzQvutNCXbPUSrr
vte8reCpfjUJYbF05ML2ha+F84Ff71I3HIh4RhysVQyJLKBDzZgDig3RXI9MYTGHQa+Ln+CXGdsY
DIuR8Y2x0B+PiEAZQA6ykO/AJB0bYchITrIcFNAsJTs5yDvOgieiTGUt/BgTzLhElp9siS0X48R6
C7KXtZxiMSNgzGM2hIjn4OU1TyTMSXYzi1NRXezWeRBGhgkYaHNn66q3zyaUQp4DrQmeArrQTbgy
HB5yCAMmwtFcbv+0if13AEkKudJAxnSQfwtpSN/hIct19HIN0EAlg/qBiDiCP0grhZtoQTNLWJFO
qLATLYQqiSVhWBJm0oRaxxQmu3tCOXitSQYcS9KX8HSkM23pIGsaE89WRrQDNOk7BMUOyqZDtoF8
bUscwXeEaAkrk+BrJpT7CucuwjpIQmwstHvcUHhfoo29aAqJtECWJhBxC7DAZAyoQAcqAIfs1u9H
ChxDzoJDwkccoQSSesQLGoAkLYShBBQgxRlS1sQbfm9+N4jj1xJusx+ZoH0T6OKPLJBHi8FASTpr
4P82EG9XqiEKEcAYG5p4xCVEIQedWOASt9syJKTvBBT95SjHULX/Ir5Se9+bQxOqEEsFnvSij0sy
siGNaVqTGhY9JRtb7Q/pyDkfF1ZmbVWqTUOXovbupOUvZV9OpwqZNb7KvSDKGWJYq8GW3FhDI4ep
HPjsXh53WWUyilHKXlrmGsw00ysjeY7d10NFvnCiHE7VE3rgHrqnKtMasuE8a3RD75SfWebaIqnR
CYAsZT3kWXXD0AJkr9KLQ2j2BnBWQ4i7Ujk0sKV761YcstUsbWVrWxE5KUkPiOnfe9RbHZpWcZu1
8ptfa+SlrlvQq3/moMfh5seXPe2VdfGKR0T12Tp9t4xfLW9ZC1sCesjyRd1I8jurWeJ/fe6z9f5m
ydzk14IAFJF//60nUqhmJ7c0J2KCgGQCAWJkI76SMFfxJEPyJK7VCUJyH+QRKEg1PeEwPvSyGP6g
FRSYK5P1OEnSLpziUCHzJhbUTIXRFAXlgIJya0dUK4dCHCqyJ9pwJqhSRK7CQvyQOyg4gSyIFCxk
ODxoMFkyIyuoOLQSK/TigzE0QsfSe7NXaYwmSR2lW3vTIHDDEJZmINqCQLJ3cwzHSAfEcovmUrUn
Ug+hEJWGAKx3N1gIfnXIEMuXhUt2YtoHB5W2hye1DHnofin3PxoHLXdYSYwGOClFLQi0LXIThsPX
SF4YN3lDiT8RFH7zc5LEN3gDhog4LhyjRIajMlCUJlIEDkBTVv//oEsUUzIWmISziA2vZCXZNChg
xycnSEN3VE/npIs3gRU6k0opY4y+KDNWsjWr1DFsAzpbww/WsIsJdU/EsxVJ+DvgdVAj0w3qokc2
9IxWSGkDUI4SF21diEDXFoYGFBFBQRGq120/AUDF8EBz+IjFZTdyGC7mSCGaFhHZYo4RYY8jp2/P
EhT3CIjN5iHrOIqYplKWplL96IaQCI8JInBCh0Dp2JCOtIYKVCClBopreEAdyVznY4q/gzmdhBQw
JkSkcx7WMxWjwzuU1TRRgjlSVESuIZN9xDS+iEbzcz1t9Q5ZREHOw4rccTRwZUS2MzlFNDyJ4R7t
okfWmA7ZaJT/TIg6PZlQNrQ/U3SFlqYh+TaKjlSG3gItBnRzZfgTF8JoAZSHi1SPCklJ01eG+/gT
27KIeNkhBMlwyUCPCSlSC/lA69cMZ+lID1lJEamYy4BA+ohAaEiSJiZAl0gthqmJD8SJlYRymCaS
ZomZpKhBKElBQUMboAd6MANGQzNGPnlGtciN/nJalddCTNmLNtg4fUSby8MWWLlOPIOUVfNE3tgx
XFRETzQNuUEN/1RISuNL3AQ67NONv/CNXNk6xfmV/kNSzeBRy0eHZHmJklQ3b3gtuKd79VZt37Jy
3TaJyWAgdAkhjLaPXwiH1xJ91KIhcdgMpfaWCRSXnamfI6ct/+63cuLphYm5fAGoneBCl55JN5So
hulIoJbomJrZe8AnkhI6ioIjUKOZThZ1MDqYM2nyTlzxG1X4JtbkNK5IPHolTsOSPiZaL/lEHcN2
m/h0GHAyR2KXD0vCKOZRUD/6kwA1IwaFFDnagxhVRAYFYzaiHj9JQx0EAdnkI4LyVNGpLyYIjqgz
UWGhaMVVUqTGQIuWIMaQjvBIIenZLQxUagiiIIS5npPIQM2wnnTIQKeWQMZwfXAgnyf3LfqGhn1a
cy3ne3bKeggZniBZkHaacgKXDIjJhd0SpmgoqY4ZN8YVXBdSLfT3nYyaphSKp8jVll96po2qocxF
VvlUGm9VU/9G9FMlBDOIpVNSFVQu6SlX9VWXw1n5gSI06FeLVRM09VPWyFr80BS+ehNBVUKI8UrL
SjvtoFmwlRTZsFadBVtCpSehRSW+kkQ2ClUzog9LNSKClZXtIx05MR4zVFvYqXDClwCTJnyJsGJv
Boh0Y49uKQfuegd6WG2WsGJGBwfEdWLwCmZ1MLB1IGfLEGbyiggGm692sLAkFmQLewgLW7EG+1Ia
xgn4lbFOUGAF9hwfu2HlghUV1l/nxV35QGFLgGEwUQv0sg0vmwrdRV7olWCKM2FOwLGExgtLoBlL
oz0Vpjgd4aXLhgcQQiA4F5mXsFxAhiALUodFG7VSO7VAFgj/rlZly6lHWCsMs+SkUUC0VDsHcxhA
/IoI/+pkRtdkYbu2bNu2gTBlW4sE1xS3wnC1ULAJuxBgQgtdgIZEYJC3OGsEnxC0W6C3WsAKnTC4
h8azMPExXICNcFu4gdtegwYgIwZnbftIZXYMmMu5dUBiZbtpSztkz5Bmn7stnXuwqZsHm6ASxLZU
ACFj17AYXhsGHWQenNRr16CrWzBsSbkF6TAN1XANk/tuXwFai9uz2xCut6oJtUsOudsEItgKezEH
F5K5jwSpiDBtC4FqctCZTwandRAuIwlklEkH9wotTKtwDzJyLNa64fW7WwQFPjJPlduxSZluSAAS
DZYF+msF//NgvL9Gbr1AhFNglSKCa3A0awe8SkbwEvg6XNibmMu2XNy7ttu2tN47B+K7vo55CSNU
RNQEHaMxPdLDF150EAjzXP5BGEMUWGSBHWwBFhczjZjnFPfhd3HyONBZQtAha2qhlHKRHusxFkIM
eKlRH3y3efAReFMjwilceJmHGjvcNqNQCt8hFVGaGLJhG3vVCyrBEiWkHIyhHFpcxHLBGUhcxYOi
HW7XJJO3UQppABIRc+5qaZUUB/8omAnickD3UX8zc/wGcCSnIA7XQAdgccD1cwPXpiA1YirHhYV8
cS9HXCRlyODij3KKLFlIyC93jgxkcfVGXHZ8sBHCIJdcfv89R2oVV6dB53Ozd8mVtnGG7CAH9yHw
W0SagkLn4SpcA1AJVQQycipLISU4glSdkCMhuCsiCA7FpCcm8nZ7wb/itIxSeCZnw4FNSCW+xIFt
0ysWpBjacM1nwiUDXCupwotGMiJ7kkLJQVHKNCa9wRWvxIFzsTmcVIOKwcw9siu3BILd7IHfHIwY
UQ6vdESo4iKWW1xGx2iwVyGc2GyaJoclRZ6yR56KpADm53rTd3/Bx2TNIoAgRYADYp7ft36fGFIe
VTe953yf6H+vl9IPjXskR1LFJ1IldXszjb7UZ4krx53YIqAAKXHo94gQkrYd3UD8Z4iCk8sjjIJa
czOvMhP/mRUxleNMMEI0BNU46MJT0ji/tXMNO+U4FlMzFLUkxpNH7yMzOgPWFdQfOTkxJHrO8CPV
VpyjqEijp4GKK1QyyhhsMmENOsXDWh1sS9HXXG2LeJFFL1EzNaOMO2q5y4cgeAqZhanHliafBySJ
2eKQ2ssQ3mmAa6hpqjefZ1mGdUOIbUiSEyfaqAuXHolzMu2FnE2JD2ogJZkQ9YqWrY1SeBrajvjb
GreHK0WXTV0LrltHP7k+o1U70xXZwNlKo5UmorPV8naS0DPNnxDM9yNMRog8M/Q+GUFBLyE512BD
/xDAp3UWzPM8KtleewI8hwQ+OElasuEJd5Evw8A+O1kl/zkh3utN1lb0DowVExAcQBRSqog5IN47
0YK5p5MMmhQM2oTpn2OY2f24hkPxE+BLUivnLL8XkOUYl3EDvo6UyrYtdAPphXTwjpbo4ZldqQJI
kJREQC5F4ZV93Eqsy3fUDmQ31b+bDrFk1YQ93apaQdatjXMk4FqrtSJUKMSREbH5SwXzmtmtxMaI
3gglwhlxRc9TH+UCSqSJCs0ji3Vt3/Kr3ySajQtT5olt5W49F58gb3F04AuKACd14gpSkDHu4JEp
4Z8dEbB9qKIN4Y3p4pWokAf0l/yGuqS2l7H94KC5nymelqD9wcdGmYwehzL+E8GtvhoX2jiekSFc
O71gP/89XlDmFJ1hjhXjcxU6MlSwggryFOt1JG8ceuXBrLXG5C7NGE7h/TsrquvapBFx7QlGdWEB
ftc4WqUeOk1xVSeC8qGwdE/hhOZGAD2BJW/1K1rndN3D7tZE+DDDEk2o4D+q3ZECt7m919kOjtpw
E56JWJaOmtKCWZ8BIkneuXKPvKftmdI3x5cnddr4Gekm7oXw/ph1g9G0DWf8boloCEA13n7uyXre
MuOSXu90aQyl7ilMZSupHq2ixWvtcR2y5R6VJ91Zh/Ksxas+blqGtSbEfkg8bK2N0QuLwVlWBfN7
xaxubVvuAfPEw1V0ffJ/5Vgxfw42ElQAA1e0cVb/kPP/a9Iew8BrT7NWpumABJ7GsWVb6cP0TP5O
d1En0PpZ7QCI3qstHZnakJwsmq0QYToh0bfIBLIsBrqmc6qQBGKO3SdwebqmDb6mKX1yDXQtwxWe
wvUtminpoxj32vLoCoEgZOrZ+Ar4imhzknSpv72mjAb43TcgiC+nDMpcm+RetjC5FlY0NhtT6yVe
HlZhOksKOkYLFlGylRuy6YVdAEaz+PWxrl+zFYb7SPD7KCuyUWH7VGCyJosJg7hkoZuw+ApnEctm
z+8MZxYHCPtInSuvHRJm7rq5WgZn1z98q8tkKrb98DqxI/auZeawy/D8ktTxjSDAdFv/9n8EhkBq
4I+9//wPAos4kqV5oql4KKr7wqlyLAHDBLm+873/A4M5xkNoPCKTyiWz6XxCo9Kd65CIYbPaLbfr
/YJdNkZYlGiV0yTEtYSInU8JBLocV8feWb25ruKLAOJxCboUqtxxJZosdi3GCR6eFNo05DQ44EA5
TD01aB4xWOrcpB3QDJYZEKAuHLwNxBQUKgwUtH0l0MymjryexGYFr7Se/A6LIPcKwxxn8cYYlECT
/FJ7nVbTKMcqSKso1zhE2FBEjD5RdDo9FCGN75Quz2td84bvFZgWL1974ae4R2+gCH+pAE57Y3BL
NhP4EOgDZyIAPHhS1K3L6MPiEDK+BhC4oqCArRYGDv+AnIMKwaldKAu0eGkA14IEBAZ8K7DKFyp9
NkvWvPltxE9pKEOuSIkTaNESM0/d3IVzgYGUrqoiOAkSwc03I0G+IsBqJlWrUFk5ZSq04EtXKX8i
1XcWVVWkZatqW1DgZZ2jCZbC1Ot2ajWrXwNrJcB1wJvEixUS08tXcNnAcHWl1HfYpF8SM7/aTTq1
6q1VBsj69bs34kgSe20V3Fn3yoECYmlkW5pT72ird8NRJBeBAoQh5GyQazCBeI7j7XYQN4dDOYUJ
DR5wCoA9AITq6LR3d0C9OMUJE9x1t679QQRNED4Nb29jOYTjHYmGPECAqrTTevef9hdbubn0lwII
MEb/AisKoMVYX6jEspdkCywo4QgLVsiCCCOxMIBLFLJgYUEsEXDgfvrpApN+rgRWgD62zaCPfwIG
OIt+M5xYIoLVwKQTiAxuU+BeQLK4QCw37libiSx6gwyBE244pIcTxjLAGaHZpAuA/Unj4n8x6vVi
ibUZGdmUEh7ZozRoKSklf296SeYINso1lJFXJvAXAggqMBIb+ZU45CxIHWAnThwaSYeSKyJ54jYG
IHpkfjBxxSReJQSnnXo5qPdAcecxcF4AGD2nAwVFRFCEqOx5yul1EzDgwAQ7sIcDqKkGMIEDDlBA
RHuyrgdBEcpxVxwExhYXgX1j+PLNNlcIaGEsitUy/8M2xBQqgmL4BaKPMg1FSAO0+y0AEbflvgiI
QK5YQa65c7IEIbpQ5tfTG9mY22e5R+6SFSqKgeuaV392Wya7er0hEpn8JkNvArwIyJPBDY048bVW
1lSNs3fWFOG9NJjLC77emlkyLwcu0AKYAmEc7RvvjkimviO03PC7Nm7Myyz+bUvzFeYGYyHA8ub2
M8kh//twwsBVtOyxue46a6akupMD1TbYUKs6wArrqg7PARscsRQFgGuu12FHTqsUWMKAOr1qt6w8
B9NcNzRHniTXtew2RM27QJcQsE1oITiA4RHNO689sBBT+OECBxyyHjbae7C5P5F08CzQUN4wvCP8
Tf+y5vfe5CXDZZJkOGN35xUMxQhbXKZ+17w+jMeWp4t77K5fSztIXrJs98uIIzzSgtUQwPrN8QqM
cJbcFBz05MzLvjfgIau+uh5Mk8NRAMo1sPVx8Fxtag7PPVCdsme3OhwF72e3HkXvvx+B9+7D347b
ZXNC//uj5sB7c2vINlR2uzL95SQH4122KMSHSs3rW/IymgHeNbNyuSt3n+OdBf3QuTJJTlvUExnI
9NEzhm1OD0PzXMXmAEHAja4WRqtew6BxBdZJjHfN02EszlCbVhDQSAaE3ciIWMLdmSxhf5ohy4bI
C5gVTwEJ2AlRYnSt5QVRZ28ggH9IEAwYQmOFNPz/4tE0eMPtTaRpPJjA08JGvvNVDYDrAV+mjqUr
/l2CVkWwyA0skgn75fE5qYIbRr4nRwF6JCgYnBCZfCSnm5SMXQZCECAwhqbASWNH2wIabQx1w37t
0EydhJy8zEUmAfXtYxGMCQpZ4pPTOcko0rDk3rIxCwiajm5pStkAZmAUJ9WyGOsqWomo0gqbLFJC
jVRlCItISyRmq1C4zF24ivRE4u2MBrXAD2dAGJFZILNSWiyLIKakQNe9UpcL/FAsTKmZXkazG7jI
lPe4Q4HssK1sRcin2awGx7CtTzlSY085QFGqfK7tBmwjqNuIUIQHTOA4uAIWruoTj0RSpSsdI8kN
/8ViFznlJjJH6VkgQFJMZfzFRUeyxbZegjHQmbQF11jFjg7mUpp8sJ2a8ShuKlfEVXDRSiipDR14
qs4RMIij+xJLC3RIU9twcT+wTBlUpZFUSOYwMiOgKQ8zahuarCJBKbUkM3P3U7FccoEpSx7GPCob
xfTQFmRN3IhSipatJg8pYlleRhP01JeFg6Un3ZBRA5abvDa1Y5Cq6lpto9MR0HNZ8/uaeWDFHfP0
U47PqSwEpGYO45iHPHA8nzkQGlrknPY54XNH+IbDCYFG9KJuqMOB0HDLOigwBbrQFk1qIokNAaK2
SKUDI35brt4C1w95QC4iaJKnNTC3BMI1g3HZcP9cGFgXdISIbrkOQdzkeuG5LphuufyQ3ZR99wUH
Qu6ehqvcQNThvA30Isomwd3hFjcQNJGEEFqlA0zsoAHfAUImgiCeIMQKFALewYERXOAhDJhZsgDE
Kt5LgloYwDYE2TCHO+zhD4M4xK4gad1EPBEgQDR+GllxJ+b2Ag354r4bOoWFTWzjG+M4xzouQ3tN
wA8bG1jFLB4yFG7QA1HEI8JENoKQEaxkIHxiyQaWsg+Q/L0m88DKQ9ayk5fMCS4nAcwQ3ggUFkyK
J1P5yGhWsxKw/AQkRxkJYjaCkXVQHO/VM81AKGQQ7ixZIQBSzzzgM5X9PL8/2zlTRM7zRhC9DnX/
lGoJkdajDwg9BNFWuTiTnrSgG01nTcfRCJbehHCwjGkdMFoIdfZnqjsdhVG7egmwHjKfOT1oRQ+5
1Qx2dEZsfQRf+3rUuoaHr2P9BF3rWdfC5jUQVt0d+0WUOQ3QNH14ANE7jqc56UuVeXAwSG5b1jmo
2ra3kcMcTUnn2dM2t3yE5Z0dvGfawzk1RE/1vc4eqzuiqPa02diDb/vTnpvqjrSXI596x1He50a4
Pc/xHvOUygFVe7as5n2+5cSRAcNRj8alw530cZw+yal22TqLavPYWz5lA0XH2w1yWd3ze8tRj9oS
PnNLfHs66kv4zmV+boykxxIYF/h3MM6eoT+H/+AZtzi6h1WfUz373sPx1GfXzR0BP70466YOet73
qVOpluQ53wE53K2r5XDC7DD/cnxwECrilN0S6Uv3Zxk+DokHMNRVVvA9eWUJtpGvf+hw26ty9QCN
7/Pw/sbVqUKVrH2ONuWQP1aoMsHPB4RvV2VHVtnUtiz7+Z3wpGAb+HjlbQjYSvHY6RUoTIV6xmuK
CLOqVagagKtUEZ6OAWQb4d0mHutkfhwMOFb4tP3fvueT96TfVNzAU6znr4+gwtI4OW61zwfPD/PW
6drYcvC0p60vArAi6B0JCuk4lp8ckoea29BveVUdHvYQlb2mXkV/ykocVsBqh3JiJTXvo56u+P9e
6ZFe41mH361W7VkE6CkfJlSfePQK7VkHRKGN4SHeqIwbdHRe2YyfcAhHBz7f98VfqTWUPmVe7h3g
OWBEZv3AqgHQAmreqFjCd/iX9p2P+jUHJzzHCuog5MnP1bwNDhzYDMIe+cygOgDS/cQgHp0PeQgL
DMpcE6ZaPr1RoHGczI3DsDjfx6GaREmcE0IesamK5bWe+OSgf3XNDY6BDJYDHpEPDrDH2LwRg0nN
E87K05hK2yBhD2ZK25if/PxX1uDgHNVh1YyNsMghDlqhAzIh84mhP/GfZX0H3IgHGqZNwIHecfAg
DHLiOUhNgU2Hrojh2PwhIPoTIIFNqcmPEbb/IdwQFCBNh/yBITwIINyoWhkqWiZqSqCNVgCNzyCi
og8Go2b54A7KkZ1Vh6iYYSHtIa7xDxSSFv1cohv+4hT6IgDhzz11nHn8Hq7M3ftUDQyWijE+oqcQ
lAaKo/9UjcaByqj4DzUekv34zyB2YeTpntW84zASW/3g4KbxIzFaRKQF5OrRjyL6TwxmY/w8IgAl
HXFMIqWth0VsoibmYCdWpP3IzcaJYs350SBOWjOmIh6FpP+8zTUCUnooo3aoI7EJC7ORAi5a5Cew
yte4A3Z8IjDyIQ/+YOTxJEZU4sGFofq5XTMqITQCoiVAoRth5A/4pCJmhyXgof0gZQQIC2vt/9oZ
guEL1tz3EEeomSH/lMp33EC/HSPOccIc3t1xGBmhWUTX2NGt5ZE+euJUMqQhqscctsNA1mNEqiUO
NKMhwUOgfcdCnt/3EIEtHtJ1zCJFPiNj6mJjXqQfDR956GJe3iQxaqBciuQe0ePfmaTEAWVd5hE8
hE8a3iI6euE49B8XXsKsAMvlydEw6uQO4lwxQh4gpUqrhEpQ6lPzJeHnLSEvyoq3TWOgXZ5FxJnV
FEHXQJom2t5r3ZMAqma4haMX9l/taSUgLkfrZSf/rGY/dc3+TNSs/GZvWhRCFQdb8t5dnpsOjOdm
BgdA9WM4Ss36AKHQxVE+KaPcpWfzKaDnzf8HOhDmepzjHeWgCcLKf2LiEm7irPieRbIe2wBS8G0l
bJbPKfJhYGaocOwReS5nqelmSg6nPi0gJZ6mDnBjapZdRDHfZcXctVnWbAojH3ZWRNkmAMFWOYjf
06QoVw6HWTrjY/LiZZlHLmYHjMaKF0IHi/rlfOzoodkoRInfclbWVeJRjaJerujKVjbfGm3pgdbo
//moqLRWzJUnbKlNtHkmHYaWJuRTgJUWJ2gmZ81KYaJoaNXpaMFoHO3pLiafk/pbaYbKkx5fVUKi
4mFWgFUpkaKeRF7kgmqp+AVnDF7bnZmDjbqNoSIpZpqPZmpmmb5WZZWacuzop8BKmCraOc7/WkfE
A/b1wK5sBDoAmCes2SXET4KRAvbhahTMKpQ1WYNZTazE6n+pGCYomJvxQK/uKrzp3bKeWZPFymCi
GZcZaxCYWRQOqxAAK4Gt2bUG2HdUKw8A66xuq60aWIT16pVtAnf6wLWm67siqxRE65kdma4WWLp6
n961ILsaW792mlf6KxB0Fr8GLJOxYMEibMIqbJoNrJwR7MJCbK9FrHbU6sR+j75abMZq7MbSSsW+
JMeCbMiK7MiSbMmaLBO44Mmq7MqybMu67MvK68PC7MzSbM3a7M0qbMri7M7ybM/67M+irMwC7dAS
bdEarcrq7NEq7dIybdMWbNI6bdRK7dRS/+2bCW3VYm3Wam3U6qwE7IDXAgHYBoHXiq0EmO3X8oDZ
qq3YCkHZrq0OgO3anm0AsK0P1C3coi3czm0OxO3b8u3Xym3Y7q3bsu3dBu7fhm3b9oDh6q3a4i3d
+i3d8u3bxm3aPq7kjm3aRu7dQm7hNm7eJm7nDq4TRK7dYi7g+i3hgu7lli3qHu7klm4SOC7r7u3p
/gDnrqHlPu7rGu7ski3inq7n6m7jUu7wIi7n4u7k3i7otu7xsu7lQu/z2u7iZi7wzq71bu7iym3t
Tm/vXm/wAq/10m7g1m3zTm/wpq70gq/zii/1Gu/Ytm7ysu/yDq/50u/5Iu/2yu/+ou7qXv+U+4Zv
++Zt5VauAOPv/XYv7Bbw+w4w9ZrvAwtw4b5u/f6t/gaw5vqu+kIwA5evAgOw8IouBg9u7YJwBH/w
7hLvBmOuCvsv+m4v+/6u6a6w6GawCE+w/kpw7Oou4aavBa/vD2cZd8Zw5zKv+xKwCbsu966u5wrv
C58v5AIu2qpw8z6wElfvDFdw/wIwFv8wD3vvDdtuB0MvFVPwBZdwF39w+iLx+rJwCn8vF2PxEFsu
BOdwEYev/C7BAmfx58qwC1tx7rYv45qxB6tu9MquHQNxGDMBGSPxBuOwFV/vAtuv/0qyBhuy4hpw
345uAYtxIityEl/y9xYy9kayAk/yII//8e46Lu6Wbymjchc/Mg1PcANbMuwi8imzagDL8SfT8i5P
wRDrMRzzMhJ0cB2rsitHQSWbsSBPsfoegRj3rRHjbTDz7hxf8hZfcR+38TNvMQhzMv6+sDKDMzLf
cRPgcCOPLxrvXR638Dd7cSTHsjVf8O2esw3PcgszMPP6cBKf7Sg/sQw3synbsw4XLDALLh6Trgbv
Mz9zb+m6MzHz8TwbQT3L8h8bsiivsRfvqz2/LzPvMQJD9PyaMh6TNDdnMzbnczmH7kpntDOj9Ehz
dExrb+wyMumCcRl7Mj7rtC47L0JL9DwLMku/9E5rcy3/swsyc1AT70dT9D9T8jAbcEgT/7VTU3VT
Gy8uw+9M6zM5v3RQK7VSv3Ix260Tc7AbjzAyW/VQL/M093Fbwy9ZV/Q7W/QykzVGR/RRtx5Yp7QU
X3NfY3JYL7Ja/3RVK4E3F/ZgIzb/ovQpn/EB7/VP+/JFS/YV+/Qjk208y/Nj+7RjD3Zlx7NeTzXu
MkAL8PNf/3VTp7Vbw3Vqt/NCU/RrLzRlx7by6u1JCzYrzzJcw/RYEzQHnzVvi/Js169wa0T+1rVw
o/Y+s/Zb33NotyBpb210S/d0G+1o1wB1Y3d2azfMWvd2e/d3gzfHdnd4k3d5m3esjfd5q/d6s/cU
jLcTa/Lo3rJAQzZV+/Vmi/BEV+9X2/92URuBAAC4AOgAgA94gBd4EBB4AAS4gSu4gB9Bgjd4gUM4
hPsAhR84ECx4hu9Ahlu4Eiz4hROxX/P2Ejc3Udv1Y9+3UI9zidc356Y3LUtxQ7u05AY3W/fvKtM3
Z4v4Uusyjuu4P39xP+94gnN4DhC5gx+5kSP5kit5kz+4g0d4lCd5g394lEs4g/dAh284lDt5lnO4
loO4Nsd2QO+0RW+zjBtx9tKzbv/4VcdvlUE3DJ8wQ89tNct5JzP2ZG/14TbxVb8yF+c5TmM4k0v5
klf5lCM6of83lCd6lW95l2M5lXu5EHw5pQv4hFc6gfuwYhu1LIcuK7u0HiMvUKu4Xp//MSNH9osb
NA1HryNjMArTOE579UzntkqL9CeLtQdHNWdb9ZEfOqEnupMH+6L7OoNP+aNbuYd/OZczAYFbuKM7
umbLeh5L8JyjbxQ/cTBD9myjdhkf8ZHFefe+8bhL76gfr4/Xsp238xKncgLzeCCvsZ4jAbQzOpYX
e6MbO7P/wK9feZgLu6Ev+xIse6TzgLNz+bCHeGdr9TET90STsEnvsFuD9GGH8LkLObhftwVru7i7
MnzD+i5XMSQ/vJ+PMVf3OU+Lc5BHtsDrO7Ij/BMkOZh3OaS3vMwPvMwjeMAXupOHPCL395DFdzgD
9Ij/vGV/NBsfPSmEe5qrcSc89Hxn/zut0/QbqzaMn3ZfUzFmTwHCD7ylbznOV3i9X7mGN7vO57yX
Y3q873rbjrnWJ/PQD7XRT7wco/oTv/htL3Zpf7y7I70WT/xU8zSsu3GnC/q8F7m/DzvOg/2+iz2y
z7zitzyVR3vYLzo77/rGr72J67etC74tc/w64Hm5J30uK7zD13U3v/mNX7zHqzglC73eNzaQD7R8
e73jd73kH/vtJ7u/F7zOEzymV/qk277ZDzraH37C6/j95jCL2zcQ1zPrQ79gOzM0Y3us80DK5PXP
l/WfZ7b2c7zGu73mQzVhb37z737aOz7lz7zw9/7Zpz/7L/76oz+x+z6z43zQ3/Pvrv/6IWcuCEiB
KAajiZ7pWq5o2b7uHM9unZLuojC5BAy2hMIbEfgr2mRLpg3XjD6lqhcxCr1ZjzOB9ytIgcdNL2oM
Npm76HWg7Waf4ba2mE51wcPLbN8Jc+RXRQNoIjiY2CdoxPXXhMPjk0dZaXmJmam5ydnp+QkaKjpK
Wmp6KiWJusra6voKGys7S1tLqmqbq7vL2+v7CxwcgCtcbHyMnKy8fNvD/AwdLT1NDUssFZQzckW4
nX2YOeQ4pEU5uKXdXYW4sqeG9sZnmpYXd2f/jh9v1x6mL/evnrx3ZQYKzBSHXz55awLe+0JwIUQ2
bszAizenosF9F+vwucbuD5SRLMD/lTz0TV0NcY7QKVFXbh3KloXu9ItoMyM9jmQeWpyYZg/DhhDJ
7Izy0+jGORwxSjyqBw9TnDp7OqWicapWOVcPOrWHjyhVnku3LiGK55pJlkp0xEzXtlwMGHJT4ljp
JO8UkyrubuFmVuzNsQH1afyJMyvGpAMZF6QatOziogYRI62M2ezXjQ4HXwXrz45gShdBR306mHFk
rJkjqu1bci4jlYQCjYMbO503wHzvzja09vc5skA5U04tNWdT5YoRH3V8NnQ/ywCP2+xM3PTYzVEV
ek7Y0ePTiVw/h5862vzjy6ddOzs5FzjfbuTWysUtf7hu/TSQ6O0fEmsPBcYHduNp/6feZFYRt153
UPm04GSV/KNYTgY2aBpoFU7YmGTRVaiaTgS6o9UaPCiwwF9x9aZbbfDN15tdetFlzm/GiNahVRce
ViB59MAD3WZhCUUQdaetdqBkQg2FVo7nCdTkktwtx1prnCSFXEQXTtcjCgygWFMS2iDC30y8vbUX
mVmsRCYLjKhp5kvZkdeeFCQOSKWWxRUZWnN0kiZdYX1KV+eVe0bHpXcLbSced1LaOaiihuqJyY/y
fJkimpeMdCaMe0ES5iOe+IUNopBeImiTN4nF6qCJ/VmVn12tap1nBSnUaoOodgmejl3OasmWDvZE
omBD4srrpWBqGpJ+pLa4WzZ4Uf8x3LOQ2OhpgIUyumujjqkqYj6L9rpUhkNNGSuhtgLLFbm6cqsc
lQjulF6V65qqWYk+GpdluAFgGic3pDqrBZyfenqwigJTy/BJXsWb6JJPcrloow5SVK6VTNVLa5JG
4luex792S5iHHD8G3sPwOjTkvcoBTO1s2iqsCZs0/RfzzdGm9N/MEM/JypYsK1mWpNd5+HPI77p8
mdGFOo1echlNDfSwD+ar2Z3lwVxN115/DXbY0XAtdtlmn4122qSQrXbbbr8Nd9psx0133XbfLczc
eO/Nd99+r71stAjjDG3CMOU2U+GFv6mwf40j7NuKKs7Y6X4z7uf44SesCRPPirj/ia3DNeqs+Hyc
s1R6zz6nrjl8L30uKi1cDxwmYM6GHheNMiVOuIvZJuybpprzZq3D9eWl+/HbyGAbXc/WZzuoB7Ml
p/Cmx05C7tLzPnj38Qn+O4vGQz55964wMEn4JJFfquj2bS4+bPG/Ja31zb+ouB/KF5+E49+4Jb/d
yQ+A9nkeOuRTsOltr2Dr856Y4pO9hcVPf4f7nuXGFxy78AyBvTtf+sCnuwu67wm4K+AET1iI462O
gOIAh/8kSD/QbRCDLoJefkyIGwP+bobzQ94CrfAD0Z0OgQSMCfU+1UDahG9362tgEmeBvhh2Dmdl
cuBu1pG55KkOiE8UYRd9WJfM/1kieuLTYhnr17/OZTFOWwxii2A3xvwxgRxFQN0Ns8UmIRqxEf6D
0f9qFyoopo9xU4ScGH+InyIisYMAstG0mnczC6LEep3Aix3L6ELLVbGQcVReD3f2OgFS0Ydm9IYA
N5lJPy4OEM1inxpRGYooNoyGrAtY9WgEwFZ+EpSwpKQMK3et1dkSjnuEjQUVyUs/ilFNdOwZI6fg
yVI185Ss3CAzmXc5Z+5SeNFsXStkqT7QUa6XNXGe9FSYhy8ukHQj3FnsKkFMDJrzevwJYQedGM5G
hvJ9v/zjNNGJQsMxEVo6FCU/uWezXIAzme7E4ori2chUMtSUVCwhIlf5TCWiie1TLYGoG+FHn1cK
jAvxtKQv04Q4ac7RoW9c4ztDGghm7ZOhtwnYQWGxUP7V0p7tVKn5AvnTzVHwpZIkKvCAyroqIhOk
PX1pLefYpvYJFKlMpeo903lRQDbVmzz1YP+qt1VvDhOrY3VqgLLIUeKdaYXA9B0fXyec0G01rWBN
Klk54VFf5tV89cyqEeXKSHKCYqF/K6xhD4vYJRA2sYxtrGPrttjHSnaylPVaZCuL2cxqNm8f3Kxn
PwtaQYZ2tKQtbSnQh9rUqna1rG2ta18L29jKdra0ra1tb4vb3Op2t7ztrW9/C9zgCne4xP1tCAAA
Ow==

--=_NamoWEC-fg44f0yf5w
Content-Type: image/gif;
	name="201407210944275_7EUABGFC.gif"
Content-Transfer-Encoding: base64
Content-ID: <2LL5XOK0LK7C@namo.co.kr>

R0lGODlhCAKQAMQAAAAAAP///8k6OspMTNRiYtt0dOSOjumiovLExPfZ2fvt7f/+/uvr69TU1Lm5
uYyMjG9vb0dHRzMzMyoqKgICAv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEA
ABUALAAAAAAIApAAAAX/ICOOZGmeaKqubOu+cCzPdG3feK7vfO//uYBwSCwaj8ikcslsOp/QqHRK
rVqv2Kx2y+16v1YReEwum8/otHrNbhcX8Lh8Tq/b73al2M3v+/+AgYKDVniGh4h1egyEjY6PkJGS
k0OJlpd5SXsBDQ6engwNjFKilHoNSaVYqkisTK5CoUqdo02waLJMubGogg6Nt1S/a3IIeAoJmHAJ
CnTIipq1EBETFBERDRHDUdqmSQ8PSd1GENzbR+NN6UPgqRPYr+Hrae1MDhFE94MUfA3hRvOKlHPC
z8xAIXIG4EFQAJGBOQWMzWEIDckmIfqEBFR3zhuWgk82DhGJrmOAekcy/zJpR5IMSiUqA8T8A5LN
yyc1l+QEU9MSxUMKD/2cs6iIyggQKExAxSCCtVoBmlKgIC/pBEZSIzBw8I/ryWr/hDSYRjUpvq9U
ozpdGiBp2rZTyzUAO9BqLyHt3IZt22Cs03Jm0YbzS2HgA2sTfj0AixfxNqlsszLqtjgtuAfDMA+p
BlgpqgdJh82d8ACpZ7VPiUA4HNlp2tVKHVT7NbewWKUR9kpNy4Azvt6F8SGdIBg1W71C7CY/rTru
ycr/kiYlAm620+hxm4o9K5ax5Las+04gvTschL5kD8LFBmFCZ9twp8NlO6S21uJfE7dNygD6+kpx
NGTAAQMQkIwCBAxggP+AySTw0AEJPmTAAAU4SIABBiQDIYUKDCVHUflwd81JgJWomlz8UMMABCay
OFdyDzBAgXh3OTBjA1T1JsqNS5VG4lxbEVeaCEut1hQ+i/VHHDsPACkbEdrYuGNfFDggI41SXnml
jVbyiGWV7CDZYjnaXDmXP+CcNWOY/ly12En3xeLiiKDtZ+dISOLDIicpCucmPuTlFkBiMu61J47g
HZnoiFWK4KWPoDkppJuTKkmdVjomieiQ8uHl5o38DKkjW3Vu5gCOK5pIp1YuHpqiJzNeWV+VNjIi
ao+shkoplPLE6OWVbyLlKI04bpPQAgU0dICAByiQLLLGUDSAMQMkkMD/tAgMoICzCChQLbIHeBgH
iEMc9Ys+a8pIhBg2BiCoumsiqh8F/dUVVkYFaVPqaj6KIBsjvQCcGL0yCTcMfc8ByQmUnpzVTaj2
ZqTvQIntCw7F2/TLSLyvWgyOjEGG6O7BaBbB0rn4pFtTN/qw++pzBb8Y85KrrctIuwT7mHPKeNmr
8b8Lj7OU0HdFxUnF/7yMKJMFC1GQwA7sqV93GMmKKMtIhuPyyBKfw49KUHdzNckjDUYijKXKo5i9
AfQUh0IRLSBtM8tCK3dD3yazgEI/xd3ggOLCQS5GIqLc9lRTEWHfy2037jR4Lx6G+L1qasQV4jlS
E2N8TK01MOHuYp6x/3mFFR2lw7+EijlmqNej7+quP6b5xkN0DHuvNZdrsOU3ndw05isbvvjIMN9j
I+LanPXS8AWhC3pBkk8V4+ych474PaIPARnSj49TUzv4GpcYkDXFBNLL+rQz/OmWE/H1Wdsb3332
3QkaPVUvUba64wi9bbe0cKBI3CgCobjt7W5wiNuECECAcDWEDoNrWvucJxYiTO1l8MLK19xTjnoU
LXwj82BUQtGeqPiDXnsaGcH0MY6iqa8/BLNc1xonwq7FToSx0x4JiUMwdenrH58JB2jWpDviDYor
e4EZ1vhnOsNdkHjgS14stqK8vTyxeTz7HV6AOMKxECcUh2mKaIxYtP8U/rB7w/heOMJnxl9wUGQy
AVlU0Je1QSWNa6hznwTb6D0yKq5g/KpgPdQGs4XxLwDHGiDeAtgQRS6AGcs6wAH7hoBl0c2BFTnC
RSRIPBaucUlOs1WKOigcIZ5lPKgAmqBA57goXcVdoNEaVU4pv2KxSFH9QthlaDmShrVvg5NhneVe
VCxVYoY4xRpCzXxoSq69MjftkBEoQeejTSXRd56UyTSXmLOXRbFtnynHmkjjPlHCsi2lRKfjjLnM
WQqhYr/BVVQQJrYq1QNiJ1GjBJUGptAUgV4gs9/u0heObuKxfbWTYD250sFQxfMuhLqHwnLzoiex
7JkFxQgi/efIAkj/ckHgWsCyEkCAZgxokg+MyAEegiBMQjAaRilc03DklHO0xz30okY1UEFTIjpF
meOZJgi7cVNkIiZGQcWHjaiRG+BMY57UUM/HksqwGY5nRUFV6C+KutWstiWo26ApOXuKCqJm1XVJ
bNl4wNS7WQrPGmDqZdNuyh/KrBFJ71jTYsZjqPHwR6z4GM07+FdUPs2Oqr2JKlTdkw/EQPOOvckr
de76uKW+Y4072SuKnFJWwx0GNH7NqS+N+M7EnMWyTR3PTxPLWHYc9avjSc5sjFjYQV2FH4mMVkNI
ysCGZCtZAiJAAQy0AAZS0lvDxVDgFhDBJpzKCH0xSi22ApUidAIK/9eNxXMxcpfsnsRW3NluSoqm
BytxwiT5gIp342iErdyFutA1CcLGOwvylsu+0MVvfGsR3fyuq2i7sO5jxCtemXzQvutNCXbPUSrr
vte8reCpfjUJYbF05ML2ha+F84Ff71I3HIh4RhysVQyJLKBDzZgDig3RXI9MYTGHQa+Ln+CXGdsY
DIuR8Y2x0B+PiEAZQA6ykO/AJB0bYchITrIcFNAsJTs5yDvOgieiTGUt/BgTzLhElp9siS0X48R6
C7KXtZxiMSNgzGM2hIjn4OU1TyTMSXYzi1NRXezWeRBGhgkYaHNn66q3zyaUQp4DrQmeArrQTbgy
HB5yCAMmwtFcbv+0if13AEkKudJAxnSQfwtpSN/hIct19HIN0EAlg/qBiDiCP0grhZtoQTNLWJFO
qLATLYQqiSVhWBJm0oRaxxQmu3tCOXitSQYcS9KX8HSkM23pIGsaE89WRrQDNOk7BMUOyqZDtoF8
bUscwXeEaAkrk+BrJpT7CucuwjpIQmwstHvcUHhfoo29aAqJtECWJhBxC7DAZAyoQAcqAIfs1u9H
ChxDzoJDwkccoQSSesQLGoAkLYShBBQgxRlS1sQbfm9+N4jj1xJusx+ZoH0T6OKPLJBHi8FASTpr
4P82EG9XqiEKEcAYG5p4xCVEIQedWOASt9syJKTvBBT95SjHULX/Ir5Se9+bQxOqEEsFnvSij0sy
siGNaVqTGhY9JRtb7Q/pyDkfF1ZmbVWqTUOXovbupOUvZV9OpwqZNb7KvSDKGWJYq8GW3FhDI4ep
HPjsXh53WWUyilHKXlrmGsw00ysjeY7d10NFvnCiHE7VE3rgHrqnKtMasuE8a3RD75SfWebaIqnR
CYAsZT3kWXXD0AJkr9KLQ2j2BnBWQ4i7Ujk0sKV761YcstUsbWVrWxE5KUkPiOnfe9RbHZpWcZu1
8ptfa+SlrlvQq3/moMfh5seXPe2VdfGKR0T12Tp9t4xfLW9ZC1sCesjyRd1I8jurWeJ/fe6z9f5m
ydzk14IAFJF//60nUqhmJ7c0J2KCgGQCAWJkI76SMFfxJEPyJK7VCUJyH+QRKEg1PeEwPvSyGP6g
FRSYK5P1OEnSLpziUCHzJhbUTIXRFAXlgIJya0dUK4dCHCqyJ9pwJqhSRK7CQvyQOyg4gSyIFCxk
ODxoMFkyIyuoOLQSK/TigzE0QsfSe7NXaYwmSR2lW3vTIHDDEJZmINqCQLJ3cwzHSAfEcovmUrUn
Ug+hEJWGAKx3N1gIfnXIEMuXhUt2YtoHB5W2hye1DHnofin3PxoHLXdYSYwGOClFLQi0LXIThsPX
SF4YN3lDiT8RFH7zc5LEN3gDhog4LhyjRIajMlCUJlIEDkBTVv//oEsUUzIWmISziA2vZCXZNChg
xycnSEN3VE/npIs3gRU6k0opY4y+KDNWsjWr1DFsAzpbww/WsIsJdU/EsxVJ+DvgdVAj0w3qokc2
9IxWSGkDUI4SF21diEDXFoYGFBFBQRGq120/AUDF8EBz+IjFZTdyGC7mSCGaFhHZYo4RYY8jp2/P
EhT3CIjN5iHrOIqYplKWplL96IaQCI8JInBCh0Dp2JCOtIYKVCClBopreEAdyVznY4q/gzmdhBQw
JkSkcx7WMxWjwzuU1TRRgjlSVESuIZN9xDS+iEbzcz1t9Q5ZREHOw4rccTRwZUS2MzlFNDyJ4R7t
okfWmA7ZaJT/TIg6PZlQNrQ/U3SFlqYh+TaKjlSG3gItBnRzZfgTF8JoAZSHi1SPCklJ01eG+/gT
27KIeNkhBMlwyUCPCSlSC/lA69cMZ+lID1lJEamYy4BA+ohAaEiSJiZAl0gthqmJD8SJlYRymCaS
ZomZpKhBKElBQUMboAd6MANGQzNGPnlGtciN/nJalddCTNmLNtg4fUSby8MWWLlOPIOUVfNE3tgx
XFRETzQNuUEN/1RISuNL3AQ67NONv/CNXNk6xfmV/kNSzeBRy0eHZHmJklQ3b3gtuKd79VZt37Jy
3TaJyWAgdAkhjLaPXwiH1xJ91KIhcdgMpfaWCRSXnamfI6ct/+63cuLphYm5fAGoneBCl55JN5So
hulIoJbomJrZe8AnkhI6ioIjUKOZThZ1MDqYM2nyTlzxG1X4JtbkNK5IPHolTsOSPiZaL/lEHcN2
m/h0GHAyR2KXD0vCKOZRUD/6kwA1IwaFFDnagxhVRAYFYzaiHj9JQx0EAdnkI4LyVNGpLyYIjqgz
UWGhaMVVUqTGQIuWIMaQjvBIIenZLQxUagiiIIS5npPIQM2wnnTIQKeWQMZwfXAgnyf3LfqGhn1a
cy3ne3bKeggZniBZkHaacgKXDIjJhd0SpmgoqY4ZN8YVXBdSLfT3nYyaphSKp8jVll96po2qocxF
VvlUGm9VU/9G9FMlBDOIpVNSFVQu6SlX9VWXw1n5gSI06FeLVRM09VPWyFr80BS+ehNBVUKI8UrL
SjvtoFmwlRTZsFadBVtCpSehRSW+kkQ2ClUzog9LNSKClZXtIx05MR4zVFvYqXDClwCTJnyJsGJv
Boh0Y49uKQfuegd6WG2WsGJGBwfEdWLwCmZ1MLB1IGfLEGbyiggGm692sLAkFmQLewgLW7EG+1Ia
xgn4lbFOUGAF9hwfu2HlghUV1l/nxV35QGFLgGEwUQv0sg0vmwrdRV7olWCKM2FOwLGExgtLoBlL
oz0Vpjgd4aXLhgcQQiA4F5mXsFxAhiALUodFG7VSO7VAFgj/rlZly6lHWCsMs+SkUUC0VDsHcxhA
/IoI/+pkRtdkYbu2bNu2gTBlW4sE1xS3wnC1ULAJuxBgQgtdgIZEYJC3OGsEnxC0W6C3WsAKnTC4
h8azMPExXICNcFu4gdtegwYgIwZnbftIZXYMmMu5dUBiZbtpSztkz5Bmn7stnXuwqZsHm6ASxLZU
ACFj17AYXhsGHWQenNRr16CrWzBsSbkF6TAN1XANk/tuXwFai9uz2xCut6oJtUsOudsEItgKezEH
F5K5jwSpiDBtC4FqctCZTwandRAuIwlklEkH9wotTKtwDzJyLNa64fW7WwQFPjJPlduxSZluSAAS
DZYF+msF//NgvL9Gbr1AhFNglSKCa3A0awe8SkbwEvg6XNibmMu2XNy7ttu2tN47B+K7vo55CSNU
RNQEHaMxPdLDF150EAjzXP5BGEMUWGSBHWwBFhczjZjnFPfhd3HyONBZQtAha2qhlHKRHusxFkIM
eKlRH3y3efAReFMjwilceJmHGjvcNqNQCt8hFVGaGLJhG3vVCyrBEiWkHIyhHFpcxHLBGUhcxYOi
HW7XJJO3UQppABIRc+5qaZUUB/8omAnickD3UX8zc/wGcCSnIA7XQAdgccD1cwPXpiA1YirHhYV8
cS9HXCRlyODij3KKLFlIyC93jgxkcfVGXHZ8sBHCIJdcfv89R2oVV6dB53Ozd8mVtnGG7CAH9yHw
W0SagkLn4SpcA1AJVQQycipLISU4glSdkCMhuCsiCA7FpCcm8nZ7wb/itIxSeCZnw4FNSCW+xIFt
0ysWpBjacM1nwiUDXCupwotGMiJ7kkLJQVHKNCa9wRWvxIFzsTmcVIOKwcw9siu3BILd7IHfHIwY
UQ6vdESo4iKWW1xGx2iwVyGc2GyaJoclRZ6yR56KpADm53rTd3/Bx2TNIoAgRYADYp7ft36fGFIe
VTe953yf6H+vl9IPjXskR1LFJ1IldXszjb7UZ4krx53YIqAAKXHo94gQkrYd3UD8Z4iCk8sjjIJa
czOvMhP/mRUxleNMMEI0BNU46MJT0ji/tXMNO+U4FlMzFLUkxpNH7yMzOgPWFdQfOTkxJHrO8CPV
VpyjqEijp4GKK1QyyhhsMmENOsXDWh1sS9HXXG2LeJFFL1EzNaOMO2q5y4cgeAqZhanHliafBySJ
2eKQ2ssQ3mmAa6hpqjefZ1mGdUOIbUiSEyfaqAuXHolzMu2FnE2JD2ogJZkQ9YqWrY1SeBrajvjb
GreHK0WXTV0LrltHP7k+o1U70xXZwNlKo5UmorPV8naS0DPNnxDM9yNMRog8M/Q+GUFBLyE512BD
/xDAp3UWzPM8KtleewI8hwQ+OElasuEJd5Evw8A+O1kl/zkh3utN1lb0DowVExAcQBRSqog5IN47
0YK5p5MMmhQM2oTpn2OY2f24hkPxE+BLUivnLL8XkOUYl3EDvo6UyrYtdAPphXTwjpbo4ZldqQJI
kJREQC5F4ZV93Eqsy3fUDmQ31b+bDrFk1YQ93apaQdatjXMk4FqrtSJUKMSREbH5SwXzmtmtxMaI
3gglwhlxRc9TH+UCSqSJCs0ji3Vt3/Kr3ySajQtT5olt5W49F58gb3F04AuKACd14gpSkDHu4JEp
4Z8dEbB9qKIN4Y3p4pWokAf0l/yGuqS2l7H94KC5nymelqD9wcdGmYwehzL+E8GtvhoX2jiekSFc
O71gP/89XlDmFJ1hjhXjcxU6MlSwggryFOt1JG8ceuXBrLXG5C7NGE7h/TsrquvapBFx7QlGdWEB
ftc4WqUeOk1xVSeC8qGwdE/hhOZGAD2BJW/1K1rndN3D7tZE+DDDEk2o4D+q3ZECt7m919kOjtpw
E56JWJaOmtKCWZ8BIkneuXKPvKftmdI3x5cnddr4Gekm7oXw/ph1g9G0DWf8boloCEA13n7uyXre
MuOSXu90aQyl7ilMZSupHq2ixWvtcR2y5R6VJ91Zh/Ksxas+blqGtSbEfkg8bK2N0QuLwVlWBfN7
xaxubVvuAfPEw1V0ffJ/5Vgxfw42ElQAA1e0cVb/kPP/a9Iew8BrT7NWpumABJ7GsWVb6cP0TP5O
d1En0PpZ7QCI3qstHZnakJwsmq0QYToh0bfIBLIsBrqmc6qQBGKO3SdwebqmDb6mKX1yDXQtwxWe
wvUtminpoxj32vLoCoEgZOrZ+Ar4imhzknSpv72mjAb43TcgiC+nDMpcm+RetjC5FlY0NhtT6yVe
HlZhOksKOkYLFlGylRuy6YVdAEaz+PWxrl+zFYb7SPD7KCuyUWH7VGCyJosJg7hkoZuw+ApnEctm
z+8MZxYHCPtInSuvHRJm7rq5WgZn1z98q8tkKrb98DqxI/auZeawy/D8ktTxjSDAdFv/9n8EhkBq
4I+9//wPAos4kqV5oql4KKr7wqlyLAHDBLm+873/A4M5xkNoPCKTyiWz6XxCo9Kd65CIYbPaLbfr
/YJdNkZYlGiV0yTEtYSInU8JBLocV8feWb25ruKLAOJxCboUqtxxJZosdi3GCR6eFNo05DQ44EA5
TD01aB4xWOrcpB3QDJYZEKAuHLwNxBQUKgwUtH0l0MymjryexGYFr7Se/A6LIPcKwxxn8cYYlECT
/FJ7nVbTKMcqSKso1zhE2FBEjD5RdDo9FCGN75Quz2td84bvFZgWL1974ae4R2+gCH+pAE57Y3BL
NhP4EOgDZyIAPHhS1K3L6MPiEDK+BhC4oqCArRYGDv+AnIMKwaldKAu0eGkA14IEBAZ8K7DKFyp9
NkvWvPltxE9pKEOuSIkTaNESM0/d3IVzgYGUrqoiOAkSwc03I0G+IsBqJlWrUFk5ZSq04EtXKX8i
1XcWVVWkZatqW1DgZZ2jCZbC1Ot2ajWrXwNrJcB1wJvEixUS08tXcNnAcHWl1HfYpF8SM7/aTTq1
6q1VBsj69bs34kgSe20V3Fn3yoECYmlkW5pT72ird8NRJBeBAoQh5GyQazCBeI7j7XYQN4dDOYUJ
DR5wCoA9AITq6LR3d0C9OMUJE9x1t679QQRNED4Nb29jOYTjHYmGPECAqrTTevef9hdbubn0lwII
MEb/AisKoMVYX6jEspdkCywo4QgLVsiCCCOxMIBLFLJgYUEsEXDgfvrpApN+rgRWgD62zaCPfwIG
OIt+M5xYIoLVwKQTiAxuU+BeQLK4QCw37libiSx6gwyBE244pIcTxjLAGaHZpAuA/Unj4n8x6vVi
ibUZGdmUEh7ZozRoKSklf296SeYINso1lJFXJvAXAggqMBIb+ZU45CxIHWAnThwaSYeSKyJ54jYG
IHpkfjBxxSReJQSnnXo5qPdAcecxcF4AGD2nAwVFRFCEqOx5yul1EzDgwAQ7sIcDqKkGMIEDDlBA
RHuyrgdBEcpxVxwExhYXgX1j+PLNNlcIaGEsitUy/8M2xBQqgmL4BaKPMg1FSAO0+y0AEbflvgiI
QK5YQa65c7IEIbpQ5tfTG9mY22e5R+6SFSqKgeuaV392Wya7er0hEpn8JkNvArwIyJPBDY048bVW
1lSNs3fWFOG9NJjLC77emlkyLwcu0AKYAmEc7RvvjkimviO03PC7Nm7Myyz+bUvzFeYGYyHA8ub2
M8kh//twwsBVtOyxue46a6akupMD1TbYUKs6wArrqg7PARscsRQFgGuu12FHTqsUWMKAOr1qt6w8
B9NcNzRHniTXtew2RM27QJcQsE1oITiA4RHNO689sBBT+OECBxyyHjbae7C5P5F08CzQUN4wvCP8
Tf+y5vfe5CXDZZJkOGN35xUMxQhbXKZ+17w+jMeWp4t77K5fSztIXrJs98uIIzzSgtUQwPrN8QqM
cJbcFBz05MzLvjfgIau+uh5Mk8NRAMo1sPVx8Fxtag7PPVCdsme3OhwF72e3HkXvvx+B9+7D347b
ZXNC//uj5sB7c2vINlR2uzL95SQH4122KMSHSs3rW/IymgHeNbNyuSt3n+OdBf3QuTJJTlvUExnI
9NEzhm1OD0PzXMXmAEHAja4WRqtew6BxBdZJjHfN02EszlCbVhDQSAaE3ciIWMLdmSxhf5ohy4bI
C5gVTwEJ2AlRYnSt5QVRZ28ggH9IEAwYQmOFNPz/4tE0eMPtTaRpPJjA08JGvvNVDYDrAV+mjqUr
/l2CVkWwyA0skgn75fE5qYIbRr4nRwF6JCgYnBCZfCSnm5SMXQZCECAwhqbASWNH2wIabQx1w37t
0EydhJy8zEUmAfXtYxGMCQpZ4pPTOcko0rDk3rIxCwiajm5pStkAZmAUJ9WyGOsqWomo0gqbLFJC
jVRlCItISyRmq1C4zF24ivRE4u2MBrXAD2dAGJFZILNSWiyLIKakQNe9UpcL/FAsTKmZXkazG7jI
lPe4Q4HssK1sRcin2awGx7CtTzlSY085QFGqfK7tBmwjqNuIUIQHTOA4uAIWruoTj0RSpSsdI8kN
/8ViFznlJjJH6VkgQFJMZfzFRUeyxbZegjHQmbQF11jFjg7mUpp8sJ2a8ShuKlfEVXDRSiipDR14
qs4RMIij+xJLC3RIU9twcT+wTBlUpZFUSOYwMiOgKQ8zahuarCJBKbUkM3P3U7FccoEpSx7GPCob
xfTQFmRN3IhSipatJg8pYlleRhP01JeFg6Un3ZBRA5abvDa1Y5Cq6lpto9MR0HNZ8/uaeWDFHfP0
U47PqSwEpGYO45iHPHA8nzkQGlrknPY54XNH+IbDCYFG9KJuqMOB0HDLOigwBbrQFk1qIokNAaK2
SKUDI35brt4C1w95QC4iaJKnNTC3BMI1g3HZcP9cGFgXdISIbrkOQdzkeuG5LphuufyQ3ZR99wUH
Qu6ehqvcQNThvA30Isomwd3hFjcQNJGEEFqlA0zsoAHfAUImgiCeIMQKFALewYERXOAhDJhZsgDE
Kt5LgloYwDYE2TCHO+zhD4M4xK4gad1EPBEgQDR+GllxJ+b2Ag354r4bOoWFTWzjG+M4xzouQ3tN
wA8bG1jFLB4yFG7QA1HEI8JENoKQEaxkIHxiyQaWsg+Q/L0m88DKQ9ayk5fMCS4nAcwQ3ggUFkyK
J1P5yGhWsxKw/AQkRxkJYjaCkXVQHO/VM81AKGQQ7ixZIQBSzzzgM5X9PL8/2zlTRM7zRhC9DnX/
lGoJkdajDwg9BNFWuTiTnrSgG01nTcfRCJbehHCwjGkdMFoIdfZnqjsdhVG7egmwHjKfOT1oRQ+5
1Qx2dEZsfQRf+3rUuoaHr2P9BF3rWdfC5jUQVt0d+0WUOQ3QNH14ANE7jqc56UuVeXAwSG5b1jmo
2ra3kcMcTUnn2dM2t3yE5Z0dvGfawzk1RE/1vc4eqzuiqPa02diDb/vTnpvqjrSXI596x1He50a4
Pc/xHvOUygFVe7as5n2+5cSRAcNRj8alw530cZw+yal22TqLavPYWz5lA0XH2w1yWd3ze8tRj9oS
PnNLfHs66kv4zmV+boykxxIYF/h3MM6eoT+H/+AZtzi6h1WfUz373sPx1GfXzR0BP70466YOet73
qVOpluQ53wE53K2r5XDC7DD/cnxwECrilN0S6Uv3Zxk+DokHMNRVVvA9eWUJtpGvf+hw26ty9QCN
7/Pw/sbVqUKVrH2ONuWQP1aoMsHPB4RvV2VHVtnUtiz7+Z3wpGAb+HjlbQjYSvHY6RUoTIV6xmuK
CLOqVagagKtUEZ6OAWQb4d0mHutkfhwMOFb4tP3fvueT96TfVNzAU6znr4+gwtI4OW61zwfPD/PW
6drYcvC0p60vArAi6B0JCuk4lp8ckoea29BveVUdHvYQlb2mXkV/ykocVsBqh3JiJTXvo56u+P9e
6ZFe41mH361W7VkE6CkfJlSfePQK7VkHRKGN4SHeqIwbdHRe2YyfcAhHBz7f98VfqTWUPmVe7h3g
OWBEZv3AqgHQAmreqFjCd/iX9p2P+jUHJzzHCuog5MnP1bwNDhzYDMIe+cygOgDS/cQgHp0PeQgL
DMpcE6ZaPr1RoHGczI3DsDjfx6GaREmcE0IesamK5bWe+OSgf3XNDY6BDJYDHpEPDrDH2LwRg0nN
E87K05hK2yBhD2ZK25if/PxX1uDgHNVh1YyNsMghDlqhAzIh84mhP/GfZX0H3IgHGqZNwIHecfAg
DHLiOUhNgU2Hrojh2PwhIPoTIIFNqcmPEbb/IdwQFCBNh/yBITwIINyoWhkqWiZqSqCNVgCNzyCi
og8Go2b54A7KkZ1Vh6iYYSHtIa7xDxSSFv1cohv+4hT6IgDhzz11nHn8Hq7M3ftUDQyWijE+oqcQ
lAaKo/9UjcaByqj4DzUekv34zyB2YeTpntW84zASW/3g4KbxIzFaRKQF5OrRjyL6TwxmY/w8IgAl
HXFMIqWth0VsoibmYCdWpP3IzcaJYs350SBOWjOmIh6FpP+8zTUCUnooo3aoI7EJC7ORAi5a5Cew
yte4A3Z8IjDyIQ/+YOTxJEZU4sGFofq5XTMqITQCoiVAoRth5A/4pCJmhyXgof0gZQQIC2vt/9oZ
guEL1tz3EEeomSH/lMp33EC/HSPOccIc3t1xGBmhWUTX2NGt5ZE+euJUMqQhqscctsNA1mNEqiUO
NKMhwUOgfcdCnt/3EIEtHtJ1zCJFPiNj6mJjXqQfDR956GJe3iQxaqBciuQe0ePfmaTEAWVd5hE8
hE8a3iI6euE49B8XXsKsAMvlydEw6uQO4lwxQh4gpUqrhEpQ6lPzJeHnLSEvyoq3TWOgXZ5FxJnV
FEHXQJom2t5r3ZMAqma4haMX9l/taSUgLkfrZSf/rGY/dc3+TNSs/GZvWhRCFQdb8t5dnpsOjOdm
BgdA9WM4Ss36AKHQxVE+KaPcpWfzKaDnzf8HOhDmepzjHeWgCcLKf2LiEm7irPieRbIe2wBS8G0l
bJbPKfJhYGaocOwReS5nqelmSg6nPi0gJZ6mDnBjapZdRDHfZcXctVnWbAojH3ZWRNkmAMFWOYjf
06QoVw6HWTrjY/LiZZlHLmYHjMaKF0IHi/rlfOzoodkoRInfclbWVeJRjaJerujKVjbfGm3pgdbo
//moqLRWzJUnbKlNtHkmHYaWJuRTgJUWJ2gmZ81KYaJoaNXpaMFoHO3pLiafk/pbaYbKkx5fVUKi
4mFWgFUpkaKeRF7kgmqp+AVnDF7bnZmDjbqNoSIpZpqPZmpmmb5WZZWacuzop8BKmCraOc7/WkfE
A/b1wK5sBDoAmCes2SXET4KRAvbhahTMKpQ1WYNZTazE6n+pGCYomJvxQK/uKrzp3bKeWZPFymCi
GZcZaxCYWRQOqxAAK4Gt2bUG2HdUKw8A66xuq60aWIT16pVtAnf6wLWm67siqxRE65kdma4WWLp6
n961ILsaW792mlf6KxB0Fr8GLJOxYMEibMIqbJoNrJwR7MJCbK9FrHbU6sR+j75abMZq7MbSSsW+
JMeCbMiK7MiSbMmaLBO44Mmq7MqybMu67MvK68PC7MzSbM3a7M0qbMri7M7ybM/67M+irMwC7dAS
bdEarcrq7NEq7dIybdMWbNI6bdRK7dRS/+2bCW3VYm3Wam3U6qwE7IDXAgHYBoHXiq0EmO3X8oDZ
qq3YCkHZrq0OgO3anm0AsK0P1C3coi3czm0OxO3b8u3Xym3Y7q3bsu3dBu7fhm3b9oDh6q3a4i3d
+i3d8u3bxm3aPq7kjm3aRu7dQm7hNm7eJm7nDq4TRK7dYi7g+i3hgu7lli3qHu7klm4SOC7r7u3p
/gDnrqHlPu7rGu7ski3inq7n6m7jUu7wIi7n4u7k3i7otu7xsu7lQu/z2u7iZi7wzq71bu7iym3t
Tm/vXm/wAq/10m7g1m3zTm/wpq70gq/zii/1Gu/Ytm7ysu/yDq/50u/5Iu/2yu/+ou7qXv+U+4Zv
++Zt5VauAOPv/XYv7Bbw+w4w9ZrvAwtw4b5u/f6t/gaw5vqu+kIwA5evAgOw8IouBg9u7YJwBH/w
7hLvBmOuCvsv+m4v+/6u6a6w6GawCE+w/kpw7Oou4aavBa/vD2cZd8Zw5zKv+xKwCbsu966u5wrv
C58v5AIu2qpw8z6wElfvDFdw/wIwFv8wD3vvDdtuB0MvFVPwBZdwF39w+iLx+rJwCn8vF2PxEFsu
BOdwEYev/C7BAmfx58qwC1tx7rYv45qxB6tu9MquHQNxGDMBGSPxBuOwFV/vAtuv/0qyBhuy4hpw
345uAYtxIityEl/y9xYy9kayAk/yII//8e46Lu6Wbymjchc/Mg1PcANbMuwi8imzagDL8SfT8i5P
wRDrMRzzMhJ0cB2rsitHQSWbsSBPsfoegRj3rRHjbTDz7hxf8hZfcR+38TNvMQhzMv6+sDKDMzLf
cRPgcCOPLxrvXR638Dd7cSTHsjVf8O2esw3PcgszMPP6cBKf7Sg/sQw3synbsw4XLDALLh6Trgbv
Mz9zb+m6MzHz8TwbQT3L8h8bsiivsRfvqz2/LzPvMQJD9PyaMh6TNDdnMzbnczmH7kpntDOj9Ehz
dExrb+wyMumCcRl7Mj7rtC47L0JL9DwLMku/9E5rcy3/swsyc1AT70dT9D9T8jAbcEgT/7VTU3VT
Gy8uw+9M6zM5v3RQK7VSv3Ix260Tc7AbjzAyW/VQL/M093Fbwy9ZV/Q7W/QykzVGR/RRtx5Yp7QU
X3NfY3JYL7Ja/3RVK4E3F/ZgIzb/ovQpn/EB7/VP+/JFS/YV+/Qjk208y/Nj+7RjD3Zlx7NeTzXu
MkAL8PNf/3VTp7Vbw3Vqt/NCU/RrLzRlx7by6u1JCzYrzzJcw/RYEzQHnzVvi/Js169wa0T+1rVw
o/Y+s/Zb33NotyBpb210S/d0G+1o1wB1Y3d2azfMWvd2e/d3gzfHdnd4k3d5m3esjfd5q/d6s/cU
jLcTa/Lo3rJAQzZV+/Vmi/BEV+9X2/92URuBAAC4AOgAgA94gBd4EBB4AAS4gSu4gB9Bgjd4gUM4
hPsAhR84ECx4hu9Ahlu4Eiz4hROxX/P2Ejc3Udv1Y9+3UI9zidc356Y3LUtxQ7u05AY3W/fvKtM3
Z4v4Uusyjuu4P39xP+94gnN4DhC5gx+5kSP5kit5kz+4g0d4lCd5g394lEs4g/dAh284lDt5lnO4
loO4Nsd2QO+0RW+zjBtx9tKzbv/4VcdvlUE3DJ8wQ89tNct5JzP2ZG/14TbxVb8yF+c5TmM4k0v5
klf5lCM6of83lCd6lW95l2M5lXu5EHw5pQv4hFc6gfuwYhu1LIcuK7u0HiMvUKu4Xp//MSNH9osb
NA1HryNjMArTOE579UzntkqL9CeLtQdHNWdb9ZEfOqEnupMH+6L7OoNP+aNbuYd/OZczAYFbuKM7
umbLeh5L8JyjbxQ/cTBD9myjdhkf8ZHFefe+8bhL76gfr4/Xsp238xKncgLzeCCvsZ4jAbQzOpYX
e6MbO7P/wK9feZgLu6Ev+xIse6TzgLNz+bCHeGdr9TET90STsEnvsFuD9GGH8LkLObhftwVru7i7
MnzD+i5XMSQ/vJ+PMVf3OU+Lc5BHtsDrO7Ij/BMkOZh3OaS3vMwPvMwjeMAXupOHPCL395DFdzgD
9Ij/vGV/NBsfPSmEe5qrcSc89Hxn/zut0/QbqzaMn3ZfUzFmTwHCD7ylbznOV3i9X7mGN7vO57yX
Y3q873rbjrnWJ/PQD7XRT7wco/oTv/htL3Zpf7y7I70WT/xU8zSsu3GnC/q8F7m/DzvOg/2+iz2y
z7zitzyVR3vYLzo77/rGr72J67etC74tc/w64Hm5J30uK7zD13U3v/mNX7zHqzglC73eNzaQD7R8
e73jd73kH/vtJ7u/F7zOEzymV/qk277ZDzraH37C6/j95jCL2zcQ1zPrQ79gOzM0Y3us80DK5PXP
l/WfZ7b2c7zGu73mQzVhb37z737aOz7lz7zw9/7Zpz/7L/76oz+x+z6z43zQ3/Pvrv/6IWcuCEiB
KAajiZ7pWq5o2b7uHM9unZLuojC5BAy2hMIbEfgr2mRLpg3XjD6lqhcxCr1ZjzOB9ytIgcdNL2oM
Npm76HWg7Waf4ba2mE51wcPLbN8Jc+RXRQNoIjiY2CdoxPXXhMPjk0dZaXmJmam5ydnp+QkaKjpK
Wmp6KiWJusra6voKGys7S1tLqmqbq7vL2+v7CxwcgCtcbHyMnKy8fNvD/AwdLT1NDUssFZQzckW4
nX2YOeQ4pEU5uKXdXYW4sqeG9sZnmpYXd2f/jh9v1x6mL/evnrx3ZQYKzBSHXz55awLe+0JwIUQ2
bszAizenosF9F+vwucbuD5SRLMD/lTz0TV0NcY7QKVFXbh3KloXu9ItoMyM9jmQeWpyYZg/DhhDJ
7Izy0+jGORwxSjyqBw9TnDp7OqWicapWOVcPOrWHjyhVnku3LiGK55pJlkp0xEzXtlwMGHJT4ljp
JO8UkyrubuFmVuzNsQH1afyJMyvGpAMZF6QatOziogYRI62M2ezXjQ4HXwXrz45gShdBR306mHFk
rJkjqu1bci4jlYQCjYMbO503wHzvzja09vc5skA5U04tNWdT5YoRH3V8NnQ/ywCP2+xM3PTYzVEV
ek7Y0ePTiVw/h5862vzjy6ddOzs5FzjfbuTWysUtf7hu/TSQ6O0fEmsPBcYHduNp/6feZFYRt153
UPm04GSV/KNYTgY2aBpoFU7YmGTRVaiaTgS6o9UaPCiwwF9x9aZbbfDN15tdetFlzm/GiNahVRce
ViB59MAD3WZhCUUQdaetdqBkQg2FVo7nCdTkktwtx1prnCSFXEQXTtcjCgygWFMS2iDC30y8vbUX
mVmsRCYLjKhp5kvZkdeeFCQOSKWWxRUZWnN0kiZdYX1KV+eVe0bHpXcLbSced1LaOaiihuqJyY/y
fJkimpeMdCaMe0ES5iOe+IUNopBeImiTN4nF6qCJ/VmVn12tap1nBSnUaoOodgmejl3OasmWDvZE
omBD4srrpWBqGpJ+pLa4WzZ4Uf8x3LOQ2OhpgIUyumujjqkqYj6L9rpUhkNNGSuhtgLLFbm6cqsc
lQjulF6V65qqWYk+GpdluAFgGic3pDqrBZyfenqwigJTy/BJXsWb6JJPcrloow5SVK6VTNVLa5JG
4luex792S5iHHD8G3sPwOjTkvcoBTO1s2iqsCZs0/RfzzdGm9N/MEM/JypYsK1mWpNd5+HPI77p8
mdGFOo1echlNDfSwD+ar2Z3lwVxN115/DXbY0XAtdtlmn4122qSQrXbbbr8Nd9psx0133XbfLczc
eO/Nd99+r71stAjjDG3CMOU2U+GFv6mwf40j7NuKKs7Y6X4z7uf44SesCRPPirj/ia3DNeqs+Hyc
s1R6zz6nrjl8L30uKi1cDxwmYM6GHheNMiVOuIvZJuybpprzZq3D9eWl+/HbyGAbXc/WZzuoB7Ml
p/Cmx05C7tLzPnj38Qn+O4vGQz55964wMEn4JJFfquj2bS4+bPG/Ja31zb+ouB/KF5+E49+4Jb/d
yQ+A9nkeOuRTsOltr2Dr856Y4pO9hcVPf4f7nuXGFxy78AyBvTtf+sCnuwu67wm4K+AET1iI462O
gOIAh/8kSD/QbRCDLoJefkyIGwP+bobzQ94CrfAD0Z0OgQSMCfU+1UDahG9362tgEmeBvhh2Dmdl
cuBu1pG55KkOiE8UYRd9WJfM/1kieuLTYhnr17/OZTFOWwxii2A3xvwxgRxFQN0Ns8UmIRqxEf6D
0f9qFyoopo9xU4ScGH+InyIisYMAstG0mnczC6LEep3Aix3L6ELLVbGQcVReD3f2OgFS0Ydm9IYA
N5lJPy4OEM1inxpRGYooNoyGrAtY9WgEwFZ+EpSwpKQMK3et1dkSjnuEjQUVyUs/ilFNdOwZI6fg
yVI185Ss3CAzmXc5Z+5SeNFsXStkqT7QUa6XNXGe9FSYhy8ukHQj3FnsKkFMDJrzevwJYQedGM5G
hvJ9v/zjNNGJQsMxEVo6FCU/uWezXIAzme7E4ori2chUMtSUVCwhIlf5TCWiie1TLYGoG+FHn1cK
jAvxtKQv04Q4ac7RoW9c4ztDGghm7ZOhtwnYQWGxUP7V0p7tVKn5AvnTzVHwpZIkKvCAyroqIhOk
PX1pLefYpvYJFKlMpeo903lRQDbVmzz1YP+qt1VvDhOrY3VqgLLIUeKdaYXA9B0fXyec0G01rWBN
Klk54VFf5tV89cyqEeXKSHKCYqF/K6xhD4vYJRA2sYxtrGPrttjHSnaylPVaZCuL2cxqNm8f3Kxn
PwtaQYZ2tKQtbSnQh9rUqna1rG2ta18L29jKdra0ra1tb4vb3Op2t7ztrW9/C9zgCne4xP1tCAAA
Ow==

--=_NamoWEC-fg44f0yf5w--




From nobody Mon Jul 21 01:34:28 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397521B2B86; Mon, 21 Jul 2014 01:34:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level: 
X-Spam-Status: No, score=-1.748 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, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=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 XuKRGAOPk-Ey; Mon, 21 Jul 2014 01:34:24 -0700 (PDT)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69DE51A036E; Mon, 21 Jul 2014 01:34:23 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id z11so4526111lbi.31 for ; Mon, 21 Jul 2014 01:34:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xsnTh4eFpN6D0Ayiqx80BAkXEmsl8KfbrQ/RG1ZWQxc=; b=y/cK+BjdbtkY4GhMY0ECUNJocQ/VruA6xIKXrliWLsdS8SdAmW1GzMMgPe6Jfq0u1j wGO7+sWzb6R7r3xJi8UoUvnvrsGxirZrJogOTd5HccMso3ja7qTeykH3+iFS0bda3gVu kVaDKUoJvWqE5234/A/UzZ88MLSs4gDliFEqO90K7ZH5ZraO7qansQepWakGRQtq71mT QQWVzm4R7421InqqtJbjN1/Il+pYp2s7LhZR5GiZqc3fv80fd6JchT9lxjikkgpRHSVQ XPmgVLQnViDaAb6zDOLiYUCZQTxnwIiw3LScz0YxnbGmUzOgv/CcjYIDPU1gYX3ingml eWWg==
MIME-Version: 1.0
X-Received: by 10.153.7.74 with SMTP id da10mr24471829lad.27.1405931661618; Mon, 21 Jul 2014 01:34:21 -0700 (PDT)
Received: by 10.114.243.202 with HTTP; Mon, 21 Jul 2014 01:34:21 -0700 (PDT)
In-Reply-To: 
References: 
Date: Mon, 21 Jul 2014 09:34:21 +0100
Message-ID: 
From: Kevin Dempsey 
To: kiran.guduru@samsung.com
Content-Type: multipart/related; boundary=001a11346d5c4512a404feaff9c8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/089o5j5pz2nqi04uEHYS51ZOE1g
Cc: "rtcweb-request@ietf.org" , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 21 Jul 2014 08:34:27 -0000

--001a11346d5c4512a404feaff9c8
Content-Type: multipart/alternative; boundary=001a11346d5c4512a304feaff9c7

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

Would the browser be expected to act differently with "a=group:clue"? If
not, then that is really part of the signalling and not part of the
createXxx/setXxxDescription interface.

The SDP passed to setXxxDescription and the SDP sent as part of the
signalling (if SDP is used) do not need to be identical.


On 21 July 2014 03:35, Kiran Kumar Guduru  wrote:

>  It seems there is a small mis-understanding here. I agree there is a
> need for parsing and editing SDP by JS application for now.
>
> I am not saying that constraints will do everything.
>
> My intention is, to find the possibilities to extend the API of existing
> RTCPeerConnection and proposed RTCRTPSender/Receiver to add the attributes
> required by JS application.
>
> For now, I proposed solution for one such kind of problem, i.e.,
> prioritizing codecs.
>
> setSdPAttribute (key, value) is just an example on top of my head, which
> might solve this. But we can really figure out this after getting the
> proposed API (RTCRTPSender/Receiver ) in draft.
>
> Regards,
>
> Kiran
>
>
>
> ------- *Original Message* -------
>
> *Sender* : Paul Kyzivat
>
> *Date* : Jul 19, 2014 22:35 (GMT+09:00)
>
> *Title* : Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
>
>
> Kiran,
>
>
> My need won't be satisfied by plausible constraints.
> For instance, to interwork with CLUE it will be necessary to add an
> "a=group:clue" and include in it those m-lines that are to be "clue
> controlled". And that is needed in both offer and answer processing.
>
> Thanks,
> Paul
>
>
> On 7/18/14 10:41 PM, Kiran Kumar Guduru wrote:
> > Dear Paul,
> >
> > My comment is only regarding the comments on section 6 of the JSEP draft.
> >
> > The sdp mangling described in section 6 may result in various error
> > scenarios.
> >
> > In that section, it is described like most of the parameters can be
> > modified thorugh constraints.
> >
> > The required modification, I found, which cannot not be done by the
> > constraints is "Remove or reorder of codecs (m=)"
> >
> > In order to avoid the SDP mangling at Java Script application level, I
> > submitted a draft for changing the codec preferences
> > http://tools.ietf.org/html/draft-guduru-rtcweb-codec-preferences-01.
> > (Please review it).
> >
> > If this proposal is acceptable to the group, I hope we can remove
> > section 6 from JSEP draft.
> >
> > (Expecting that we can find alternatives for adding extra attributes
> > like CLUE as identified by you, for example by extending the
> > proposed RTCRTPSender/Receiver by adding a generic setSdPAttribute (key,
> > value) method).
> >
> > Thanks,
> >
> > Kiran.
> >
> >
> >
> > -------Original Message--------
> > Sent: Paul Kyzivat
> > Date: Fri, 18 Jul 2014 14:32:24 -0400
> > Subject: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
> >
> > I just did my first thorough read-through of JSEP in quite some time. I
> > came away with a number of concerns:
> >
> > Section 1.1:
> >
> > When describing offers, modification by the application is mentioned:
> >
> >      JSEP's handling of session descriptions is simple and
> >      straightforward.  Whenever an offer/answer exchange is needed, the
> >      initiating side creates an offer by calling a createOffer()
> API.  The
> >      application *optionally modifies that offer*, and then uses it to
> set
> >      up its local config via the setLocalDescription() API.
> >
> > but when describing answers it is not:
> >
> >      When the call is accepted, the callee uses the createAnswer() API to
> >      generate an appropriate answer, applies it using
> >      setLocalDescription(), and sends the answer back to the initiator
> >      over the signaling channel.  When the offerer gets that answer, it
> >      installs it using setRemoteDescription(), and initial setup is
> >      complete.
> >
> > And Section 6 only talks about changing offers, not answers. It is
> > equally important to be able to modify answers. (More on this in later
> > comment on section 6.)
> >
> > Section 4.1.4:
> >
> >      The only difference between a provisional and final answer is that
> >      the final answer results in the freeing of any unused resources that
> >      were allocated as a result of the offer.  As such, the application
> >      can use some discretion on whether an answer should be applied as
> >      provisional or final, and can change the type of the session
> >      description as needed.  For example, in a serial forking scenario,
> an
> >      application may receive multiple "final" answers, one from each
> >      remote endpoint.  The application could choose to accept the initial
> >      answers as provisional answers, and only apply an answer as final
> >      when it receives one that meets its criteria (e.g. a live user
> >      instead of voicemail).
> >
> > Issue: in this forking case, until the final selection is made it is
> > unclear which one will need ICE completed. Only when a setlocal is done
> > on one of the answers will ICE begin to be performed. Then, if another
> > answer is provisionally set, won't that stop ICE for the prior one? And
> > won't it require new candidates? What if one of the earlier ones is
> > eventually chosen as final?
> >
> > And what if ICE completes for one of the candidates? Can't media start
> > to flow? Then what if a different candidate is set as the final answer?
> >
> > Section 4.1.4.1:
> >
> > I question the following:
> >
> >      ...  While it is good practice to send an immediate
> >      response to an "offer", in order to warm up the session transport
> and
> >      prevent media clipping, the preferred handling for a web application
> >      would be to create and send an "inactive" final answer immediately
> >      after receiving the offer.  Later, when the called user actually
> >      accepts the call, the application can create a new "sendrecv" offer
> >      to update the previous offer/answer pair and start the media flow.
> >
> > This is very unfriendly when receiving calls that might be forked. By
> > immediately "answering" a call before knowing if the user will accept
> > it, you preempt the possibility that it will be answered on some other
> fork.
> >
> > For instance, if a call could come to your browser, or be sent to an
> > answering service, and your broswer is on but you aren't present to
> > accept the call, then the call will be accepted and then dropped rather
> > than sent to the answering machine.
> >
> > So this technique should not be used if there is any possibility that
> > the request could be coming from a source that might try other
> > possibilities.
> >
> > Section 5.2.1:
> >
> >      When createOffer is called for the first time, the result is known
> as
> >      the initial offer.
> >
> > By this definition, if a peer connection initially *received* an offer
> > and sent an answer, and then it later sends an offer then that offer
> > would be considered an initial offer.
> >
> > I think perhaps what is intended is:
> >
> >      When createOffer is called before setLocal has been called with
> >      an offer,  the result is known as the initial offer.
> >
> > The following doesn't support the "balanced" BUNDLE policy:
> >
> >      Once all m= sections have been generated, a session-level "a=group"
> >      attribute MUST be added as specified in [RFC5888].  This attribute
> >      MUST have semantics "BUNDLE", and MUST include the mid identifiers
> of
> >      each m= section.  The effect of this is that the browser offers all
> >      m= sections as one BUNDLE group.  However, whether the m= sections
> >      are bundle-only or not depends on the BUNDLE policy.
> >
> > Section 5.2.2 says:
> >
> >      o  If any MediaStreamTracks have been added, and there exist
> recvonly
> >         m= sections of the appropriate media type with no associated
> >         MediaStreamTracks, or rejected m= sections of any media type,
> >         those m= sections MUST be recycled, and a local MediaStreamTrack
> >         associated with these recycled m= sections until all such
> existing
> >         m= sections have been used.  This includes any recvonly or
> >         rejected m= sections created by the preceding paragraph.
> >
> > This fails to say anything about codec compatibility. SDP O/A requires
> > the answer to be a subset of the offer in terms of PT/codec
> > configuration. You should not use the same m-line unless there is a
> > desire to use the same settings for the new track as are currently in
> > use in the other direction.
> >
> > Section 5.3.1:
> >
> >      When createAnswer is called for the first time after a remote
> >      description has been provided, the result is known as the initial
> >      answer.
> >
> > By this definition, if a peer connection initially sent an offer and
> > received an answer, and then it later receives an offer then the answer
> > to that first *received* offer would be considered an Initial Answer.
> >
> > I think perhaps what is intended is:
> >
> >      When createAnswer is called before setLocal has been called with
> >      an offer,  the result is known as the initial answer.
> >
> > When specifying the mapping of local tracks to m-lines in a received
> > offer, there is again no discussion of codec compatibility. It is quite
> > possible that the m-line chosen by the algorithm in this section won't
> > have compatible codec attributes, but some other m-line will.
> >
> > Sections 5.3.2, 5.3.3, and 5.4-5.7:
> >
> > Are these empty because the content is yet to be written?
> >
> > Section 6:
> >
> > Other likely changes are addition of extra attributes and maybe other
> > parameters. For instance, CLUE will want to add another grouping
> construct.
> >
> > Thanks,
> > Paul
> >
> >
>
>
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

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


Would the browser be expected to act differently with &quo=
t;a=3Dgroup:clue"? If not, then that is really part of the signalling =
and not part of the createXxx/setXxxDescription interface.


The SDP passed to setXxxDescription and the SDP sent as part of the signall=
ing (if SDP is used) do not need to be identical.


On 21 July 2014 03:35, Kira=
n Kumar Guduru <kiran.guduru@samsung.com> wrote:










It seems there is a small mis-understanding here. I agree there is a nee=
d for parsing and editing SDP by JS application for now.


I am not saying that constraints will do everything.


My intention is, to find the possibilities to extend the API of existing=
 RTCPeerConnection and proposed RTCRTPSender/Receiver to add the attributes=
 required by JS application.


For now, I proposed solution for one such kind of problem, i.e., priorit=
izing codecs.


setSdPAttribute (key, value) is just an example on top of my head, which=
 might solve this. But we can really figure out this after getting the prop=
osed API (RTCRTPSender/Receiver ) in draft.




Regards,


Kiran


=C2=A0


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


Sender : Paul Kyzivat<pkyzivat@alum.mit.edu>


Date : Jul 19, 2014 22:35 (GMT+09:00)


Title : Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07


=C2=A0
Kiran,


My need won't be satisfied b=
y plausible constraints.
For instance, to interwork with CLUE it will be=
 necessary to add an 
"a=3Dgroup:clue" and include in it those=
 m-lines that are to be "clue 

controlled". And that is needed in both offer and answer processing.
Thanks,
Paul


On 7/18/14 10:41 =
PM, Kiran Kumar Guduru wrote:
> Dear Paul,
>
> My comment=
 is only regarding the comments on section 6 of the JSEP draft.

>
> The sdp mangling described in section 6 may result in various =
error
> scenarios.
>
> In that section, it is described l=
ike most of the parameters can be
> modified thorugh constraints.

>
> The required modification, I found, which cannot not be done b=
y the
> constraints is "Remove or reorder of codecs (m=3D)"=

>
> In order to avoid the SDP mangling at Java Script applicat=
ion level, I

> submitted a draft for changing the codec preferences
> http://tools.ietf.org/html/draft-guduru-rtcweb-codec-prefer=
ences-01.

> (Please review it).
>
> If this proposal is acceptable to =
the group, I hope we can remove
> section 6 from JSEP draft.
><=
br>> (Expecting that we can find alternatives for adding extra attribute=
s

> like CLUE as identified by you, for example by extending the
> p=
roposed RTCRTPSender/Receiver by adding a generic setSdPAttribute (key,
=
> value) method).
>
> Thanks,
>
> Kiran.

>
>
>
> -------Original Message--------
> Sent: =
Paul Kyzivat
> Date: Fri, 18 Jul 2014 14:32:24 -0400
> Subject:=
 [rtcweb] Review of draft-ietf-rtcweb-jsep-07
>
> I just did my=
 first thorough read-through of JSEP in quite some time. I

> came away with a number of concerns:
>
> Section 1.1:
&=
gt;
> When describing offers, modification by the application is ment=
ioned:
>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0JSEP's handli=
ng of session descriptions is simple and

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0straightforward.=C2=A0=C2=A0Wheneve=
r an offer/answer exchange is needed, the
>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0initiating side creates an offer by calling a createOffer() API=
.=C2=A0=C2=A0The
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0application *op=
tionally modifies that offer*, and then uses it to set

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0up its local config via the setLoca=
lDescription() API.
>
> but when describing answers it is not:<=
br>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0When the call is accepte=
d, the callee uses the createAnswer() API to
>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0generate an appropriate answer, applies it using

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0setLocalDescription(), and sends th=
e answer back to the initiator
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0o=
ver the signaling channel.=C2=A0=C2=A0When the offerer gets that answer, it=

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0installs it using setRemoteDesc=
ription(), and initial setup is

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0complete.
>
> And Secti=
on 6 only talks about changing offers, not answers. It is
> equally i=
mportant to be able to modify answers. (More on this in later
> comme=
nt on section 6.)
>

> Section 4.1.4:
>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0The =
only difference between a provisional and final answer is that
>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the final answer results in the freeing of=
 any unused resources that
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0were =
allocated as a result of the offer.=C2=A0=C2=A0As such, the application

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0can use some discretion on whether =
an answer should be applied as
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0p=
rovisional or final, and can change the type of the session
>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0description as needed.=C2=A0=C2=A0For example=
, in a serial forking scenario, an

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0application may receive multiple &q=
uot;final" answers, one from each
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0remote endpoint.=C2=A0=C2=A0The application could choose to accept=
 the initial
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0answers as provisio=
nal answers, and only apply an answer as final

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0when it receives one that meets its=
 criteria (e.g. a live user
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0inst=
ead of voicemail).
>
> Issue: in this forking case, until the f=
inal selection is made it is
> unclear which one will need ICE comple=
ted. Only when a setlocal is done

> on one of the answers will ICE begin to be performed. Then, if another=

> answer is provisionally set, won't that stop ICE for the prior=
 one? And
> won't it require new candidates? What if one of the e=
arlier ones is

> eventually chosen as final?
>
> And what if ICE completes =
for one of the candidates? Can't media start
> to flow? Then what=
 if a different candidate is set as the final answer?
>
> Secti=
on 4.1.4.1:

>
> I question the following:
>
>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0...=C2=A0=C2=A0While it is good practice to send an immediat=
e
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0response to an "offer&quo=
t;, in order to warm up the session transport and
>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0prevent media clipping, the preferred handling for a web =
application

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0would be to create and send an &quo=
t;inactive" final answer immediately
>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0after receiving the offer.=C2=A0=C2=A0Later, when the called us=
er actually
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0accepts the call, th=
e application can create a new "sendrecv" offer

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0to update the previous offer/answer=
 pair and start the media flow.
>
> This is very unfriendly whe=
n receiving calls that might be forked. By
> immediately "answer=
ing" a call before knowing if the user will accept

> it, you preempt the possibility that it will be answered on some other=
 fork.
>
> For instance, if a call could come to your browser, =
or be sent to an
> answering service, and your broswer is on but you =
aren't present to

> accept the call, then the call will be accepted and then dropped rathe=
r
> than sent to the answering machine.
>
> So this techn=
ique should not be used if there is any possibility that
> the reques=
t could be coming from a source that might try other

> possibilities.
>
> Section 5.2.1:
>
>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0When createOffer is called for the first time, t=
he result is known as
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the initia=
l offer.
>
> By this definition, if a peer connection initially=
 *received* an offer

> and sent an answer, and then it later sends an offer then that offer> would be considered an initial offer.
>
> I think perhap=
s what is intended is:
>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0W=
hen createOffer is called before setLocal has been called with

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0an offer,=C2=A0=C2=A0the result is =
known as the initial offer.
>
> The following doesn't suppo=
rt the "balanced" BUNDLE policy:
>
>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0Once all m=3D sections have been generated, a session-=
level "a=3Dgroup"

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0attribute MUST be added as specifie=
d in [RFC5888].=C2=A0=C2=A0This attribute
>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0MUST have semantics "BUNDLE", and MUST include the mi=
d identifiers of
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0each m=3D secti=
on.=C2=A0=C2=A0The effect of this is that the browser offers all

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0m=3D sections as one BUNDLE group.=
=C2=A0=C2=A0However, whether the m=3D sections
>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0are bundle-only or not depends on the BUNDLE policy.
>=

> Section 5.2.2 says:
>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0o=C2=A0=C2=A0If any MediaStreamTracks have been added, and there exis=
t recvonly

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 m=3D sections of the a=
ppropriate media type with no associated
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 MediaStreamTracks, or rejected m=3D sections of any m=
edia type,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 those m=
=3D sections MUST be recycled, and a local MediaStreamTrack

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 associated with these =
recycled m=3D sections until all such existing
>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 m=3D sections have been used.=C2=A0=C2=A0This i=
ncludes any recvonly or
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 rejected m=3D sections created by the preceding paragraph.

>
> This fails to say anything about codec compatibility. SDP O/A =
requires
> the answer to be a subset of the offer in terms of PT/code=
c
> configuration. You should not use the same m-line unless there is=
 a

> desire to use the same settings for the new track as are currently in<=
br>> use in the other direction.
>
> Section 5.3.1:
><=
br>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0When createAnswer is called for =
the first time after a remote

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0description has been provided, the =
result is known as the initial
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0a=
nswer.
>
> By this definition, if a peer connection initially s=
ent an offer and
> received an answer, and then it later receives an =
offer then the answer

> to that first *received* offer would be considered an Initial Answer.<=
br>>
> I think perhaps what is intended is:
>
>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0When createAnswer is called before setLocal h=
as been called with
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0an offer,=C2=
=A0=C2=A0the result is known as the initial answer.

>
> When specifying the mapping of local tracks to m-lines in a re=
ceived
> offer, there is again no discussion of codec compatibility. =
It is quite
> possible that the m-line chosen by the algorithm in thi=
s section won't

> have compatible codec attributes, but some other m-line will.
><=
br>> Sections 5.3.2, 5.3.3, and 5.4-5.7:
>
> Are these empty=
 because the content is yet to be written?
>
> Section 6:

>
> Other likely changes are addition of extra attributes and mayb=
e other
> parameters. For instance, CLUE will want to add another gro=
uping construct.
>
> Thanks,
> Paul
>
>




=C2=A0


=C2=A0










_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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





--001a11346d5c4512a304feaff9c7--
--001a11346d5c4512a404feaff9c8
Content-Type: image/gif; name="201407210805126_QKNMBDIF.gif"
Content-Disposition: inline; filename="201407210805126_QKNMBDIF.gif"
Content-Transfer-Encoding: base64
Content-ID: 
X-Attachment-Id: 865003316a9639a_0.0.1

R0lGODlhCAKQAMQAAAAAAP///8k6OspMTNRiYtt0dOSOjumiovLExPfZ2fvt7f/+/uvr69TU1Lm5
uYyMjG9vb0dHRzMzMyoqKgICAv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEA
ABUALAAAAAAIApAAAAX/ICOOZGmeaKqubOu+cCzPdG3feK7vfO//uYBwSCwaj8ikcslsOp/QqHRK
rVqv2Kx2y+16v1YReEwum8/otHrNbhcX8Lh8Tq/b73al2M3v+/+AgYKDVniGh4h1egyEjY6PkJGS
k0OJlpd5SXsBDQ6engwNjFKilHoNSaVYqkisTK5CoUqdo02waLJMubGogg6Nt1S/a3IIeAoJmHAJ
CnTIipq1EBETFBERDRHDUdqmSQ8PSd1GENzbR+NN6UPgqRPYr+Hrae1MDhFE94MUfA3hRvOKlHPC
z8xAIXIG4EFQAJGBOQWMzWEIDckmIfqEBFR3zhuWgk82DhGJrmOAekcy/zJpR5IMSiUqA8T8A5LN
yyc1l+QEU9MSxUMKD/2cs6iIyggQKExAxSCCtVoBmlKgIC/pBEZSIzBw8I/ryWr/hDSYRjUpvq9U
ozpdGiBp2rZTyzUAO9BqLyHt3IZt22Cs03Jm0YbzS2HgA2sTfj0AixfxNqlsszLqtjgtuAfDMA+p
BlgpqgdJh82d8ACpZ7VPiUA4HNlp2tVKHVT7NbewWKUR9kpNy4Azvt6F8SGdIBg1W71C7CY/rTru
ycr/kiYlAm620+hxm4o9K5ax5Las+04gvTschL5kD8LFBmFCZ9twp8NlO6S21uJfE7dNygD6+kpx
NGTAAQMQkIwCBAxggP+AySTw0AEJPmTAAAU4SIABBiQDIYUKDCVHUflwd81JgJWomlz8UMMABCay
OFdyDzBAgXh3OTBjA1T1JsqNS5VG4lxbEVeaCEut1hQ+i/VHHDsPACkbEdrYuGNfFDggI41SXnml
jVbyiGWV7CDZYjnaXDmXP+CcNWOY/ly12En3xeLiiKDtZ+dISOLDIicpCucmPuTlFkBiMu61J47g
HZnoiFWK4KWPoDkppJuTKkmdVjomieiQ8uHl5o38DKkjW3Vu5gCOK5pIp1YuHpqiJzNeWV+VNjIi
ao+shkoplPLE6OWVbyLlKI04bpPQAgU0dICAByiQLLLGUDSAMQMkkMD/tAgMoICzCChQLbIHeBgH
iEMc9Ys+a8pIhBg2BiCoumsiqh8F/dUVVkYFaVPqaj6KIBsjvQCcGL0yCTcMfc8ByQmUnpzVTaj2
ZqTvQIntCw7F2/TLSLyvWgyOjEGG6O7BaBbB0rn4pFtTN/qw++pzBb8Y85KrrctIuwT7mHPKeNmr
8b8Lj7OU0HdFxUnF/7yMKJMFC1GQwA7sqV93GMmKKMtIhuPyyBKfw49KUHdzNckjDUYijKXKo5i9
AfQUh0IRLSBtM8tCK3dD3yazgEI/xd3ggOLCQS5GIqLc9lRTEWHfy2037jR4Lx6G+L1qasQV4jlS
E2N8TK01MOHuYp6x/3mFFR2lw7+EijlmqNej7+quP6b5xkN0DHuvNZdrsOU3ndw05isbvvjIMN9j
I+LanPXS8AWhC3pBkk8V4+ych474PaIPARnSj49TUzv4GpcYkDXFBNLL+rQz/OmWE/H1Wdsb3332
3QkaPVUvUba64wi9bbe0cKBI3CgCobjt7W5wiNuECECAcDWEDoNrWvucJxYiTO1l8MLK19xTjnoU
LXwj82BUQtGeqPiDXnsaGcH0MY6iqa8/BLNc1xonwq7FToSx0x4JiUMwdenrH58JB2jWpDviDYor
e4EZ1vhnOsNdkHjgS14stqK8vTyxeTz7HV6AOMKxECcUh2mKaIxYtP8U/rB7w/heOMJnxl9wUGQy
AVlU0Je1QSWNa6hznwTb6D0yKq5g/KpgPdQGs4XxLwDHGiDeAtgQRS6AGcs6wAH7hoBl0c2BFTnC
RSRIPBaucUlOs1WKOigcIZ5lPKgAmqBA57goXcVdoNEaVU4pv2KxSFH9QthlaDmShrVvg5NhneVe
VCxVYoY4xRpCzXxoSq69MjftkBEoQeejTSXRd56UyTSXmLOXRbFtnynHmkjjPlHCsi2lRKfjjLnM
WQqhYr/BVVQQJrYq1QNiJ1GjBJUGptAUgV4gs9/u0heObuKxfbWTYD250sFQxfMuhLqHwnLzoiex
7JkFxQgi/efIAkj/ckHgWsCyEkCAZgxokg+MyAEegiBMQjAaRilc03DklHO0xz30okY1UEFTIjpF
meOZJgi7cVNkIiZGQcWHjaiRG+BMY57UUM/HksqwGY5nRUFV6C+KutWstiWo26ApOXuKCqJm1XVJ
bNl4wNS7WQrPGmDqZdNuyh/KrBFJ71jTYsZjqPHwR6z4GM07+FdUPs2Oqr2JKlTdkw/EQPOOvckr
de76uKW+Y4072SuKnFJWwx0GNH7NqS+N+M7EnMWyTR3PTxPLWHYc9avjSc5sjFjYQV2FH4mMVkNI
ysCGZCtZAiJAAQy0AAZS0lvDxVDgFhDBJpzKCH0xSi22ApUidAIK/9eNxXMxcpfsnsRW3NluSoqm
BytxwiT5gIp342iErdyFutA1CcLGOwvylsu+0MVvfGsR3fyuq2i7sO5jxCtemXzQvutNCXbPUSrr
vte8reCpfjUJYbF05ML2ha+F84Ff71I3HIh4RhysVQyJLKBDzZgDig3RXI9MYTGHQa+Ln+CXGdsY
DIuR8Y2x0B+PiEAZQA6ykO/AJB0bYchITrIcFNAsJTs5yDvOgieiTGUt/BgTzLhElp9siS0X48R6
C7KXtZxiMSNgzGM2hIjn4OU1TyTMSXYzi1NRXezWeRBGhgkYaHNn66q3zyaUQp4DrQmeArrQTbgy
HB5yCAMmwtFcbv+0if13AEkKudJAxnSQfwtpSN/hIct19HIN0EAlg/qBiDiCP0grhZtoQTNLWJFO
qLATLYQqiSVhWBJm0oRaxxQmu3tCOXitSQYcS9KX8HSkM23pIGsaE89WRrQDNOk7BMUOyqZDtoF8
bUscwXeEaAkrk+BrJpT7CucuwjpIQmwstHvcUHhfoo29aAqJtECWJhBxC7DAZAyoQAcqAIfs1u9H
ChxDzoJDwkccoQSSesQLGoAkLYShBBQgxRlS1sQbfm9+N4jj1xJusx+ZoH0T6OKPLJBHi8FASTpr
4P82EG9XqiEKEcAYG5p4xCVEIQedWOASt9syJKTvBBT95SjHULX/Ir5Se9+bQxOqEEsFnvSij0sy
siGNaVqTGhY9JRtb7Q/pyDkfF1ZmbVWqTUOXovbupOUvZV9OpwqZNb7KvSDKGWJYq8GW3FhDI4ep
HPjsXh53WWUyilHKXlrmGsw00ysjeY7d10NFvnCiHE7VE3rgHrqnKtMasuE8a3RD75SfWebaIqnR
CYAsZT3kWXXD0AJkr9KLQ2j2BnBWQ4i7Ujk0sKV761YcstUsbWVrWxE5KUkPiOnfe9RbHZpWcZu1
8ptfa+SlrlvQq3/moMfh5seXPe2VdfGKR0T12Tp9t4xfLW9ZC1sCesjyRd1I8jurWeJ/fe6z9f5m
ydzk14IAFJF//60nUqhmJ7c0J2KCgGQCAWJkI76SMFfxJEPyJK7VCUJyH+QRKEg1PeEwPvSyGP6g
FRSYK5P1OEnSLpziUCHzJhbUTIXRFAXlgIJya0dUK4dCHCqyJ9pwJqhSRK7CQvyQOyg4gSyIFCxk
ODxoMFkyIyuoOLQSK/TigzE0QsfSe7NXaYwmSR2lW3vTIHDDEJZmINqCQLJ3cwzHSAfEcovmUrUn
Ug+hEJWGAKx3N1gIfnXIEMuXhUt2YtoHB5W2hye1DHnofin3PxoHLXdYSYwGOClFLQi0LXIThsPX
SF4YN3lDiT8RFH7zc5LEN3gDhog4LhyjRIajMlCUJlIEDkBTVv//oEsUUzIWmISziA2vZCXZNChg
xycnSEN3VE/npIs3gRU6k0opY4y+KDNWsjWr1DFsAzpbww/WsIsJdU/EsxVJ+DvgdVAj0w3qokc2
9IxWSGkDUI4SF21diEDXFoYGFBFBQRGq120/AUDF8EBz+IjFZTdyGC7mSCGaFhHZYo4RYY8jp2/P
EhT3CIjN5iHrOIqYplKWplL96IaQCI8JInBCh0Dp2JCOtIYKVCClBopreEAdyVznY4q/gzmdhBQw
JkSkcx7WMxWjwzuU1TRRgjlSVESuIZN9xDS+iEbzcz1t9Q5ZREHOw4rccTRwZUS2MzlFNDyJ4R7t
okfWmA7ZaJT/TIg6PZlQNrQ/U3SFlqYh+TaKjlSG3gItBnRzZfgTF8JoAZSHi1SPCklJ01eG+/gT
27KIeNkhBMlwyUCPCSlSC/lA69cMZ+lID1lJEamYy4BA+ohAaEiSJiZAl0gthqmJD8SJlYRymCaS
ZomZpKhBKElBQUMboAd6MANGQzNGPnlGtciN/nJalddCTNmLNtg4fUSby8MWWLlOPIOUVfNE3tgx
XFRETzQNuUEN/1RISuNL3AQ67NONv/CNXNk6xfmV/kNSzeBRy0eHZHmJklQ3b3gtuKd79VZt37Jy
3TaJyWAgdAkhjLaPXwiH1xJ91KIhcdgMpfaWCRSXnamfI6ct/+63cuLphYm5fAGoneBCl55JN5So
hulIoJbomJrZe8AnkhI6ioIjUKOZThZ1MDqYM2nyTlzxG1X4JtbkNK5IPHolTsOSPiZaL/lEHcN2
m/h0GHAyR2KXD0vCKOZRUD/6kwA1IwaFFDnagxhVRAYFYzaiHj9JQx0EAdnkI4LyVNGpLyYIjqgz
UWGhaMVVUqTGQIuWIMaQjvBIIenZLQxUagiiIIS5npPIQM2wnnTIQKeWQMZwfXAgnyf3LfqGhn1a
cy3ne3bKeggZniBZkHaacgKXDIjJhd0SpmgoqY4ZN8YVXBdSLfT3nYyaphSKp8jVll96po2qocxF
VvlUGm9VU/9G9FMlBDOIpVNSFVQu6SlX9VWXw1n5gSI06FeLVRM09VPWyFr80BS+ehNBVUKI8UrL
SjvtoFmwlRTZsFadBVtCpSehRSW+kkQ2ClUzog9LNSKClZXtIx05MR4zVFvYqXDClwCTJnyJsGJv
Boh0Y49uKQfuegd6WG2WsGJGBwfEdWLwCmZ1MLB1IGfLEGbyiggGm692sLAkFmQLewgLW7EG+1Ia
xgn4lbFOUGAF9hwfu2HlghUV1l/nxV35QGFLgGEwUQv0sg0vmwrdRV7olWCKM2FOwLGExgtLoBlL
oz0Vpjgd4aXLhgcQQiA4F5mXsFxAhiALUodFG7VSO7VAFgj/rlZly6lHWCsMs+SkUUC0VDsHcxhA
/IoI/+pkRtdkYbu2bNu2gTBlW4sE1xS3wnC1ULAJuxBgQgtdgIZEYJC3OGsEnxC0W6C3WsAKnTC4
h8azMPExXICNcFu4gdtegwYgIwZnbftIZXYMmMu5dUBiZbtpSztkz5Bmn7stnXuwqZsHm6ASxLZU
ACFj17AYXhsGHWQenNRr16CrWzBsSbkF6TAN1XANk/tuXwFai9uz2xCut6oJtUsOudsEItgKezEH
F5K5jwSpiDBtC4FqctCZTwandRAuIwlklEkH9wotTKtwDzJyLNa64fW7WwQFPjJPlduxSZluSAAS
DZYF+msF//NgvL9Gbr1AhFNglSKCa3A0awe8SkbwEvg6XNibmMu2XNy7ttu2tN47B+K7vo55CSNU
RNQEHaMxPdLDF150EAjzXP5BGEMUWGSBHWwBFhczjZjnFPfhd3HyONBZQtAha2qhlHKRHusxFkIM
eKlRH3y3efAReFMjwilceJmHGjvcNqNQCt8hFVGaGLJhG3vVCyrBEiWkHIyhHFpcxHLBGUhcxYOi
HW7XJJO3UQppABIRc+5qaZUUB/8omAnickD3UX8zc/wGcCSnIA7XQAdgccD1cwPXpiA1YirHhYV8
cS9HXCRlyODij3KKLFlIyC93jgxkcfVGXHZ8sBHCIJdcfv89R2oVV6dB53Ozd8mVtnGG7CAH9yHw
W0SagkLn4SpcA1AJVQQycipLISU4glSdkCMhuCsiCA7FpCcm8nZ7wb/itIxSeCZnw4FNSCW+xIFt
0ysWpBjacM1nwiUDXCupwotGMiJ7kkLJQVHKNCa9wRWvxIFzsTmcVIOKwcw9siu3BILd7IHfHIwY
UQ6vdESo4iKWW1xGx2iwVyGc2GyaJoclRZ6yR56KpADm53rTd3/Bx2TNIoAgRYADYp7ft36fGFIe
VTe953yf6H+vl9IPjXskR1LFJ1IldXszjb7UZ4krx53YIqAAKXHo94gQkrYd3UD8Z4iCk8sjjIJa
czOvMhP/mRUxleNMMEI0BNU46MJT0ji/tXMNO+U4FlMzFLUkxpNH7yMzOgPWFdQfOTkxJHrO8CPV
VpyjqEijp4GKK1QyyhhsMmENOsXDWh1sS9HXXG2LeJFFL1EzNaOMO2q5y4cgeAqZhanHliafBySJ
2eKQ2ssQ3mmAa6hpqjefZ1mGdUOIbUiSEyfaqAuXHolzMu2FnE2JD2ogJZkQ9YqWrY1SeBrajvjb
GreHK0WXTV0LrltHP7k+o1U70xXZwNlKo5UmorPV8naS0DPNnxDM9yNMRog8M/Q+GUFBLyE512BD
/xDAp3UWzPM8KtleewI8hwQ+OElasuEJd5Evw8A+O1kl/zkh3utN1lb0DowVExAcQBRSqog5IN47
0YK5p5MMmhQM2oTpn2OY2f24hkPxE+BLUivnLL8XkOUYl3EDvo6UyrYtdAPphXTwjpbo4ZldqQJI
kJREQC5F4ZV93Eqsy3fUDmQ31b+bDrFk1YQ93apaQdatjXMk4FqrtSJUKMSREbH5SwXzmtmtxMaI
3gglwhlxRc9TH+UCSqSJCs0ji3Vt3/Kr3ySajQtT5olt5W49F58gb3F04AuKACd14gpSkDHu4JEp
4Z8dEbB9qKIN4Y3p4pWokAf0l/yGuqS2l7H94KC5nymelqD9wcdGmYwehzL+E8GtvhoX2jiekSFc
O71gP/89XlDmFJ1hjhXjcxU6MlSwggryFOt1JG8ceuXBrLXG5C7NGE7h/TsrquvapBFx7QlGdWEB
ftc4WqUeOk1xVSeC8qGwdE/hhOZGAD2BJW/1K1rndN3D7tZE+DDDEk2o4D+q3ZECt7m919kOjtpw
E56JWJaOmtKCWZ8BIkneuXKPvKftmdI3x5cnddr4Gekm7oXw/ph1g9G0DWf8boloCEA13n7uyXre
MuOSXu90aQyl7ilMZSupHq2ixWvtcR2y5R6VJ91Zh/Ksxas+blqGtSbEfkg8bK2N0QuLwVlWBfN7
xaxubVvuAfPEw1V0ffJ/5Vgxfw42ElQAA1e0cVb/kPP/a9Iew8BrT7NWpumABJ7GsWVb6cP0TP5O
d1En0PpZ7QCI3qstHZnakJwsmq0QYToh0bfIBLIsBrqmc6qQBGKO3SdwebqmDb6mKX1yDXQtwxWe
wvUtminpoxj32vLoCoEgZOrZ+Ar4imhzknSpv72mjAb43TcgiC+nDMpcm+RetjC5FlY0NhtT6yVe
HlZhOksKOkYLFlGylRuy6YVdAEaz+PWxrl+zFYb7SPD7KCuyUWH7VGCyJosJg7hkoZuw+ApnEctm
z+8MZxYHCPtInSuvHRJm7rq5WgZn1z98q8tkKrb98DqxI/auZeawy/D8ktTxjSDAdFv/9n8EhkBq
4I+9//wPAos4kqV5oql4KKr7wqlyLAHDBLm+873/A4M5xkNoPCKTyiWz6XxCo9Kd65CIYbPaLbfr
/YJdNkZYlGiV0yTEtYSInU8JBLocV8feWb25ruKLAOJxCboUqtxxJZosdi3GCR6eFNo05DQ44EA5
TD01aB4xWOrcpB3QDJYZEKAuHLwNxBQUKgwUtH0l0MymjryexGYFr7Se/A6LIPcKwxxn8cYYlECT
/FJ7nVbTKMcqSKso1zhE2FBEjD5RdDo9FCGN75Quz2td84bvFZgWL1974ae4R2+gCH+pAE57Y3BL
NhP4EOgDZyIAPHhS1K3L6MPiEDK+BhC4oqCArRYGDv+AnIMKwaldKAu0eGkA14IEBAZ8K7DKFyp9
NkvWvPltxE9pKEOuSIkTaNESM0/d3IVzgYGUrqoiOAkSwc03I0G+IsBqJlWrUFk5ZSq04EtXKX8i
1XcWVVWkZatqW1DgZZ2jCZbC1Ot2ajWrXwNrJcB1wJvEixUS08tXcNnAcHWl1HfYpF8SM7/aTTq1
6q1VBsj69bs34kgSe20V3Fn3yoECYmlkW5pT72ird8NRJBeBAoQh5GyQazCBeI7j7XYQN4dDOYUJ
DR5wCoA9AITq6LR3d0C9OMUJE9x1t679QQRNED4Nb29jOYTjHYmGPECAqrTTevef9hdbubn0lwII
MEb/AisKoMVYX6jEspdkCywo4QgLVsiCCCOxMIBLFLJgYUEsEXDgfvrpApN+rgRWgD62zaCPfwIG
OIt+M5xYIoLVwKQTiAxuU+BeQLK4QCw37libiSx6gwyBE244pIcTxjLAGaHZpAuA/Unj4n8x6vVi
ibUZGdmUEh7ZozRoKSklf296SeYINso1lJFXJvAXAggqMBIb+ZU45CxIHWAnThwaSYeSKyJ54jYG
IHpkfjBxxSReJQSnnXo5qPdAcecxcF4AGD2nAwVFRFCEqOx5yul1EzDgwAQ7sIcDqKkGMIEDDlBA
RHuyrgdBEcpxVxwExhYXgX1j+PLNNlcIaGEsitUy/8M2xBQqgmL4BaKPMg1FSAO0+y0AEbflvgiI
QK5YQa65c7IEIbpQ5tfTG9mY22e5R+6SFSqKgeuaV392Wya7er0hEpn8JkNvArwIyJPBDY048bVW
1lSNs3fWFOG9NJjLC77emlkyLwcu0AKYAmEc7RvvjkimviO03PC7Nm7Myyz+bUvzFeYGYyHA8ub2
M8kh//twwsBVtOyxue46a6akupMD1TbYUKs6wArrqg7PARscsRQFgGuu12FHTqsUWMKAOr1qt6w8
B9NcNzRHniTXtew2RM27QJcQsE1oITiA4RHNO689sBBT+OECBxyyHjbae7C5P5F08CzQUN4wvCP8
Tf+y5vfe5CXDZZJkOGN35xUMxQhbXKZ+17w+jMeWp4t77K5fSztIXrJs98uIIzzSgtUQwPrN8QqM
cJbcFBz05MzLvjfgIau+uh5Mk8NRAMo1sPVx8Fxtag7PPVCdsme3OhwF72e3HkXvvx+B9+7D347b
ZXNC//uj5sB7c2vINlR2uzL95SQH4122KMSHSs3rW/IymgHeNbNyuSt3n+OdBf3QuTJJTlvUExnI
9NEzhm1OD0PzXMXmAEHAja4WRqtew6BxBdZJjHfN02EszlCbVhDQSAaE3ciIWMLdmSxhf5ohy4bI
C5gVTwEJ2AlRYnSt5QVRZ28ggH9IEAwYQmOFNPz/4tE0eMPtTaRpPJjA08JGvvNVDYDrAV+mjqUr
/l2CVkWwyA0skgn75fE5qYIbRr4nRwF6JCgYnBCZfCSnm5SMXQZCECAwhqbASWNH2wIabQx1w37t
0EydhJy8zEUmAfXtYxGMCQpZ4pPTOcko0rDk3rIxCwiajm5pStkAZmAUJ9WyGOsqWomo0gqbLFJC
jVRlCItISyRmq1C4zF24ivRE4u2MBrXAD2dAGJFZILNSWiyLIKakQNe9UpcL/FAsTKmZXkazG7jI
lPe4Q4HssK1sRcin2awGx7CtTzlSY085QFGqfK7tBmwjqNuIUIQHTOA4uAIWruoTj0RSpSsdI8kN
/8ViFznlJjJH6VkgQFJMZfzFRUeyxbZegjHQmbQF11jFjg7mUpp8sJ2a8ShuKlfEVXDRSiipDR14
qs4RMIij+xJLC3RIU9twcT+wTBlUpZFUSOYwMiOgKQ8zahuarCJBKbUkM3P3U7FccoEpSx7GPCob
xfTQFmRN3IhSipatJg8pYlleRhP01JeFg6Un3ZBRA5abvDa1Y5Cq6lpto9MR0HNZ8/uaeWDFHfP0
U47PqSwEpGYO45iHPHA8nzkQGlrknPY54XNH+IbDCYFG9KJuqMOB0HDLOigwBbrQFk1qIokNAaK2
SKUDI35brt4C1w95QC4iaJKnNTC3BMI1g3HZcP9cGFgXdISIbrkOQdzkeuG5LphuufyQ3ZR99wUH
Qu6ehqvcQNThvA30Isomwd3hFjcQNJGEEFqlA0zsoAHfAUImgiCeIMQKFALewYERXOAhDJhZsgDE
Kt5LgloYwDYE2TCHO+zhD4M4xK4gad1EPBEgQDR+GllxJ+b2Ag354r4bOoWFTWzjG+M4xzouQ3tN
wA8bG1jFLB4yFG7QA1HEI8JENoKQEaxkIHxiyQaWsg+Q/L0m88DKQ9ayk5fMCS4nAcwQ3ggUFkyK
J1P5yGhWsxKw/AQkRxkJYjaCkXVQHO/VM81AKGQQ7ixZIQBSzzzgM5X9PL8/2zlTRM7zRhC9DnX/
lGoJkdajDwg9BNFWuTiTnrSgG01nTcfRCJbehHCwjGkdMFoIdfZnqjsdhVG7egmwHjKfOT1oRQ+5
1Qx2dEZsfQRf+3rUuoaHr2P9BF3rWdfC5jUQVt0d+0WUOQ3QNH14ANE7jqc56UuVeXAwSG5b1jmo
2ra3kcMcTUnn2dM2t3yE5Z0dvGfawzk1RE/1vc4eqzuiqPa02diDb/vTnpvqjrSXI596x1He50a4
Pc/xHvOUygFVe7as5n2+5cSRAcNRj8alw530cZw+yal22TqLavPYWz5lA0XH2w1yWd3ze8tRj9oS
PnNLfHs66kv4zmV+boykxxIYF/h3MM6eoT+H/+AZtzi6h1WfUz373sPx1GfXzR0BP70466YOet73
qVOpluQ53wE53K2r5XDC7DD/cnxwECrilN0S6Uv3Zxk+DokHMNRVVvA9eWUJtpGvf+hw26ty9QCN
7/Pw/sbVqUKVrH2ONuWQP1aoMsHPB4RvV2VHVtnUtiz7+Z3wpGAb+HjlbQjYSvHY6RUoTIV6xmuK
CLOqVagagKtUEZ6OAWQb4d0mHutkfhwMOFb4tP3fvueT96TfVNzAU6znr4+gwtI4OW61zwfPD/PW
6drYcvC0p60vArAi6B0JCuk4lp8ckoea29BveVUdHvYQlb2mXkV/ykocVsBqh3JiJTXvo56u+P9e
6ZFe41mH361W7VkE6CkfJlSfePQK7VkHRKGN4SHeqIwbdHRe2YyfcAhHBz7f98VfqTWUPmVe7h3g
OWBEZv3AqgHQAmreqFjCd/iX9p2P+jUHJzzHCuog5MnP1bwNDhzYDMIe+cygOgDS/cQgHp0PeQgL
DMpcE6ZaPr1RoHGczI3DsDjfx6GaREmcE0IesamK5bWe+OSgf3XNDY6BDJYDHpEPDrDH2LwRg0nN
E87K05hK2yBhD2ZK25if/PxX1uDgHNVh1YyNsMghDlqhAzIh84mhP/GfZX0H3IgHGqZNwIHecfAg
DHLiOUhNgU2Hrojh2PwhIPoTIIFNqcmPEbb/IdwQFCBNh/yBITwIINyoWhkqWiZqSqCNVgCNzyCi
og8Go2b54A7KkZ1Vh6iYYSHtIa7xDxSSFv1cohv+4hT6IgDhzz11nHn8Hq7M3ftUDQyWijE+oqcQ
lAaKo/9UjcaByqj4DzUekv34zyB2YeTpntW84zASW/3g4KbxIzFaRKQF5OrRjyL6TwxmY/w8IgAl
HXFMIqWth0VsoibmYCdWpP3IzcaJYs350SBOWjOmIh6FpP+8zTUCUnooo3aoI7EJC7ORAi5a5Cew
yte4A3Z8IjDyIQ/+YOTxJEZU4sGFofq5XTMqITQCoiVAoRth5A/4pCJmhyXgof0gZQQIC2vt/9oZ
guEL1tz3EEeomSH/lMp33EC/HSPOccIc3t1xGBmhWUTX2NGt5ZE+euJUMqQhqscctsNA1mNEqiUO
NKMhwUOgfcdCnt/3EIEtHtJ1zCJFPiNj6mJjXqQfDR956GJe3iQxaqBciuQe0ePfmaTEAWVd5hE8
hE8a3iI6euE49B8XXsKsAMvlydEw6uQO4lwxQh4gpUqrhEpQ6lPzJeHnLSEvyoq3TWOgXZ5FxJnV
FEHXQJom2t5r3ZMAqma4haMX9l/taSUgLkfrZSf/rGY/dc3+TNSs/GZvWhRCFQdb8t5dnpsOjOdm
BgdA9WM4Ss36AKHQxVE+KaPcpWfzKaDnzf8HOhDmepzjHeWgCcLKf2LiEm7irPieRbIe2wBS8G0l
bJbPKfJhYGaocOwReS5nqelmSg6nPi0gJZ6mDnBjapZdRDHfZcXctVnWbAojH3ZWRNkmAMFWOYjf
06QoVw6HWTrjY/LiZZlHLmYHjMaKF0IHi/rlfOzoodkoRInfclbWVeJRjaJerujKVjbfGm3pgdbo
//moqLRWzJUnbKlNtHkmHYaWJuRTgJUWJ2gmZ81KYaJoaNXpaMFoHO3pLiafk/pbaYbKkx5fVUKi
4mFWgFUpkaKeRF7kgmqp+AVnDF7bnZmDjbqNoSIpZpqPZmpmmb5WZZWacuzop8BKmCraOc7/WkfE
A/b1wK5sBDoAmCes2SXET4KRAvbhahTMKpQ1WYNZTazE6n+pGCYomJvxQK/uKrzp3bKeWZPFymCi
GZcZaxCYWRQOqxAAK4Gt2bUG2HdUKw8A66xuq60aWIT16pVtAnf6wLWm67siqxRE65kdma4WWLp6
n961ILsaW792mlf6KxB0Fr8GLJOxYMEibMIqbJoNrJwR7MJCbK9FrHbU6sR+j75abMZq7MbSSsW+
JMeCbMiK7MiSbMmaLBO44Mmq7MqybMu67MvK68PC7MzSbM3a7M0qbMri7M7ybM/67M+irMwC7dAS
bdEarcrq7NEq7dIybdMWbNI6bdRK7dRS/+2bCW3VYm3Wam3U6qwE7IDXAgHYBoHXiq0EmO3X8oDZ
qq3YCkHZrq0OgO3anm0AsK0P1C3coi3czm0OxO3b8u3Xym3Y7q3bsu3dBu7fhm3b9oDh6q3a4i3d
+i3d8u3bxm3aPq7kjm3aRu7dQm7hNm7eJm7nDq4TRK7dYi7g+i3hgu7lli3qHu7klm4SOC7r7u3p
/gDnrqHlPu7rGu7ski3inq7n6m7jUu7wIi7n4u7k3i7otu7xsu7lQu/z2u7iZi7wzq71bu7iym3t
Tm/vXm/wAq/10m7g1m3zTm/wpq70gq/zii/1Gu/Ytm7ysu/yDq/50u/5Iu/2yu/+ou7qXv+U+4Zv
++Zt5VauAOPv/XYv7Bbw+w4w9ZrvAwtw4b5u/f6t/gaw5vqu+kIwA5evAgOw8IouBg9u7YJwBH/w
7hLvBmOuCvsv+m4v+/6u6a6w6GawCE+w/kpw7Oou4aavBa/vD2cZd8Zw5zKv+xKwCbsu966u5wrv
C58v5AIu2qpw8z6wElfvDFdw/wIwFv8wD3vvDdtuB0MvFVPwBZdwF39w+iLx+rJwCn8vF2PxEFsu
BOdwEYev/C7BAmfx58qwC1tx7rYv45qxB6tu9MquHQNxGDMBGSPxBuOwFV/vAtuv/0qyBhuy4hpw
345uAYtxIityEl/y9xYy9kayAk/yII//8e46Lu6Wbymjchc/Mg1PcANbMuwi8imzagDL8SfT8i5P
wRDrMRzzMhJ0cB2rsitHQSWbsSBPsfoegRj3rRHjbTDz7hxf8hZfcR+38TNvMQhzMv6+sDKDMzLf
cRPgcCOPLxrvXR638Dd7cSTHsjVf8O2esw3PcgszMPP6cBKf7Sg/sQw3synbsw4XLDALLh6Trgbv
Mz9zb+m6MzHz8TwbQT3L8h8bsiivsRfvqz2/LzPvMQJD9PyaMh6TNDdnMzbnczmH7kpntDOj9Ehz
dExrb+wyMumCcRl7Mj7rtC47L0JL9DwLMku/9E5rcy3/swsyc1AT70dT9D9T8jAbcEgT/7VTU3VT
Gy8uw+9M6zM5v3RQK7VSv3Ix260Tc7AbjzAyW/VQL/M093Fbwy9ZV/Q7W/QykzVGR/RRtx5Yp7QU
X3NfY3JYL7Ja/3RVK4E3F/ZgIzb/ovQpn/EB7/VP+/JFS/YV+/Qjk208y/Nj+7RjD3Zlx7NeTzXu
MkAL8PNf/3VTp7Vbw3Vqt/NCU/RrLzRlx7by6u1JCzYrzzJcw/RYEzQHnzVvi/Js169wa0T+1rVw
o/Y+s/Zb33NotyBpb210S/d0G+1o1wB1Y3d2azfMWvd2e/d3gzfHdnd4k3d5m3esjfd5q/d6s/cU
jLcTa/Lo3rJAQzZV+/Vmi/BEV+9X2/92URuBAAC4AOgAgA94gBd4EBB4AAS4gSu4gB9Bgjd4gUM4
hPsAhR84ECx4hu9Ahlu4Eiz4hROxX/P2Ejc3Udv1Y9+3UI9zidc356Y3LUtxQ7u05AY3W/fvKtM3
Z4v4Uusyjuu4P39xP+94gnN4DhC5gx+5kSP5kit5kz+4g0d4lCd5g394lEs4g/dAh284lDt5lnO4
loO4Nsd2QO+0RW+zjBtx9tKzbv/4VcdvlUE3DJ8wQ89tNct5JzP2ZG/14TbxVb8yF+c5TmM4k0v5
klf5lCM6of83lCd6lW95l2M5lXu5EHw5pQv4hFc6gfuwYhu1LIcuK7u0HiMvUKu4Xp//MSNH9osb
NA1HryNjMArTOE579UzntkqL9CeLtQdHNWdb9ZEfOqEnupMH+6L7OoNP+aNbuYd/OZczAYFbuKM7
umbLeh5L8JyjbxQ/cTBD9myjdhkf8ZHFefe+8bhL76gfr4/Xsp238xKncgLzeCCvsZ4jAbQzOpYX
e6MbO7P/wK9feZgLu6Ev+xIse6TzgLNz+bCHeGdr9TET90STsEnvsFuD9GGH8LkLObhftwVru7i7
MnzD+i5XMSQ/vJ+PMVf3OU+Lc5BHtsDrO7Ij/BMkOZh3OaS3vMwPvMwjeMAXupOHPCL395DFdzgD
9Ij/vGV/NBsfPSmEe5qrcSc89Hxn/zut0/QbqzaMn3ZfUzFmTwHCD7ylbznOV3i9X7mGN7vO57yX
Y3q873rbjrnWJ/PQD7XRT7wco/oTv/htL3Zpf7y7I70WT/xU8zSsu3GnC/q8F7m/DzvOg/2+iz2y
z7zitzyVR3vYLzo77/rGr72J67etC74tc/w64Hm5J30uK7zD13U3v/mNX7zHqzglC73eNzaQD7R8
e73jd73kH/vtJ7u/F7zOEzymV/qk277ZDzraH37C6/j95jCL2zcQ1zPrQ79gOzM0Y3us80DK5PXP
l/WfZ7b2c7zGu73mQzVhb37z737aOz7lz7zw9/7Zpz/7L/76oz+x+z6z43zQ3/Pvrv/6IWcuCEiB
KAajiZ7pWq5o2b7uHM9unZLuojC5BAy2hMIbEfgr2mRLpg3XjD6lqhcxCr1ZjzOB9ytIgcdNL2oM
Npm76HWg7Waf4ba2mE51wcPLbN8Jc+RXRQNoIjiY2CdoxPXXhMPjk0dZaXmJmam5ydnp+QkaKjpK
Wmp6KiWJusra6voKGys7S1tLqmqbq7vL2+v7CxwcgCtcbHyMnKy8fNvD/AwdLT1NDUssFZQzckW4
nX2YOeQ4pEU5uKXdXYW4sqeG9sZnmpYXd2f/jh9v1x6mL/evnrx3ZQYKzBSHXz55awLe+0JwIUQ2
bszAizenosF9F+vwucbuD5SRLMD/lTz0TV0NcY7QKVFXbh3KloXu9ItoMyM9jmQeWpyYZg/DhhDJ
7Izy0+jGORwxSjyqBw9TnDp7OqWicapWOVcPOrWHjyhVnku3LiGK55pJlkp0xEzXtlwMGHJT4ljp
JO8UkyrubuFmVuzNsQH1afyJMyvGpAMZF6QatOziogYRI62M2ezXjQ4HXwXrz45gShdBR306mHFk
rJkjqu1bci4jlYQCjYMbO503wHzvzja09vc5skA5U04tNWdT5YoRH3V8NnQ/ywCP2+xM3PTYzVEV
ek7Y0ePTiVw/h5862vzjy6ddOzs5FzjfbuTWysUtf7hu/TSQ6O0fEmsPBcYHduNp/6feZFYRt153
UPm04GSV/KNYTgY2aBpoFU7YmGTRVaiaTgS6o9UaPCiwwF9x9aZbbfDN15tdetFlzm/GiNahVRce
ViB59MAD3WZhCUUQdaetdqBkQg2FVo7nCdTkktwtx1prnCSFXEQXTtcjCgygWFMS2iDC30y8vbUX
mVmsRCYLjKhp5kvZkdeeFCQOSKWWxRUZWnN0kiZdYX1KV+eVe0bHpXcLbSced1LaOaiihuqJyY/y
fJkimpeMdCaMe0ES5iOe+IUNopBeImiTN4nF6qCJ/VmVn12tap1nBSnUaoOodgmejl3OasmWDvZE
omBD4srrpWBqGpJ+pLa4WzZ4Uf8x3LOQ2OhpgIUyumujjqkqYj6L9rpUhkNNGSuhtgLLFbm6cqsc
lQjulF6V65qqWYk+GpdluAFgGic3pDqrBZyfenqwigJTy/BJXsWb6JJPcrloow5SVK6VTNVLa5JG
4luex792S5iHHD8G3sPwOjTkvcoBTO1s2iqsCZs0/RfzzdGm9N/MEM/JypYsK1mWpNd5+HPI77p8
mdGFOo1echlNDfSwD+ar2Z3lwVxN115/DXbY0XAtdtlmn4122qSQrXbbbr8Nd9psx0133XbfLczc
eO/Nd99+r71stAjjDG3CMOU2U+GFv6mwf40j7NuKKs7Y6X4z7uf44SesCRPPirj/ia3DNeqs+Hyc
s1R6zz6nrjl8L30uKi1cDxwmYM6GHheNMiVOuIvZJuybpprzZq3D9eWl+/HbyGAbXc/WZzuoB7Ml
p/Cmx05C7tLzPnj38Qn+O4vGQz55964wMEn4JJFfquj2bS4+bPG/Ja31zb+ouB/KF5+E49+4Jb/d
yQ+A9nkeOuRTsOltr2Dr856Y4pO9hcVPf4f7nuXGFxy78AyBvTtf+sCnuwu67wm4K+AET1iI462O
gOIAh/8kSD/QbRCDLoJefkyIGwP+bobzQ94CrfAD0Z0OgQSMCfU+1UDahG9362tgEmeBvhh2Dmdl
cuBu1pG55KkOiE8UYRd9WJfM/1kieuLTYhnr17/OZTFOWwxii2A3xvwxgRxFQN0Ns8UmIRqxEf6D
0f9qFyoopo9xU4ScGH+InyIisYMAstG0mnczC6LEep3Aix3L6ELLVbGQcVReD3f2OgFS0Ydm9IYA
N5lJPy4OEM1inxpRGYooNoyGrAtY9WgEwFZ+EpSwpKQMK3et1dkSjnuEjQUVyUs/ilFNdOwZI6fg
yVI185Ss3CAzmXc5Z+5SeNFsXStkqT7QUa6XNXGe9FSYhy8ukHQj3FnsKkFMDJrzevwJYQedGM5G
hvJ9v/zjNNGJQsMxEVo6FCU/uWezXIAzme7E4ori2chUMtSUVCwhIlf5TCWiie1TLYGoG+FHn1cK
jAvxtKQv04Q4ac7RoW9c4ztDGghm7ZOhtwnYQWGxUP7V0p7tVKn5AvnTzVHwpZIkKvCAyroqIhOk
PX1pLefYpvYJFKlMpeo903lRQDbVmzz1YP+qt1VvDhOrY3VqgLLIUeKdaYXA9B0fXyec0G01rWBN
Klk54VFf5tV89cyqEeXKSHKCYqF/K6xhD4vYJRA2sYxtrGPrttjHSnaylPVaZCuL2cxqNm8f3Kxn
PwtaQYZ2tKQtbSnQh9rUqna1rG2ta18L29jKdra0ra1tb4vb3Op2t7ztrW9/C9zgCne4xP1tCAAA
Ow==
--001a11346d5c4512a404feaff9c8--


From nobody Mon Jul 21 06:16:32 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECBA1B2BDB for ; Mon, 21 Jul 2014 06:16:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNXgWsYCnSPv for ; Mon, 21 Jul 2014 06:16:30 -0700 (PDT)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCA011B2BE2 for ; Mon, 21 Jul 2014 06:15:20 -0700 (PDT)
Received: by mail-ig0-f169.google.com with SMTP id r2so3039026igi.4 for ; Mon, 21 Jul 2014 06:15:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=YY38NE7K7x1hodNExxsAB87P1lCU1cVGWl6Hqpj9cA4=; b=tSRQ627FQFTfkH7ptTYAyl2i/NcU/nxO0pDz66Zybj2sST1p+YnBTI5oVT4fKSX08N nlJp3/1V+QGemSmDZwVFBv/tEtme9XpIQdP5RD7DvDO+PIFdRY2dpch1SruuaqtTvP8e SHwiStxrB9OZnXemmJP2zDq6IQpncwTaxD61ABBcfH49fo9tl3LYgabH1eYpvZr4YglI ohZOdWctYClGSm9kxPPox+icQmOfIokeXMRq0Lnjbq+Vg0q1QfdyLnXTcHs9hAUsC20Q RlsgNnSz9aJwhajTZ3BfHXfsmyghRh3HHi6rTPYkJdofaozZLWJxuDCUXtXyZu/HSNU8 Ks/w==
MIME-Version: 1.0
X-Received: by 10.50.56.38 with SMTP id x6mr5123351igp.30.1405948520117; Mon, 21 Jul 2014 06:15:20 -0700 (PDT)
Received: by 10.43.154.80 with HTTP; Mon, 21 Jul 2014 06:15:20 -0700 (PDT)
Date: Mon, 21 Jul 2014 09:15:20 -0400
Message-ID: 
From: Ted Hardie 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0158b05e1d3b2904feb3e641
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DJQrURW890DxWVC9MsOMT1453zU
Subject: [rtcweb] Reviews of draft-ietf-avtext-rtp-grouping-taxonomy
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 21 Jul 2014 13:16:31 -0000

--089e0158b05e1d3b2904feb3e641
Content-Type: text/plain; charset=UTF-8

At today's MMUSIC meeting, folks asked for review of the rtp grouping
taxonomy draft.  It would also be valuable for our group to review that
draft to ensure that we're using common vocabulary.  If you had not had a
look at the draft in a while, please do so and provide feedback to AVTEXT.

Ted

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


At today's MMUSIC meeting, folks asked for revi=
ew of the rtp grouping taxonomy draft.=C2=A0 It would also be valuable for =
our group to review that draft to ensure that we're using common vocabu=
lary.=C2=A0 If you had not had a look at the draft in a while, please do so=
 and provide feedback to AVTEXT.


Ted


--089e0158b05e1d3b2904feb3e641--


From nobody Mon Jul 21 06:25:37 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB551B2DD9 for ; Mon, 21 Jul 2014 06:25:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVz8csTKwrzw for ; Mon, 21 Jul 2014 06:25:26 -0700 (PDT)
Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AF781B2DE5 for ; Mon, 21 Jul 2014 06:24:24 -0700 (PDT)
Received: by mail-wg0-f46.google.com with SMTP id m15so6485150wgh.5 for ; Mon, 21 Jul 2014 06:24:23 -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:content-type; bh=GauDp2i0MvSc8Yq0PsF9alimacAg7oF+hKsAgnBwyJE=; b=XxMHxTDNkAiUda0xDDuDhgFSTOMgy2rTKiZCIGQyok+dAC+EZeAe7y8ulzz0ewG6DR GDArC7LMZOzIV5Da0YW9LHLZ18j68ilOEwvvimQ+kF5kEqi6Cz7DNbCbOv8Bsb9OybDt K3qLdFDiQ8Qh64QrUi/B9lPxlN21C87HOotC3u+sZ1DlGvIcBfUusnXpgEG8ERuEfcgh yn63VI0HQDkCDTqBCsA06PYAKsT6nl/qCWspcA1Wz1z53l6tq+83ssLh19XUT2YaSFtu e3JtNuFU8EH9BLiJrhfIgK2RhHkoVjX7JrmSMWHKkZM3816nXCogQiyaEL4MwRvfFYOL kDnA==
X-Received: by 10.194.92.115 with SMTP id cl19mr23363793wjb.29.1405949063297;  Mon, 21 Jul 2014 06:24:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.217.122.65 with HTTP; Mon, 21 Jul 2014 06:24:03 -0700 (PDT)
In-Reply-To: 
References: <74.10.26169.C4457B35@epcpsbgx4.samsung.com>  
From: Bernard Aboba 
Date: Mon, 21 Jul 2014 09:24:03 -0400
Message-ID: 
To: Justin Uberti 
Content-Type: multipart/related; boundary=047d7bfcf88e7dac8404feb406ac
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sUSHDRGW8OHLZOXa7M5GMpvt76A
Cc: Kiran Kumar Guduru , franklin blek , "rtcweb@ietf.org" , "public-webrtc@w3.org" 
Subject: Re: [rtcweb] New Version Notification for draft-guduru-rtcweb-codec-preferences-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 21 Jul 2014 13:25:29 -0000

--047d7bfcf88e7dac8404feb406ac
Content-Type: multipart/alternative; boundary=047d7bfcf88e7dac8204feb406ab

--047d7bfcf88e7dac8204feb406ab
Content-Type: text/plain; charset=UTF-8

I agree with Justin that this draft is not a useful addition. Codecs are
only one aspect of capability discovery, and so cannot be treated in
isolation.  So I would argue that the approach is problematic as well.


On Sun, Jul 20, 2014 at 11:30 PM, Justin Uberti  wrote:

> This seems like a pretty big hammer to solve a fairly small problem. This
> proposal adds 6 new API points for the purpose of changing the order of
> codecs in createOffer, which seems like a high cost-benefit ratio. And
> while the use cases listed here are helpful, they seem somewhat contrived
> to me, since it seems unlikely that the application can make better choices
> about bandwidth or power consumption than the browser.
>
> Without a specific, concrete example, I remain unconvinced that this is
> worth doing in the 1.0 timeframe. Post-1.0, we can probably find a way to
> provide this sort of lower-level control.
>
>
> On Sat, Jul 12, 2014 at 9:41 PM, franklin blek 
> wrote:
>
>> Hi,
>> The draft seems to explain codec preferences in a good way.
>> I think this has a good potenitial to be a part of WebRTC1.0.
>>
>>
>>
>> On Sat, Jul 5, 2014 at 10:26 AM, Kiran Kumar Guduru <
>> kiran.guduru@samsung.com> wrote:
>>
>>>  Hi,
>>>
>>> A new version of codec preferences draft has been published, by
>>> modifying as per the review comments received.
>>>
>>> Please review and let me know your comments.
>>>
>>>
>>>
>>> Thanks & Regards,
>>>
>>> Kiran.
>>>
>>>
>>>
>>> ------- *Original Message* -------
>>>
>>> *Sender* : internet-drafts@ietf.org
>>>
>>> *Date* : Jul 02, 2014 18:28 (GMT+09:00)
>>>
>>> *Title* : New Version Notification for
>>> draft-guduru-rtcweb-codec-preferences-01.txt
>>>
>>>
>>>
>>> A new version of I-D, draft-guduru-rtcweb-codec-preferences-01.txt
>>> has been successfully submitted by Kiran Kumar Guduru and posted to the
>>> IETF repository.
>>>
>>> Name: draft-guduru-rtcweb-codec-preferences
>>> Revision: 01
>>> Title: WebRTC Codec Preferences
>>> Document date: 2014-07-02
>>> Group: Individual Submission
>>> Pages: 7
>>> URL:
>>> http://www.ietf.org/internet-drafts/draft-guduru-rtcweb-codec-preferences-01.txt
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-guduru-rtcweb-codec-preferences/
>>> Htmlized:
>>> http://tools.ietf.org/html/draft-guduru-rtcweb-codec-preferences-01
>>> Diff:
>>> http://www.ietf.org/rfcdiff?url2=draft-guduru-rtcweb-codec-preferences-01
>>>
>>> Abstract:
>>>    WebRTC specifies to implement a minimum set of required codecs to
>>>    ensure guaranteed interoperability between WebRTC peers.  WebRTC
>>>    allows browser implementers to support vendor specific codecs apart
>>>    from mandatory codecs.  This document specifies the way for
>>>    JavaScript applications to give preferences for media codecs in
>>>    WebRTC context out of the available codecs in browser for creating
>>>    the offer / answer.
>>>
>>>
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> The IETF Secretariat
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

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


I agree with Justin that this draft is not a useful additi=
on. Codecs are only one aspect of capability discovery, and so cannot be tr=
eated in isolation. =C2=A0So I would argue that the approach is problematic=
 as well. =C2=A0





On Sun, Jul 2=
0, 2014 at 11:30 PM, Justin Uberti <juberti@google.com> wro=
te:



This seems like a pretty bi=
g hammer to solve a fairly small problem. This proposal adds 6 new API poin=
ts for the purpose of changing the order of codecs in createOffer, which se=
ems like a high cost-benefit ratio. And while the use cases listed here are=
 helpful, they seem somewhat contrived to me, since it seems unlikely that =
the application can make better choices about bandwidth or power consumptio=
n than the browser.





Without a specific, concrete example, I remain unconvinced t=
hat this is worth doing in the 1.0 timeframe. Post-1.0, we can probably fin=
d a way to provide this sort of lower-level control.







On Sat, Jul 12, 2014 at 9:41 PM, frankli=
n blek <franklin.blek@gmail.com> wrote:





Hi,


The draft seems to explain codec preferences in a good way.


I think this has a good potenitial to=C2=A0be a part of=C2=A0WebRTC1.0=
.




=C2=A0


On Sat, Jul 5, 2014 at 10:26 AM, Kiran Kumar Gud=
uru <kiran.guduru@samsung.com> wrote:






Hi,


A new version of codec preferences draft has been published, by modifyin=
g as per the review comments received.


Please review and let me know your comments.


=C2=A0


Thanks & Regards,


Kiran.


=C2=A0


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


Sender : internet-drafts@ietf.org<internet-drafts@ietf.org>


Date : Jul 02, 2014 18:28 (GMT+09:00)


Title : New Version Notification for draft-guduru-rtcweb-codec-pr=
eferences-01.txt


=C2=A0

A new version of I-D, draft-guduru-rtcweb-codec-preference=
s-01.txt
has been successfully submitted by Kiran Kumar Guduru and poste=
d to the
IETF repository.

Name: draft-guduru-rtcweb-codec-prefere=
nces





Revision: 01
Title: WebRTC Codec Preferences
Document date: 2014-07-0=
2
Group: Individual Submission
Pages: 7
URL:=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http://www.ietf.org/internet-drafts/draft-guduru-rtcweb-codec-p=
references-01.txt





Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc/draft-guduru-rtcweb-codec-preferen=
ces/
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/draft-guduru-rtcweb-codec-preferences-01





Diff:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://www.ietf.org/rfcdiff?url2=3Ddraft-guduru-rtc=
web-codec-preferences-01

Abstract:
=C2=A0=C2=A0 WebRTC specif=
ies to implement a minimum set of required codecs to





=C2=A0=C2=A0 ensure guaranteed interoperability between WebRTC peers.=C2=A0=
=C2=A0WebRTC
=C2=A0=C2=A0 allows browser implementers to support vendor =
specific codecs apart
=C2=A0=C2=A0 from mandatory codecs.=C2=A0=C2=A0Thi=
s document specifies the way for
=C2=A0=C2=A0 JavaScript applications to=
 give preferences for media codecs in





=C2=A0=C2=A0 WebRTC context out of the available codecs in browser for crea=
ting
=C2=A0=C2=A0 the offer / answer.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0


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





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

The IETF Secretar=
iat



=C2=A0


=C2=A0




















_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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





--047d7bfcf88e7dac8204feb406ab--
--047d7bfcf88e7dac8404feb406ac
Content-Type: image/gif; name="201407050656727_QKNMBDIF.gif"
Content-Disposition: inline; filename="201407050656727_QKNMBDIF.gif"
Content-Transfer-Encoding: base64
Content-ID: 
X-Attachment-Id: c52c5aec3d8c59b0_0.1

R0lGODlhCAKQAMQAAAAAAP///8k6OspMTNRiYtt0dOSOjumiovLExPfZ2fvt7f/+/uvr69TU1Lm5
uYyMjG9vb0dHRzMzMyoqKgICAv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEA
ABUALAAAAAAIApAAAAX/ICOOZGmeaKqubOu+cCzPdG3feK7vfO//uYBwSCwaj8ikcslsOp/QqHRK
rVqv2Kx2y+16v1YReEwum8/otHrNbhcX8Lh8Tq/b73al2M3v+/+AgYKDVniGh4h1egyEjY6PkJGS
k0OJlpd5SXsBDQ6engwNjFKilHoNSaVYqkisTK5CoUqdo02waLJMubGogg6Nt1S/a3IIeAoJmHAJ
CnTIipq1EBETFBERDRHDUdqmSQ8PSd1GENzbR+NN6UPgqRPYr+Hrae1MDhFE94MUfA3hRvOKlHPC
z8xAIXIG4EFQAJGBOQWMzWEIDckmIfqEBFR3zhuWgk82DhGJrmOAekcy/zJpR5IMSiUqA8T8A5LN
yyc1l+QEU9MSxUMKD/2cs6iIyggQKExAxSCCtVoBmlKgIC/pBEZSIzBw8I/ryWr/hDSYRjUpvq9U
ozpdGiBp2rZTyzUAO9BqLyHt3IZt22Cs03Jm0YbzS2HgA2sTfj0AixfxNqlsszLqtjgtuAfDMA+p
BlgpqgdJh82d8ACpZ7VPiUA4HNlp2tVKHVT7NbewWKUR9kpNy4Azvt6F8SGdIBg1W71C7CY/rTru
ycr/kiYlAm620+hxm4o9K5ax5Las+04gvTschL5kD8LFBmFCZ9twp8NlO6S21uJfE7dNygD6+kpx
NGTAAQMQkIwCBAxggP+AySTw0AEJPmTAAAU4SIABBiQDIYUKDCVHUflwd81JgJWomlz8UMMABCay
OFdyDzBAgXh3OTBjA1T1JsqNS5VG4lxbEVeaCEut1hQ+i/VHHDsPACkbEdrYuGNfFDggI41SXnml
jVbyiGWV7CDZYjnaXDmXP+CcNWOY/ly12En3xeLiiKDtZ+dISOLDIicpCucmPuTlFkBiMu61J47g
HZnoiFWK4KWPoDkppJuTKkmdVjomieiQ8uHl5o38DKkjW3Vu5gCOK5pIp1YuHpqiJzNeWV+VNjIi
ao+shkoplPLE6OWVbyLlKI04bpPQAgU0dICAByiQLLLGUDSAMQMkkMD/tAgMoICzCChQLbIHeBgH
iEMc9Ys+a8pIhBg2BiCoumsiqh8F/dUVVkYFaVPqaj6KIBsjvQCcGL0yCTcMfc8ByQmUnpzVTaj2
ZqTvQIntCw7F2/TLSLyvWgyOjEGG6O7BaBbB0rn4pFtTN/qw++pzBb8Y85KrrctIuwT7mHPKeNmr
8b8Lj7OU0HdFxUnF/7yMKJMFC1GQwA7sqV93GMmKKMtIhuPyyBKfw49KUHdzNckjDUYijKXKo5i9
AfQUh0IRLSBtM8tCK3dD3yazgEI/xd3ggOLCQS5GIqLc9lRTEWHfy2037jR4Lx6G+L1qasQV4jlS
E2N8TK01MOHuYp6x/3mFFR2lw7+EijlmqNej7+quP6b5xkN0DHuvNZdrsOU3ndw05isbvvjIMN9j
I+LanPXS8AWhC3pBkk8V4+ych474PaIPARnSj49TUzv4GpcYkDXFBNLL+rQz/OmWE/H1Wdsb3332
3QkaPVUvUba64wi9bbe0cKBI3CgCobjt7W5wiNuECECAcDWEDoNrWvucJxYiTO1l8MLK19xTjnoU
LXwj82BUQtGeqPiDXnsaGcH0MY6iqa8/BLNc1xonwq7FToSx0x4JiUMwdenrH58JB2jWpDviDYor
e4EZ1vhnOsNdkHjgS14stqK8vTyxeTz7HV6AOMKxECcUh2mKaIxYtP8U/rB7w/heOMJnxl9wUGQy
AVlU0Je1QSWNa6hznwTb6D0yKq5g/KpgPdQGs4XxLwDHGiDeAtgQRS6AGcs6wAH7hoBl0c2BFTnC
RSRIPBaucUlOs1WKOigcIZ5lPKgAmqBA57goXcVdoNEaVU4pv2KxSFH9QthlaDmShrVvg5NhneVe
VCxVYoY4xRpCzXxoSq69MjftkBEoQeejTSXRd56UyTSXmLOXRbFtnynHmkjjPlHCsi2lRKfjjLnM
WQqhYr/BVVQQJrYq1QNiJ1GjBJUGptAUgV4gs9/u0heObuKxfbWTYD250sFQxfMuhLqHwnLzoiex
7JkFxQgi/efIAkj/ckHgWsCyEkCAZgxokg+MyAEegiBMQjAaRilc03DklHO0xz30okY1UEFTIjpF
meOZJgi7cVNkIiZGQcWHjaiRG+BMY57UUM/HksqwGY5nRUFV6C+KutWstiWo26ApOXuKCqJm1XVJ
bNl4wNS7WQrPGmDqZdNuyh/KrBFJ71jTYsZjqPHwR6z4GM07+FdUPs2Oqr2JKlTdkw/EQPOOvckr
de76uKW+Y4072SuKnFJWwx0GNH7NqS+N+M7EnMWyTR3PTxPLWHYc9avjSc5sjFjYQV2FH4mMVkNI
ysCGZCtZAiJAAQy0AAZS0lvDxVDgFhDBJpzKCH0xSi22ApUidAIK/9eNxXMxcpfsnsRW3NluSoqm
BytxwiT5gIp342iErdyFutA1CcLGOwvylsu+0MVvfGsR3fyuq2i7sO5jxCtemXzQvutNCXbPUSrr
vte8reCpfjUJYbF05ML2ha+F84Ff71I3HIh4RhysVQyJLKBDzZgDig3RXI9MYTGHQa+Ln+CXGdsY
DIuR8Y2x0B+PiEAZQA6ykO/AJB0bYchITrIcFNAsJTs5yDvOgieiTGUt/BgTzLhElp9siS0X48R6
C7KXtZxiMSNgzGM2hIjn4OU1TyTMSXYzi1NRXezWeRBGhgkYaHNn66q3zyaUQp4DrQmeArrQTbgy
HB5yCAMmwtFcbv+0if13AEkKudJAxnSQfwtpSN/hIct19HIN0EAlg/qBiDiCP0grhZtoQTNLWJFO
qLATLYQqiSVhWBJm0oRaxxQmu3tCOXitSQYcS9KX8HSkM23pIGsaE89WRrQDNOk7BMUOyqZDtoF8
bUscwXeEaAkrk+BrJpT7CucuwjpIQmwstHvcUHhfoo29aAqJtECWJhBxC7DAZAyoQAcqAIfs1u9H
ChxDzoJDwkccoQSSesQLGoAkLYShBBQgxRlS1sQbfm9+N4jj1xJusx+ZoH0T6OKPLJBHi8FASTpr
4P82EG9XqiEKEcAYG5p4xCVEIQedWOASt9syJKTvBBT95SjHULX/Ir5Se9+bQxOqEEsFnvSij0sy
siGNaVqTGhY9JRtb7Q/pyDkfF1ZmbVWqTUOXovbupOUvZV9OpwqZNb7KvSDKGWJYq8GW3FhDI4ep
HPjsXh53WWUyilHKXlrmGsw00ysjeY7d10NFvnCiHE7VE3rgHrqnKtMasuE8a3RD75SfWebaIqnR
CYAsZT3kWXXD0AJkr9KLQ2j2BnBWQ4i7Ujk0sKV761YcstUsbWVrWxE5KUkPiOnfe9RbHZpWcZu1
8ptfa+SlrlvQq3/moMfh5seXPe2VdfGKR0T12Tp9t4xfLW9ZC1sCesjyRd1I8jurWeJ/fe6z9f5m
ydzk14IAFJF//60nUqhmJ7c0J2KCgGQCAWJkI76SMFfxJEPyJK7VCUJyH+QRKEg1PeEwPvSyGP6g
FRSYK5P1OEnSLpziUCHzJhbUTIXRFAXlgIJya0dUK4dCHCqyJ9pwJqhSRK7CQvyQOyg4gSyIFCxk
ODxoMFkyIyuoOLQSK/TigzE0QsfSe7NXaYwmSR2lW3vTIHDDEJZmINqCQLJ3cwzHSAfEcovmUrUn
Ug+hEJWGAKx3N1gIfnXIEMuXhUt2YtoHB5W2hye1DHnofin3PxoHLXdYSYwGOClFLQi0LXIThsPX
SF4YN3lDiT8RFH7zc5LEN3gDhog4LhyjRIajMlCUJlIEDkBTVv//oEsUUzIWmISziA2vZCXZNChg
xycnSEN3VE/npIs3gRU6k0opY4y+KDNWsjWr1DFsAzpbww/WsIsJdU/EsxVJ+DvgdVAj0w3qokc2
9IxWSGkDUI4SF21diEDXFoYGFBFBQRGq120/AUDF8EBz+IjFZTdyGC7mSCGaFhHZYo4RYY8jp2/P
EhT3CIjN5iHrOIqYplKWplL96IaQCI8JInBCh0Dp2JCOtIYKVCClBopreEAdyVznY4q/gzmdhBQw
JkSkcx7WMxWjwzuU1TRRgjlSVESuIZN9xDS+iEbzcz1t9Q5ZREHOw4rccTRwZUS2MzlFNDyJ4R7t
okfWmA7ZaJT/TIg6PZlQNrQ/U3SFlqYh+TaKjlSG3gItBnRzZfgTF8JoAZSHi1SPCklJ01eG+/gT
27KIeNkhBMlwyUCPCSlSC/lA69cMZ+lID1lJEamYy4BA+ohAaEiSJiZAl0gthqmJD8SJlYRymCaS
ZomZpKhBKElBQUMboAd6MANGQzNGPnlGtciN/nJalddCTNmLNtg4fUSby8MWWLlOPIOUVfNE3tgx
XFRETzQNuUEN/1RISuNL3AQ67NONv/CNXNk6xfmV/kNSzeBRy0eHZHmJklQ3b3gtuKd79VZt37Jy
3TaJyWAgdAkhjLaPXwiH1xJ91KIhcdgMpfaWCRSXnamfI6ct/+63cuLphYm5fAGoneBCl55JN5So
hulIoJbomJrZe8AnkhI6ioIjUKOZThZ1MDqYM2nyTlzxG1X4JtbkNK5IPHolTsOSPiZaL/lEHcN2
m/h0GHAyR2KXD0vCKOZRUD/6kwA1IwaFFDnagxhVRAYFYzaiHj9JQx0EAdnkI4LyVNGpLyYIjqgz
UWGhaMVVUqTGQIuWIMaQjvBIIenZLQxUagiiIIS5npPIQM2wnnTIQKeWQMZwfXAgnyf3LfqGhn1a
cy3ne3bKeggZniBZkHaacgKXDIjJhd0SpmgoqY4ZN8YVXBdSLfT3nYyaphSKp8jVll96po2qocxF
VvlUGm9VU/9G9FMlBDOIpVNSFVQu6SlX9VWXw1n5gSI06FeLVRM09VPWyFr80BS+ehNBVUKI8UrL
SjvtoFmwlRTZsFadBVtCpSehRSW+kkQ2ClUzog9LNSKClZXtIx05MR4zVFvYqXDClwCTJnyJsGJv
Boh0Y49uKQfuegd6WG2WsGJGBwfEdWLwCmZ1MLB1IGfLEGbyiggGm692sLAkFmQLewgLW7EG+1Ia
xgn4lbFOUGAF9hwfu2HlghUV1l/nxV35QGFLgGEwUQv0sg0vmwrdRV7olWCKM2FOwLGExgtLoBlL
oz0Vpjgd4aXLhgcQQiA4F5mXsFxAhiALUodFG7VSO7VAFgj/rlZly6lHWCsMs+SkUUC0VDsHcxhA
/IoI/+pkRtdkYbu2bNu2gTBlW4sE1xS3wnC1ULAJuxBgQgtdgIZEYJC3OGsEnxC0W6C3WsAKnTC4
h8azMPExXICNcFu4gdtegwYgIwZnbftIZXYMmMu5dUBiZbtpSztkz5Bmn7stnXuwqZsHm6ASxLZU
ACFj17AYXhsGHWQenNRr16CrWzBsSbkF6TAN1XANk/tuXwFai9uz2xCut6oJtUsOudsEItgKezEH
F5K5jwSpiDBtC4FqctCZTwandRAuIwlklEkH9wotTKtwDzJyLNa64fW7WwQFPjJPlduxSZluSAAS
DZYF+msF//NgvL9Gbr1AhFNglSKCa3A0awe8SkbwEvg6XNibmMu2XNy7ttu2tN47B+K7vo55CSNU
RNQEHaMxPdLDF150EAjzXP5BGEMUWGSBHWwBFhczjZjnFPfhd3HyONBZQtAha2qhlHKRHusxFkIM
eKlRH3y3efAReFMjwilceJmHGjvcNqNQCt8hFVGaGLJhG3vVCyrBEiWkHIyhHFpcxHLBGUhcxYOi
HW7XJJO3UQppABIRc+5qaZUUB/8omAnickD3UX8zc/wGcCSnIA7XQAdgccD1cwPXpiA1YirHhYV8
cS9HXCRlyODij3KKLFlIyC93jgxkcfVGXHZ8sBHCIJdcfv89R2oVV6dB53Ozd8mVtnGG7CAH9yHw
W0SagkLn4SpcA1AJVQQycipLISU4glSdkCMhuCsiCA7FpCcm8nZ7wb/itIxSeCZnw4FNSCW+xIFt
0ysWpBjacM1nwiUDXCupwotGMiJ7kkLJQVHKNCa9wRWvxIFzsTmcVIOKwcw9siu3BILd7IHfHIwY
UQ6vdESo4iKWW1xGx2iwVyGc2GyaJoclRZ6yR56KpADm53rTd3/Bx2TNIoAgRYADYp7ft36fGFIe
VTe953yf6H+vl9IPjXskR1LFJ1IldXszjb7UZ4krx53YIqAAKXHo94gQkrYd3UD8Z4iCk8sjjIJa
czOvMhP/mRUxleNMMEI0BNU46MJT0ji/tXMNO+U4FlMzFLUkxpNH7yMzOgPWFdQfOTkxJHrO8CPV
VpyjqEijp4GKK1QyyhhsMmENOsXDWh1sS9HXXG2LeJFFL1EzNaOMO2q5y4cgeAqZhanHliafBySJ
2eKQ2ssQ3mmAa6hpqjefZ1mGdUOIbUiSEyfaqAuXHolzMu2FnE2JD2ogJZkQ9YqWrY1SeBrajvjb
GreHK0WXTV0LrltHP7k+o1U70xXZwNlKo5UmorPV8naS0DPNnxDM9yNMRog8M/Q+GUFBLyE512BD
/xDAp3UWzPM8KtleewI8hwQ+OElasuEJd5Evw8A+O1kl/zkh3utN1lb0DowVExAcQBRSqog5IN47
0YK5p5MMmhQM2oTpn2OY2f24hkPxE+BLUivnLL8XkOUYl3EDvo6UyrYtdAPphXTwjpbo4ZldqQJI
kJREQC5F4ZV93Eqsy3fUDmQ31b+bDrFk1YQ93apaQdatjXMk4FqrtSJUKMSREbH5SwXzmtmtxMaI
3gglwhlxRc9TH+UCSqSJCs0ji3Vt3/Kr3ySajQtT5olt5W49F58gb3F04AuKACd14gpSkDHu4JEp
4Z8dEbB9qKIN4Y3p4pWokAf0l/yGuqS2l7H94KC5nymelqD9wcdGmYwehzL+E8GtvhoX2jiekSFc
O71gP/89XlDmFJ1hjhXjcxU6MlSwggryFOt1JG8ceuXBrLXG5C7NGE7h/TsrquvapBFx7QlGdWEB
ftc4WqUeOk1xVSeC8qGwdE/hhOZGAD2BJW/1K1rndN3D7tZE+DDDEk2o4D+q3ZECt7m919kOjtpw
E56JWJaOmtKCWZ8BIkneuXKPvKftmdI3x5cnddr4Gekm7oXw/ph1g9G0DWf8boloCEA13n7uyXre
MuOSXu90aQyl7ilMZSupHq2ixWvtcR2y5R6VJ91Zh/Ksxas+blqGtSbEfkg8bK2N0QuLwVlWBfN7
xaxubVvuAfPEw1V0ffJ/5Vgxfw42ElQAA1e0cVb/kPP/a9Iew8BrT7NWpumABJ7GsWVb6cP0TP5O
d1En0PpZ7QCI3qstHZnakJwsmq0QYToh0bfIBLIsBrqmc6qQBGKO3SdwebqmDb6mKX1yDXQtwxWe
wvUtminpoxj32vLoCoEgZOrZ+Ar4imhzknSpv72mjAb43TcgiC+nDMpcm+RetjC5FlY0NhtT6yVe
HlZhOksKOkYLFlGylRuy6YVdAEaz+PWxrl+zFYb7SPD7KCuyUWH7VGCyJosJg7hkoZuw+ApnEctm
z+8MZxYHCPtInSuvHRJm7rq5WgZn1z98q8tkKrb98DqxI/auZeawy/D8ktTxjSDAdFv/9n8EhkBq
4I+9//wPAos4kqV5oql4KKr7wqlyLAHDBLm+873/A4M5xkNoPCKTyiWz6XxCo9Kd65CIYbPaLbfr
/YJdNkZYlGiV0yTEtYSInU8JBLocV8feWb25ruKLAOJxCboUqtxxJZosdi3GCR6eFNo05DQ44EA5
TD01aB4xWOrcpB3QDJYZEKAuHLwNxBQUKgwUtH0l0MymjryexGYFr7Se/A6LIPcKwxxn8cYYlECT
/FJ7nVbTKMcqSKso1zhE2FBEjD5RdDo9FCGN75Quz2td84bvFZgWL1974ae4R2+gCH+pAE57Y3BL
NhP4EOgDZyIAPHhS1K3L6MPiEDK+BhC4oqCArRYGDv+AnIMKwaldKAu0eGkA14IEBAZ8K7DKFyp9
NkvWvPltxE9pKEOuSIkTaNESM0/d3IVzgYGUrqoiOAkSwc03I0G+IsBqJlWrUFk5ZSq04EtXKX8i
1XcWVVWkZatqW1DgZZ2jCZbC1Ot2ajWrXwNrJcB1wJvEixUS08tXcNnAcHWl1HfYpF8SM7/aTTq1
6q1VBsj69bs34kgSe20V3Fn3yoECYmlkW5pT72ird8NRJBeBAoQh5GyQazCBeI7j7XYQN4dDOYUJ
DR5wCoA9AITq6LR3d0C9OMUJE9x1t679QQRNED4Nb29jOYTjHYmGPECAqrTTevef9hdbubn0lwII
MEb/AisKoMVYX6jEspdkCywo4QgLVsiCCCOxMIBLFLJgYUEsEXDgfvrpApN+rgRWgD62zaCPfwIG
OIt+M5xYIoLVwKQTiAxuU+BeQLK4QCw37libiSx6gwyBE244pIcTxjLAGaHZpAuA/Unj4n8x6vVi
ibUZGdmUEh7ZozRoKSklf296SeYINso1lJFXJvAXAggqMBIb+ZU45CxIHWAnThwaSYeSKyJ54jYG
IHpkfjBxxSReJQSnnXo5qPdAcecxcF4AGD2nAwVFRFCEqOx5yul1EzDgwAQ7sIcDqKkGMIEDDlBA
RHuyrgdBEcpxVxwExhYXgX1j+PLNNlcIaGEsitUy/8M2xBQqgmL4BaKPMg1FSAO0+y0AEbflvgiI
QK5YQa65c7IEIbpQ5tfTG9mY22e5R+6SFSqKgeuaV392Wya7er0hEpn8JkNvArwIyJPBDY048bVW
1lSNs3fWFOG9NJjLC77emlkyLwcu0AKYAmEc7RvvjkimviO03PC7Nm7Myyz+bUvzFeYGYyHA8ub2
M8kh//twwsBVtOyxue46a6akupMD1TbYUKs6wArrqg7PARscsRQFgGuu12FHTqsUWMKAOr1qt6w8
B9NcNzRHniTXtew2RM27QJcQsE1oITiA4RHNO689sBBT+OECBxyyHjbae7C5P5F08CzQUN4wvCP8
Tf+y5vfe5CXDZZJkOGN35xUMxQhbXKZ+17w+jMeWp4t77K5fSztIXrJs98uIIzzSgtUQwPrN8QqM
cJbcFBz05MzLvjfgIau+uh5Mk8NRAMo1sPVx8Fxtag7PPVCdsme3OhwF72e3HkXvvx+B9+7D347b
ZXNC//uj5sB7c2vINlR2uzL95SQH4122KMSHSs3rW/IymgHeNbNyuSt3n+OdBf3QuTJJTlvUExnI
9NEzhm1OD0PzXMXmAEHAja4WRqtew6BxBdZJjHfN02EszlCbVhDQSAaE3ciIWMLdmSxhf5ohy4bI
C5gVTwEJ2AlRYnSt5QVRZ28ggH9IEAwYQmOFNPz/4tE0eMPtTaRpPJjA08JGvvNVDYDrAV+mjqUr
/l2CVkWwyA0skgn75fE5qYIbRr4nRwF6JCgYnBCZfCSnm5SMXQZCECAwhqbASWNH2wIabQx1w37t
0EydhJy8zEUmAfXtYxGMCQpZ4pPTOcko0rDk3rIxCwiajm5pStkAZmAUJ9WyGOsqWomo0gqbLFJC
jVRlCItISyRmq1C4zF24ivRE4u2MBrXAD2dAGJFZILNSWiyLIKakQNe9UpcL/FAsTKmZXkazG7jI
lPe4Q4HssK1sRcin2awGx7CtTzlSY085QFGqfK7tBmwjqNuIUIQHTOA4uAIWruoTj0RSpSsdI8kN
/8ViFznlJjJH6VkgQFJMZfzFRUeyxbZegjHQmbQF11jFjg7mUpp8sJ2a8ShuKlfEVXDRSiipDR14
qs4RMIij+xJLC3RIU9twcT+wTBlUpZFUSOYwMiOgKQ8zahuarCJBKbUkM3P3U7FccoEpSx7GPCob
xfTQFmRN3IhSipatJg8pYlleRhP01JeFg6Un3ZBRA5abvDa1Y5Cq6lpto9MR0HNZ8/uaeWDFHfP0
U47PqSwEpGYO45iHPHA8nzkQGlrknPY54XNH+IbDCYFG9KJuqMOB0HDLOigwBbrQFk1qIokNAaK2
SKUDI35brt4C1w95QC4iaJKnNTC3BMI1g3HZcP9cGFgXdISIbrkOQdzkeuG5LphuufyQ3ZR99wUH
Qu6ehqvcQNThvA30Isomwd3hFjcQNJGEEFqlA0zsoAHfAUImgiCeIMQKFALewYERXOAhDJhZsgDE
Kt5LgloYwDYE2TCHO+zhD4M4xK4gad1EPBEgQDR+GllxJ+b2Ag354r4bOoWFTWzjG+M4xzouQ3tN
wA8bG1jFLB4yFG7QA1HEI8JENoKQEaxkIHxiyQaWsg+Q/L0m88DKQ9ayk5fMCS4nAcwQ3ggUFkyK
J1P5yGhWsxKw/AQkRxkJYjaCkXVQHO/VM81AKGQQ7ixZIQBSzzzgM5X9PL8/2zlTRM7zRhC9DnX/
lGoJkdajDwg9BNFWuTiTnrSgG01nTcfRCJbehHCwjGkdMFoIdfZnqjsdhVG7egmwHjKfOT1oRQ+5
1Qx2dEZsfQRf+3rUuoaHr2P9BF3rWdfC5jUQVt0d+0WUOQ3QNH14ANE7jqc56UuVeXAwSG5b1jmo
2ra3kcMcTUnn2dM2t3yE5Z0dvGfawzk1RE/1vc4eqzuiqPa02diDb/vTnpvqjrSXI596x1He50a4
Pc/xHvOUygFVe7as5n2+5cSRAcNRj8alw530cZw+yal22TqLavPYWz5lA0XH2w1yWd3ze8tRj9oS
PnNLfHs66kv4zmV+boykxxIYF/h3MM6eoT+H/+AZtzi6h1WfUz373sPx1GfXzR0BP70466YOet73
qVOpluQ53wE53K2r5XDC7DD/cnxwECrilN0S6Uv3Zxk+DokHMNRVVvA9eWUJtpGvf+hw26ty9QCN
7/Pw/sbVqUKVrH2ONuWQP1aoMsHPB4RvV2VHVtnUtiz7+Z3wpGAb+HjlbQjYSvHY6RUoTIV6xmuK
CLOqVagagKtUEZ6OAWQb4d0mHutkfhwMOFb4tP3fvueT96TfVNzAU6znr4+gwtI4OW61zwfPD/PW
6drYcvC0p60vArAi6B0JCuk4lp8ckoea29BveVUdHvYQlb2mXkV/ykocVsBqh3JiJTXvo56u+P9e
6ZFe41mH361W7VkE6CkfJlSfePQK7VkHRKGN4SHeqIwbdHRe2YyfcAhHBz7f98VfqTWUPmVe7h3g
OWBEZv3AqgHQAmreqFjCd/iX9p2P+jUHJzzHCuog5MnP1bwNDhzYDMIe+cygOgDS/cQgHp0PeQgL
DMpcE6ZaPr1RoHGczI3DsDjfx6GaREmcE0IesamK5bWe+OSgf3XNDY6BDJYDHpEPDrDH2LwRg0nN
E87K05hK2yBhD2ZK25if/PxX1uDgHNVh1YyNsMghDlqhAzIh84mhP/GfZX0H3IgHGqZNwIHecfAg
DHLiOUhNgU2Hrojh2PwhIPoTIIFNqcmPEbb/IdwQFCBNh/yBITwIINyoWhkqWiZqSqCNVgCNzyCi
og8Go2b54A7KkZ1Vh6iYYSHtIa7xDxSSFv1cohv+4hT6IgDhzz11nHn8Hq7M3ftUDQyWijE+oqcQ
lAaKo/9UjcaByqj4DzUekv34zyB2YeTpntW84zASW/3g4KbxIzFaRKQF5OrRjyL6TwxmY/w8IgAl
HXFMIqWth0VsoibmYCdWpP3IzcaJYs350SBOWjOmIh6FpP+8zTUCUnooo3aoI7EJC7ORAi5a5Cew
yte4A3Z8IjDyIQ/+YOTxJEZU4sGFofq5XTMqITQCoiVAoRth5A/4pCJmhyXgof0gZQQIC2vt/9oZ
guEL1tz3EEeomSH/lMp33EC/HSPOccIc3t1xGBmhWUTX2NGt5ZE+euJUMqQhqscctsNA1mNEqiUO
NKMhwUOgfcdCnt/3EIEtHtJ1zCJFPiNj6mJjXqQfDR956GJe3iQxaqBciuQe0ePfmaTEAWVd5hE8
hE8a3iI6euE49B8XXsKsAMvlydEw6uQO4lwxQh4gpUqrhEpQ6lPzJeHnLSEvyoq3TWOgXZ5FxJnV
FEHXQJom2t5r3ZMAqma4haMX9l/taSUgLkfrZSf/rGY/dc3+TNSs/GZvWhRCFQdb8t5dnpsOjOdm
BgdA9WM4Ss36AKHQxVE+KaPcpWfzKaDnzf8HOhDmepzjHeWgCcLKf2LiEm7irPieRbIe2wBS8G0l
bJbPKfJhYGaocOwReS5nqelmSg6nPi0gJZ6mDnBjapZdRDHfZcXctVnWbAojH3ZWRNkmAMFWOYjf
06QoVw6HWTrjY/LiZZlHLmYHjMaKF0IHi/rlfOzoodkoRInfclbWVeJRjaJerujKVjbfGm3pgdbo
//moqLRWzJUnbKlNtHkmHYaWJuRTgJUWJ2gmZ81KYaJoaNXpaMFoHO3pLiafk/pbaYbKkx5fVUKi
4mFWgFUpkaKeRF7kgmqp+AVnDF7bnZmDjbqNoSIpZpqPZmpmmb5WZZWacuzop8BKmCraOc7/WkfE
A/b1wK5sBDoAmCes2SXET4KRAvbhahTMKpQ1WYNZTazE6n+pGCYomJvxQK/uKrzp3bKeWZPFymCi
GZcZaxCYWRQOqxAAK4Gt2bUG2HdUKw8A66xuq60aWIT16pVtAnf6wLWm67siqxRE65kdma4WWLp6
n961ILsaW792mlf6KxB0Fr8GLJOxYMEibMIqbJoNrJwR7MJCbK9FrHbU6sR+j75abMZq7MbSSsW+
JMeCbMiK7MiSbMmaLBO44Mmq7MqybMu67MvK68PC7MzSbM3a7M0qbMri7M7ybM/67M+irMwC7dAS
bdEarcrq7NEq7dIybdMWbNI6bdRK7dRS/+2bCW3VYm3Wam3U6qwE7IDXAgHYBoHXiq0EmO3X8oDZ
qq3YCkHZrq0OgO3anm0AsK0P1C3coi3czm0OxO3b8u3Xym3Y7q3bsu3dBu7fhm3b9oDh6q3a4i3d
+i3d8u3bxm3aPq7kjm3aRu7dQm7hNm7eJm7nDq4TRK7dYi7g+i3hgu7lli3qHu7klm4SOC7r7u3p
/gDnrqHlPu7rGu7ski3inq7n6m7jUu7wIi7n4u7k3i7otu7xsu7lQu/z2u7iZi7wzq71bu7iym3t
Tm/vXm/wAq/10m7g1m3zTm/wpq70gq/zii/1Gu/Ytm7ysu/yDq/50u/5Iu/2yu/+ou7qXv+U+4Zv
++Zt5VauAOPv/XYv7Bbw+w4w9ZrvAwtw4b5u/f6t/gaw5vqu+kIwA5evAgOw8IouBg9u7YJwBH/w
7hLvBmOuCvsv+m4v+/6u6a6w6GawCE+w/kpw7Oou4aavBa/vD2cZd8Zw5zKv+xKwCbsu966u5wrv
C58v5AIu2qpw8z6wElfvDFdw/wIwFv8wD3vvDdtuB0MvFVPwBZdwF39w+iLx+rJwCn8vF2PxEFsu
BOdwEYev/C7BAmfx58qwC1tx7rYv45qxB6tu9MquHQNxGDMBGSPxBuOwFV/vAtuv/0qyBhuy4hpw
345uAYtxIityEl/y9xYy9kayAk/yII//8e46Lu6Wbymjchc/Mg1PcANbMuwi8imzagDL8SfT8i5P
wRDrMRzzMhJ0cB2rsitHQSWbsSBPsfoegRj3rRHjbTDz7hxf8hZfcR+38TNvMQhzMv6+sDKDMzLf
cRPgcCOPLxrvXR638Dd7cSTHsjVf8O2esw3PcgszMPP6cBKf7Sg/sQw3synbsw4XLDALLh6Trgbv
Mz9zb+m6MzHz8TwbQT3L8h8bsiivsRfvqz2/LzPvMQJD9PyaMh6TNDdnMzbnczmH7kpntDOj9Ehz
dExrb+wyMumCcRl7Mj7rtC47L0JL9DwLMku/9E5rcy3/swsyc1AT70dT9D9T8jAbcEgT/7VTU3VT
Gy8uw+9M6zM5v3RQK7VSv3Ix260Tc7AbjzAyW/VQL/M093Fbwy9ZV/Q7W/QykzVGR/RRtx5Yp7QU
X3NfY3JYL7Ja/3RVK4E3F/ZgIzb/ovQpn/EB7/VP+/JFS/YV+/Qjk208y/Nj+7RjD3Zlx7NeTzXu
MkAL8PNf/3VTp7Vbw3Vqt/NCU/RrLzRlx7by6u1JCzYrzzJcw/RYEzQHnzVvi/Js169wa0T+1rVw
o/Y+s/Zb33NotyBpb210S/d0G+1o1wB1Y3d2azfMWvd2e/d3gzfHdnd4k3d5m3esjfd5q/d6s/cU
jLcTa/Lo3rJAQzZV+/Vmi/BEV+9X2/92URuBAAC4AOgAgA94gBd4EBB4AAS4gSu4gB9Bgjd4gUM4
hPsAhR84ECx4hu9Ahlu4Eiz4hROxX/P2Ejc3Udv1Y9+3UI9zidc356Y3LUtxQ7u05AY3W/fvKtM3
Z4v4Uusyjuu4P39xP+94gnN4DhC5gx+5kSP5kit5kz+4g0d4lCd5g394lEs4g/dAh284lDt5lnO4
loO4Nsd2QO+0RW+zjBtx9tKzbv/4VcdvlUE3DJ8wQ89tNct5JzP2ZG/14TbxVb8yF+c5TmM4k0v5
klf5lCM6of83lCd6lW95l2M5lXu5EHw5pQv4hFc6gfuwYhu1LIcuK7u0HiMvUKu4Xp//MSNH9osb
NA1HryNjMArTOE579UzntkqL9CeLtQdHNWdb9ZEfOqEnupMH+6L7OoNP+aNbuYd/OZczAYFbuKM7
umbLeh5L8JyjbxQ/cTBD9myjdhkf8ZHFefe+8bhL76gfr4/Xsp238xKncgLzeCCvsZ4jAbQzOpYX
e6MbO7P/wK9feZgLu6Ev+xIse6TzgLNz+bCHeGdr9TET90STsEnvsFuD9GGH8LkLObhftwVru7i7
MnzD+i5XMSQ/vJ+PMVf3OU+Lc5BHtsDrO7Ij/BMkOZh3OaS3vMwPvMwjeMAXupOHPCL395DFdzgD
9Ij/vGV/NBsfPSmEe5qrcSc89Hxn/zut0/QbqzaMn3ZfUzFmTwHCD7ylbznOV3i9X7mGN7vO57yX
Y3q873rbjrnWJ/PQD7XRT7wco/oTv/htL3Zpf7y7I70WT/xU8zSsu3GnC/q8F7m/DzvOg/2+iz2y
z7zitzyVR3vYLzo77/rGr72J67etC74tc/w64Hm5J30uK7zD13U3v/mNX7zHqzglC73eNzaQD7R8
e73jd73kH/vtJ7u/F7zOEzymV/qk277ZDzraH37C6/j95jCL2zcQ1zPrQ79gOzM0Y3us80DK5PXP
l/WfZ7b2c7zGu73mQzVhb37z737aOz7lz7zw9/7Zpz/7L/76oz+x+z6z43zQ3/Pvrv/6IWcuCEiB
KAajiZ7pWq5o2b7uHM9unZLuojC5BAy2hMIbEfgr2mRLpg3XjD6lqhcxCr1ZjzOB9ytIgcdNL2oM
Npm76HWg7Waf4ba2mE51wcPLbN8Jc+RXRQNoIjiY2CdoxPXXhMPjk0dZaXmJmam5ydnp+QkaKjpK
Wmp6KiWJusra6voKGys7S1tLqmqbq7vL2+v7CxwcgCtcbHyMnKy8fNvD/AwdLT1NDUssFZQzckW4
nX2YOeQ4pEU5uKXdXYW4sqeG9sZnmpYXd2f/jh9v1x6mL/evnrx3ZQYKzBSHXz55awLe+0JwIUQ2
bszAizenosF9F+vwucbuD5SRLMD/lTz0TV0NcY7QKVFXbh3KloXu9ItoMyM9jmQeWpyYZg/DhhDJ
7Izy0+jGORwxSjyqBw9TnDp7OqWicapWOVcPOrWHjyhVnku3LiGK55pJlkp0xEzXtlwMGHJT4ljp
JO8UkyrubuFmVuzNsQH1afyJMyvGpAMZF6QatOziogYRI62M2ezXjQ4HXwXrz45gShdBR306mHFk
rJkjqu1bci4jlYQCjYMbO503wHzvzja09vc5skA5U04tNWdT5YoRH3V8NnQ/ywCP2+xM3PTYzVEV
ek7Y0ePTiVw/h5862vzjy6ddOzs5FzjfbuTWysUtf7hu/TSQ6O0fEmsPBcYHduNp/6feZFYRt153
UPm04GSV/KNYTgY2aBpoFU7YmGTRVaiaTgS6o9UaPCiwwF9x9aZbbfDN15tdetFlzm/GiNahVRce
ViB59MAD3WZhCUUQdaetdqBkQg2FVo7nCdTkktwtx1prnCSFXEQXTtcjCgygWFMS2iDC30y8vbUX
mVmsRCYLjKhp5kvZkdeeFCQOSKWWxRUZWnN0kiZdYX1KV+eVe0bHpXcLbSced1LaOaiihuqJyY/y
fJkimpeMdCaMe0ES5iOe+IUNopBeImiTN4nF6qCJ/VmVn12tap1nBSnUaoOodgmejl3OasmWDvZE
omBD4srrpWBqGpJ+pLa4WzZ4Uf8x3LOQ2OhpgIUyumujjqkqYj6L9rpUhkNNGSuhtgLLFbm6cqsc
lQjulF6V65qqWYk+GpdluAFgGic3pDqrBZyfenqwigJTy/BJXsWb6JJPcrloow5SVK6VTNVLa5JG
4luex792S5iHHD8G3sPwOjTkvcoBTO1s2iqsCZs0/RfzzdGm9N/MEM/JypYsK1mWpNd5+HPI77p8
mdGFOo1echlNDfSwD+ar2Z3lwVxN115/DXbY0XAtdtlmn4122qSQrXbbbr8Nd9psx0133XbfLczc
eO/Nd99+r71stAjjDG3CMOU2U+GFv6mwf40j7NuKKs7Y6X4z7uf44SesCRPPirj/ia3DNeqs+Hyc
s1R6zz6nrjl8L30uKi1cDxwmYM6GHheNMiVOuIvZJuybpprzZq3D9eWl+/HbyGAbXc/WZzuoB7Ml
p/Cmx05C7tLzPnj38Qn+O4vGQz55964wMEn4JJFfquj2bS4+bPG/Ja31zb+ouB/KF5+E49+4Jb/d
yQ+A9nkeOuRTsOltr2Dr856Y4pO9hcVPf4f7nuXGFxy78AyBvTtf+sCnuwu67wm4K+AET1iI462O
gOIAh/8kSD/QbRCDLoJefkyIGwP+bobzQ94CrfAD0Z0OgQSMCfU+1UDahG9362tgEmeBvhh2Dmdl
cuBu1pG55KkOiE8UYRd9WJfM/1kieuLTYhnr17/OZTFOWwxii2A3xvwxgRxFQN0Ns8UmIRqxEf6D
0f9qFyoopo9xU4ScGH+InyIisYMAstG0mnczC6LEep3Aix3L6ELLVbGQcVReD3f2OgFS0Ydm9IYA
N5lJPy4OEM1inxpRGYooNoyGrAtY9WgEwFZ+EpSwpKQMK3et1dkSjnuEjQUVyUs/ilFNdOwZI6fg
yVI185Ss3CAzmXc5Z+5SeNFsXStkqT7QUa6XNXGe9FSYhy8ukHQj3FnsKkFMDJrzevwJYQedGM5G
hvJ9v/zjNNGJQsMxEVo6FCU/uWezXIAzme7E4ori2chUMtSUVCwhIlf5TCWiie1TLYGoG+FHn1cK
jAvxtKQv04Q4ac7RoW9c4ztDGghm7ZOhtwnYQWGxUP7V0p7tVKn5AvnTzVHwpZIkKvCAyroqIhOk
PX1pLefYpvYJFKlMpeo903lRQDbVmzz1YP+qt1VvDhOrY3VqgLLIUeKdaYXA9B0fXyec0G01rWBN
Klk54VFf5tV89cyqEeXKSHKCYqF/K6xhD4vYJRA2sYxtrGPrttjHSnaylPVaZCuL2cxqNm8f3Kxn
PwtaQYZ2tKQtbSnQh9rUqna1rG2ta18L29jKdra0ra1tb4vb3Op2t7ztrW9/C9zgCne4xP1tCAAA
Ow==
--047d7bfcf88e7dac8404feb406ac--


From nobody Mon Jul 21 11:49:04 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE181A01E1 for ; Mon, 21 Jul 2014 11:48:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.779
X-Spam-Level: 
X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 0nOj0wC5ZG_w for ; Mon, 21 Jul 2014 11:48:51 -0700 (PDT)
Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F5AA1A01BD for ; Mon, 21 Jul 2014 11:48:51 -0700 (PDT)
Received: by mail-vc0-f173.google.com with SMTP id hy10so12805817vcb.4 for ; Mon, 21 Jul 2014 11:48:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9Du8DTUxGo3feJoI/imAS0E2qUpCemub/ynn91/DU3M=; b=fKn0gr9lf3E1gfsksTjyrHvZAjunLRslCHpw1kcfd7KIEDxvgHj18ci8cDDNDmEkUQ 9xSfmOICEG3LloyuyTGjxgQXjBCNgzp5oWNyD8qaSfmMI2VsrYV1cGqLSHfQpefHlEWR i3Rdaf1OadPv5ocnD0VT46Qa9RNIbPw9aLkOZIiZOwDURPihTOGMHnlCJ8aToft25R6K YYdDEXjXkRmlQPwFU4RTM72nim3GY2W6NQLO/hGUcM64wKRORmjrOx3AwP+S6D9VMH3m 0yvLM40T3zx2cgbjHAjJTC/Iu7cjXPtffoq5U0XiVipATuoicJ9QU5jLzG0oTWGOb3dC pXiw==
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:content-type; bh=9Du8DTUxGo3feJoI/imAS0E2qUpCemub/ynn91/DU3M=; b=iiYydd3nJCJ/pt8rFGdVGnUYEDbgAg9d+qOwVxDw5siZCuRpQv54icYoUa2Kuc84pr Ck7+yQ7sHan3giI6F7RVNsGarwbAgAJgtWxEfCR92J4IXxWakTVyjPkCR9JCMQni1J2N xvYsKILG2SA60/7eaPXQBPQppZ+VFYiaNIztgL6Tn8ZPGcDQ5h/JbYPWj5PhI9rB2WQz q7thggIHClvZFOan5AI1eJzNe9BSPHPrFhYVahxkcdFSGO0nHRJxm4leZKWGvoonqfgb bKJcp39fkOAWzLUOvuS0LbZ+S9SZ/4EgaQayqYSEKh9k+uNwrNxHMIAAfJq4KPF4UM+y RPiQ==
X-Gm-Message-State: ALoCoQkZEKI1z8EDWCaZMwrwbX3KiO8JkkSogbsvq/XjuDmuTYDS4CZV+9cTQal0ULMVvyOcuoAV
X-Received: by 10.52.129.232 with SMTP id nz8mr4156200vdb.94.1405968530310; Mon, 21 Jul 2014 11:48:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.66.242 with HTTP; Mon, 21 Jul 2014 11:48:28 -0700 (PDT)
In-Reply-To: <47.D7.22787.0939CC35@epcpsbgx2.samsung.com>
References: <47.D7.22787.0939CC35@epcpsbgx2.samsung.com>
From: Justin Uberti 
Date: Mon, 21 Jul 2014 14:48:28 -0400
Message-ID: 
To: Kiran Kumar Guduru 
Content-Type: multipart/related; boundary=bcaec51dd641d0c11d04feb88eea
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/FNpurPUe9eD54aJGgeOROHCqrbA
Cc: franklin blek , "rtcweb@ietf.org" , "public-webrtc@w3.org" 
Subject: Re: [rtcweb] New Version Notification for draft-guduru-rtcweb-codec-preferences-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 21 Jul 2014 18:48:56 -0000

--bcaec51dd641d0c11d04feb88eea
Content-Type: multipart/alternative; boundary=bcaec51dd641d0c11904feb88ee9

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

On Mon, Jul 21, 2014 at 12:14 AM, Kiran Kumar Guduru <
kiran.guduru@samsung.com> wrote:

>  Hi Justin,
>
> I don't feel the number of API addition, is a big problem :).
>
You are proposing expanding the API surface of WebRTC 1.0 by over 10%. This
is a significant addition (the current PeerConnection object itself only
has 21 methods), and doesn't count the codec object that would have to be
added to the spec to complete this design.

> I feel this is very useful to add in 1.0. I don't know what made you feel
> the existing usecases to be contrived. AFAIK, apps has that intellegence to
> analyze on the bandwidth utilization.
>
I think the examples are contrived, because they don't show how the apps
would use this API to accomplish the desired behavior. Apps certainly don't
know the power characteristics of the various codecs (i.e. whether they are
hardware-backed or not), and only have indirect knowledge of the bandwidth
situation; they don't have all the details on congestion that the browser
has access to, and could end up incorrectly dropping to a low-bandwidth
codec, or oscillating between codecs, because of the lack of detailed
information.

> One use case I missed in the draft and I would like to add in the next
> version is, the problem arising at gateways, which can only be solved by
> apps, but never by browser as explained below.
>
>
>
> "Considering the usecase off an application is serving the needs between
> webrtc client and non-webrtc client (IMS for example), that does not
> support the mandatory codecs specified for WebRTC, then gateways will solve
> the problem by transcoding.
>
> If a browser is supporting codecs which don't need this kind of
> transcoding, but giving low priority to them, then according to existing
> specifications, the gateway has to accept the offer with priorities
> specified by webrtc (considering the case for webrtc client as offerer)
> client through answer, then again gateway has to send the offer with its
> order of priority to change to codec preferences, resulting in a second
> offer-answer negotiation."  In this kind of usecases API are known about
> the priority of codecs required and we can avoid this kind of unnecessary
> signaling if APIs are provided to apps to prioritize the codecs.
>
>
>
> I hope this example will add some more value to this idea.
>

This is a useful example, thanks for explaining this. But I think this is
the wrong solution. Quoth RFC3264, S. 7:

*   When the offerer receives the answer, it MAY send media on the*
*   accepted stream(s) (assuming it is listed as sendrecv or recvonly in*
*   the answer).  It MUST send using a media format listed in the answer,*
*   and it SHOULD use the first media format listed in the answer when it*
*   does send.*

Note the use of SHOULD vs MUST. Ergo, even if the offer has m=audio 1111
RTP/SAVPF X Y Z, it is completely legal for the callee to apply its own
priorities and send with codec Y or Z instead of X if there are compelling
reasons to do so. This makes more sense to me than doing an immediate
re-offer, or adding APIs to reorder the browser's codec list.

>
>
>
>
> ------- *Original Message* -------
>
> *Sender* : Justin Uberti
>
> *Date* : Jul 21, 2014 12:30 (GMT+09:00)
>
> *Title* : Re: New Version Notification for
> draft-guduru-rtcweb-codec-preferences-01.txt
>
>
> This seems like a pretty big hammer to solve a fairly small problem. This
> proposal adds 6 new API points for the purpose of changing the order of
> codecs in createOffer, which seems like a high cost-benefit ratio. And
> while the use cases listed here are helpful, they seem somewhat contrived
> to me, since it seems unlikely that the application can make better choices
> about bandwidth or power consumption than the browser.
>
> Without a specific, concrete example, I remain unconvinced that this is
> worth doing in the 1.0 timeframe. Post-1.0, we can probably find a way to
> provide this sort of lower-level control.
>
>
> On Sat, Jul 12, 2014 at 9:41 PM, franklin blek 
> wrote:
>
>> Hi,
>> The draft seems to explain codec preferences in a good way.
>> I think this has a good potenitial to be a part of WebRTC1.0.
>>
>>
>>
>> On Sat, Jul 5, 2014 at 10:26 AM, Kiran Kumar Guduru <
>> kiran.guduru@samsung.com> wrote:
>>
>>>  Hi,
>>>
>>> A new version of codec preferences draft has been published, by
>>> modifying as per the review comments received.
>>>
>>> Please review and let me know your comments.
>>>
>>>
>>>
>>> Thanks & Regards,
>>>
>>> Kiran.
>>>
>>>
>>>
>>> ------- *Original Message* -------
>>>
>>> *Sender* : internet-drafts@ietf.org
>>>
>>> *Date* : Jul 02, 2014 18:28 (GMT+09:00)
>>>
>>> *Title* : New Version Notification for
>>> draft-guduru-rtcweb-codec-preferences-01.txt
>>>
>>>
>>>
>>> A new version of I-D, draft-guduru-rtcweb-codec-preferences-01.txt
>>> has been successfully submitted by Kiran Kumar Guduru and posted to the
>>> IETF repository.
>>>
>>> Name: draft-guduru-rtcweb-codec-preferences
>>> Revision: 01
>>> Title: WebRTC Codec Preferences
>>> Document date: 2014-07-02
>>> Group: Individual Submission
>>> Pages: 7
>>> URL:
>>> http://www.ietf.org/internet-drafts/draft-guduru-rtcweb-codec-preferences-01.txt
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-guduru-rtcweb-codec-preferences/
>>> Htmlized:
>>> http://tools.ietf.org/html/draft-guduru-rtcweb-codec-preferences-01
>>> Diff:
>>> http://www.ietf.org/rfcdiff?url2=draft-guduru-rtcweb-codec-preferences-01
>>>
>>> Abstract:
>>>    WebRTC specifies to implement a minimum set of required codecs to
>>>    ensure guaranteed interoperability between WebRTC peers.  WebRTC
>>>    allows browser implementers to support vendor specific codecs apart
>>>    from mandatory codecs.  This document specifies the way for
>>>    JavaScript applications to give preferences for media codecs in
>>>    WebRTC context out of the available codecs in browser for creating
>>>    the offer / answer.
>>>
>>>
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> The IETF Secretariat
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
>
>
>

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





On Mon, Jul 21, 2014 at 12:14 AM, Kiran Kumar Guduru <kiran=
.guduru@samsung.com> wrote:











Hi Justin,


I don't feel the number of API addition,=C2=A0is a big problem :).
You are proposing expanding the API surface of We=
bRTC 1.0 by over 10%. This is a significant addition (the current PeerConne=
ction object itself only has 21 methods), and doesn't count the codec o=
bject that would have to be added to the spec to complete this design.




I feel this is very useful to add in 1.0. I don't know what made you=
 feel the existing usecases to be contrived. AFAIK, apps has that intellege=
nce to analyze on the bandwidth utilization.


I think the examples are contrived, because they don't show how the app=
s would use this API to accomplish the desired behavior. Apps certainly don=
't know the power characteristics of the various codecs (i.e. whether t=
hey are hardware-backed or not), and only have indirect knowledge of the ba=
ndwidth situation; they don't have all the details on congestion that t=
he browser has access to, and could end up incorrectly dropping to a low-ba=
ndwidth codec, or oscillating between codecs, because of the lack of detail=
ed information.





One use case I missed in the draft and I would like to add in the next v=
ersion is, the problem arising at gateways, which can only be solved by app=
s, but never by browser as explained below.


=C2=A0


"Considering the usecase off an application is serving the needs be=
tween webrtc client and non-webrtc client (IMS for example), that does not =
support the mandatory codecs specified for WebRTC, then gateways will solve=
 the problem by transcoding. 




If a browser is supporting codecs which don't need this kind of tran=
scoding, but giving low priority to them, then according to=C2=A0existing s=
pecifications, the gateway has to accept the offer with priorities specifie=
d by webrtc (considering the case for webrtc client as offerer) client thro=
ugh answer, then again gateway has to send the offer with its order of prio=
rity to change to codec preferences, resulting in a second offer-answer neg=
otiation."=C2=A0 In this kind of usecases API are known about the prio=
rity of codecs required and we can avoid this kind of unnecessary signaling=
 if APIs are provided to apps to prioritize the codecs.




=C2=A0


I hope this example will add some more value to this idea.

This is a useful example, thanks for explainin=
g this. But I think this is the wrong solution. Quoth RFC3264, S. 7:




=C2=A0 =C2=A0When the offerer receives the answer, i=
t MAY send media on the
=C2=A0 =C2=A0accepted stream(s) (a=
ssuming it is listed as sendrecv or recvonly in
=C2=A0 =C2=
=A0the answer). =C2=A0It MUST send using a media format listed in the answe=
r,



=C2=A0 =C2=A0and it SHOULD use the first media format listed in the=
 answer when it
=C2=A0 =C2=A0does send.
<=
br>
Note the use of SHOULD vs MUST. Ergo, even if the offer h=
as m=3Daudio 1111 RTP/SAVPF X Y Z, it is completely legal for the callee to=
 apply its own priorities and send with codec Y or Z instead of X if there =
are compelling reasons to do so. This makes more sense to me than doing an =
immediate re-offer, or adding APIs to reorder the browser's codec list.=






=C2=A0


=C2=A0


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


Sender : Justin Uberti<juberti@google.com>


Date : Jul 21, 2014 12:30 (GMT+09:00)


Title : Re: New Version Notification for draft-guduru-rtcweb-code=
c-preferences-01.txt


=C2=A0


This seems like a pretty big hammer to solve a fairly smal=
l problem. This proposal adds 6 new API points for the purpose of changing =
the order of codecs in createOffer, which seems like a high cost-benefit ra=
tio. And while the use cases listed here are helpful, they seem somewhat co=
ntrived to me, since it seems unlikely that the application can make better=
 choices about bandwidth or power consumption than the browser.




Without a specific, concrete example, I remain unconvinced that this i=
s worth doing in the 1.0 timeframe. Post-1.0, we can probably find a way to=
 provide this sort of lower-level control.






On Sat, Jul 12, 2014 at 9:41 PM, franklin blek <=
span dir=3D"ltr"><franklin.blek@gmail.com> wrote:




Hi,


The draft seems to explain codec preferences in a good way.


I think this has a good potenitial to=C2=A0be a part of=C2=A0WebRTC1.0=
.








=C2=A0


On Sat, Jul 5, 2014 at 10:26 AM, Kiran Kumar Gud=
uru <kiran.guduru@samsung.com> wrote:






Hi,


A new version of codec preferences draft has been published, by modifyin=
g as per the review comments received.


Please review and let me know your comments.


=C2=A0


Thanks & Regards,


Kiran.


=C2=A0


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


Sender : internet-drafts@ietf.org<internet-drafts@ietf.org>


Date : Jul 02, 2014 18:28 (GMT+09:00)


Title : New Version Notification for draft-guduru-rtcweb-codec-pr=
eferences-01.txt


=C2=A0

A new version of I-D, draft-guduru-rtcweb-codec-preference=
s-01.txt
has been successfully submitted by Kiran Kumar Guduru and poste=
d to the
IETF repository.

Name: draft-guduru-rtcweb-codec-prefere=
nces


Revision: 01
Title: WebRTC Codec Preferences
Document date: 2014-07-0=
2
Group: Individual Submission
Pages: 7
URL:=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http://www.ietf.org/internet-drafts/draft-guduru-rtcweb-codec-p=
references-01.txt


Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc/draft-guduru-rtcweb-codec-preferen=
ces/
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/draft-guduru-rtcweb-codec-preferences-01


Diff:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://www.ietf.org/rfcdiff?url2=3Ddraft-guduru-rtc=
web-codec-preferences-01

Abstract:
=C2=A0=C2=A0 WebRTC specif=
ies to implement a minimum set of required codecs to


=C2=A0=C2=A0 ensure guaranteed interoperability between WebRTC peers.=C2=A0=
=C2=A0WebRTC
=C2=A0=C2=A0 allows browser implementers to support vendor =
specific codecs apart
=C2=A0=C2=A0 from mandatory codecs.=C2=A0=C2=A0Thi=
s document specifies the way for
=C2=A0=C2=A0 JavaScript applications to=
 give preferences for media codecs in


=C2=A0=C2=A0 WebRTC context out of the available codecs in browser for crea=
ting
=C2=A0=C2=A0 the offer / answer.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0


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


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

The IETF Secretar=
iat



=C2=A0


=C2=A0















=C2=A0


=C2=A0














--bcaec51dd641d0c11904feb88ee9--
--bcaec51dd641d0c11d04feb88eea
Content-Type: image/gif; name="201407210944275_7EUABGFC.gif"
Content-Disposition: inline; filename="201407210944275_7EUABGFC.gif"
Content-Transfer-Encoding: base64
Content-ID: <2LL5XOK0LK7C@namo.co.kr>
X-Attachment-Id: eb38c4492533b79_0.2

R0lGODlhCAKQAMQAAAAAAP///8k6OspMTNRiYtt0dOSOjumiovLExPfZ2fvt7f/+/uvr69TU1Lm5
uYyMjG9vb0dHRzMzMyoqKgICAv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEA
ABUALAAAAAAIApAAAAX/ICOOZGmeaKqubOu+cCzPdG3feK7vfO//uYBwSCwaj8ikcslsOp/QqHRK
rVqv2Kx2y+16v1YReEwum8/otHrNbhcX8Lh8Tq/b73al2M3v+/+AgYKDVniGh4h1egyEjY6PkJGS
k0OJlpd5SXsBDQ6engwNjFKilHoNSaVYqkisTK5CoUqdo02waLJMubGogg6Nt1S/a3IIeAoJmHAJ
CnTIipq1EBETFBERDRHDUdqmSQ8PSd1GENzbR+NN6UPgqRPYr+Hrae1MDhFE94MUfA3hRvOKlHPC
z8xAIXIG4EFQAJGBOQWMzWEIDckmIfqEBFR3zhuWgk82DhGJrmOAekcy/zJpR5IMSiUqA8T8A5LN
yyc1l+QEU9MSxUMKD/2cs6iIyggQKExAxSCCtVoBmlKgIC/pBEZSIzBw8I/ryWr/hDSYRjUpvq9U
ozpdGiBp2rZTyzUAO9BqLyHt3IZt22Cs03Jm0YbzS2HgA2sTfj0AixfxNqlsszLqtjgtuAfDMA+p
BlgpqgdJh82d8ACpZ7VPiUA4HNlp2tVKHVT7NbewWKUR9kpNy4Azvt6F8SGdIBg1W71C7CY/rTru
ycr/kiYlAm620+hxm4o9K5ax5Las+04gvTschL5kD8LFBmFCZ9twp8NlO6S21uJfE7dNygD6+kpx
NGTAAQMQkIwCBAxggP+AySTw0AEJPmTAAAU4SIABBiQDIYUKDCVHUflwd81JgJWomlz8UMMABCay
OFdyDzBAgXh3OTBjA1T1JsqNS5VG4lxbEVeaCEut1hQ+i/VHHDsPACkbEdrYuGNfFDggI41SXnml
jVbyiGWV7CDZYjnaXDmXP+CcNWOY/ly12En3xeLiiKDtZ+dISOLDIicpCucmPuTlFkBiMu61J47g
HZnoiFWK4KWPoDkppJuTKkmdVjomieiQ8uHl5o38DKkjW3Vu5gCOK5pIp1YuHpqiJzNeWV+VNjIi
ao+shkoplPLE6OWVbyLlKI04bpPQAgU0dICAByiQLLLGUDSAMQMkkMD/tAgMoICzCChQLbIHeBgH
iEMc9Ys+a8pIhBg2BiCoumsiqh8F/dUVVkYFaVPqaj6KIBsjvQCcGL0yCTcMfc8ByQmUnpzVTaj2
ZqTvQIntCw7F2/TLSLyvWgyOjEGG6O7BaBbB0rn4pFtTN/qw++pzBb8Y85KrrctIuwT7mHPKeNmr
8b8Lj7OU0HdFxUnF/7yMKJMFC1GQwA7sqV93GMmKKMtIhuPyyBKfw49KUHdzNckjDUYijKXKo5i9
AfQUh0IRLSBtM8tCK3dD3yazgEI/xd3ggOLCQS5GIqLc9lRTEWHfy2037jR4Lx6G+L1qasQV4jlS
E2N8TK01MOHuYp6x/3mFFR2lw7+EijlmqNej7+quP6b5xkN0DHuvNZdrsOU3ndw05isbvvjIMN9j
I+LanPXS8AWhC3pBkk8V4+ych474PaIPARnSj49TUzv4GpcYkDXFBNLL+rQz/OmWE/H1Wdsb3332
3QkaPVUvUba64wi9bbe0cKBI3CgCobjt7W5wiNuECECAcDWEDoNrWvucJxYiTO1l8MLK19xTjnoU
LXwj82BUQtGeqPiDXnsaGcH0MY6iqa8/BLNc1xonwq7FToSx0x4JiUMwdenrH58JB2jWpDviDYor
e4EZ1vhnOsNdkHjgS14stqK8vTyxeTz7HV6AOMKxECcUh2mKaIxYtP8U/rB7w/heOMJnxl9wUGQy
AVlU0Je1QSWNa6hznwTb6D0yKq5g/KpgPdQGs4XxLwDHGiDeAtgQRS6AGcs6wAH7hoBl0c2BFTnC
RSRIPBaucUlOs1WKOigcIZ5lPKgAmqBA57goXcVdoNEaVU4pv2KxSFH9QthlaDmShrVvg5NhneVe
VCxVYoY4xRpCzXxoSq69MjftkBEoQeejTSXRd56UyTSXmLOXRbFtnynHmkjjPlHCsi2lRKfjjLnM
WQqhYr/BVVQQJrYq1QNiJ1GjBJUGptAUgV4gs9/u0heObuKxfbWTYD250sFQxfMuhLqHwnLzoiex
7JkFxQgi/efIAkj/ckHgWsCyEkCAZgxokg+MyAEegiBMQjAaRilc03DklHO0xz30okY1UEFTIjpF
meOZJgi7cVNkIiZGQcWHjaiRG+BMY57UUM/HksqwGY5nRUFV6C+KutWstiWo26ApOXuKCqJm1XVJ
bNl4wNS7WQrPGmDqZdNuyh/KrBFJ71jTYsZjqPHwR6z4GM07+FdUPs2Oqr2JKlTdkw/EQPOOvckr
de76uKW+Y4072SuKnFJWwx0GNH7NqS+N+M7EnMWyTR3PTxPLWHYc9avjSc5sjFjYQV2FH4mMVkNI
ysCGZCtZAiJAAQy0AAZS0lvDxVDgFhDBJpzKCH0xSi22ApUidAIK/9eNxXMxcpfsnsRW3NluSoqm
BytxwiT5gIp342iErdyFutA1CcLGOwvylsu+0MVvfGsR3fyuq2i7sO5jxCtemXzQvutNCXbPUSrr
vte8reCpfjUJYbF05ML2ha+F84Ff71I3HIh4RhysVQyJLKBDzZgDig3RXI9MYTGHQa+Ln+CXGdsY
DIuR8Y2x0B+PiEAZQA6ykO/AJB0bYchITrIcFNAsJTs5yDvOgieiTGUt/BgTzLhElp9siS0X48R6
C7KXtZxiMSNgzGM2hIjn4OU1TyTMSXYzi1NRXezWeRBGhgkYaHNn66q3zyaUQp4DrQmeArrQTbgy
HB5yCAMmwtFcbv+0if13AEkKudJAxnSQfwtpSN/hIct19HIN0EAlg/qBiDiCP0grhZtoQTNLWJFO
qLATLYQqiSVhWBJm0oRaxxQmu3tCOXitSQYcS9KX8HSkM23pIGsaE89WRrQDNOk7BMUOyqZDtoF8
bUscwXeEaAkrk+BrJpT7CucuwjpIQmwstHvcUHhfoo29aAqJtECWJhBxC7DAZAyoQAcqAIfs1u9H
ChxDzoJDwkccoQSSesQLGoAkLYShBBQgxRlS1sQbfm9+N4jj1xJusx+ZoH0T6OKPLJBHi8FASTpr
4P82EG9XqiEKEcAYG5p4xCVEIQedWOASt9syJKTvBBT95SjHULX/Ir5Se9+bQxOqEEsFnvSij0sy
siGNaVqTGhY9JRtb7Q/pyDkfF1ZmbVWqTUOXovbupOUvZV9OpwqZNb7KvSDKGWJYq8GW3FhDI4ep
HPjsXh53WWUyilHKXlrmGsw00ysjeY7d10NFvnCiHE7VE3rgHrqnKtMasuE8a3RD75SfWebaIqnR
CYAsZT3kWXXD0AJkr9KLQ2j2BnBWQ4i7Ujk0sKV761YcstUsbWVrWxE5KUkPiOnfe9RbHZpWcZu1
8ptfa+SlrlvQq3/moMfh5seXPe2VdfGKR0T12Tp9t4xfLW9ZC1sCesjyRd1I8jurWeJ/fe6z9f5m
ydzk14IAFJF//60nUqhmJ7c0J2KCgGQCAWJkI76SMFfxJEPyJK7VCUJyH+QRKEg1PeEwPvSyGP6g
FRSYK5P1OEnSLpziUCHzJhbUTIXRFAXlgIJya0dUK4dCHCqyJ9pwJqhSRK7CQvyQOyg4gSyIFCxk
ODxoMFkyIyuoOLQSK/TigzE0QsfSe7NXaYwmSR2lW3vTIHDDEJZmINqCQLJ3cwzHSAfEcovmUrUn
Ug+hEJWGAKx3N1gIfnXIEMuXhUt2YtoHB5W2hye1DHnofin3PxoHLXdYSYwGOClFLQi0LXIThsPX
SF4YN3lDiT8RFH7zc5LEN3gDhog4LhyjRIajMlCUJlIEDkBTVv//oEsUUzIWmISziA2vZCXZNChg
xycnSEN3VE/npIs3gRU6k0opY4y+KDNWsjWr1DFsAzpbww/WsIsJdU/EsxVJ+DvgdVAj0w3qokc2
9IxWSGkDUI4SF21diEDXFoYGFBFBQRGq120/AUDF8EBz+IjFZTdyGC7mSCGaFhHZYo4RYY8jp2/P
EhT3CIjN5iHrOIqYplKWplL96IaQCI8JInBCh0Dp2JCOtIYKVCClBopreEAdyVznY4q/gzmdhBQw
JkSkcx7WMxWjwzuU1TRRgjlSVESuIZN9xDS+iEbzcz1t9Q5ZREHOw4rccTRwZUS2MzlFNDyJ4R7t
okfWmA7ZaJT/TIg6PZlQNrQ/U3SFlqYh+TaKjlSG3gItBnRzZfgTF8JoAZSHi1SPCklJ01eG+/gT
27KIeNkhBMlwyUCPCSlSC/lA69cMZ+lID1lJEamYy4BA+ohAaEiSJiZAl0gthqmJD8SJlYRymCaS
ZomZpKhBKElBQUMboAd6MANGQzNGPnlGtciN/nJalddCTNmLNtg4fUSby8MWWLlOPIOUVfNE3tgx
XFRETzQNuUEN/1RISuNL3AQ67NONv/CNXNk6xfmV/kNSzeBRy0eHZHmJklQ3b3gtuKd79VZt37Jy
3TaJyWAgdAkhjLaPXwiH1xJ91KIhcdgMpfaWCRSXnamfI6ct/+63cuLphYm5fAGoneBCl55JN5So
hulIoJbomJrZe8AnkhI6ioIjUKOZThZ1MDqYM2nyTlzxG1X4JtbkNK5IPHolTsOSPiZaL/lEHcN2
m/h0GHAyR2KXD0vCKOZRUD/6kwA1IwaFFDnagxhVRAYFYzaiHj9JQx0EAdnkI4LyVNGpLyYIjqgz
UWGhaMVVUqTGQIuWIMaQjvBIIenZLQxUagiiIIS5npPIQM2wnnTIQKeWQMZwfXAgnyf3LfqGhn1a
cy3ne3bKeggZniBZkHaacgKXDIjJhd0SpmgoqY4ZN8YVXBdSLfT3nYyaphSKp8jVll96po2qocxF
VvlUGm9VU/9G9FMlBDOIpVNSFVQu6SlX9VWXw1n5gSI06FeLVRM09VPWyFr80BS+ehNBVUKI8UrL
SjvtoFmwlRTZsFadBVtCpSehRSW+kkQ2ClUzog9LNSKClZXtIx05MR4zVFvYqXDClwCTJnyJsGJv
Boh0Y49uKQfuegd6WG2WsGJGBwfEdWLwCmZ1MLB1IGfLEGbyiggGm692sLAkFmQLewgLW7EG+1Ia
xgn4lbFOUGAF9hwfu2HlghUV1l/nxV35QGFLgGEwUQv0sg0vmwrdRV7olWCKM2FOwLGExgtLoBlL
oz0Vpjgd4aXLhgcQQiA4F5mXsFxAhiALUodFG7VSO7VAFgj/rlZly6lHWCsMs+SkUUC0VDsHcxhA
/IoI/+pkRtdkYbu2bNu2gTBlW4sE1xS3wnC1ULAJuxBgQgtdgIZEYJC3OGsEnxC0W6C3WsAKnTC4
h8azMPExXICNcFu4gdtegwYgIwZnbftIZXYMmMu5dUBiZbtpSztkz5Bmn7stnXuwqZsHm6ASxLZU
ACFj17AYXhsGHWQenNRr16CrWzBsSbkF6TAN1XANk/tuXwFai9uz2xCut6oJtUsOudsEItgKezEH
F5K5jwSpiDBtC4FqctCZTwandRAuIwlklEkH9wotTKtwDzJyLNa64fW7WwQFPjJPlduxSZluSAAS
DZYF+msF//NgvL9Gbr1AhFNglSKCa3A0awe8SkbwEvg6XNibmMu2XNy7ttu2tN47B+K7vo55CSNU
RNQEHaMxPdLDF150EAjzXP5BGEMUWGSBHWwBFhczjZjnFPfhd3HyONBZQtAha2qhlHKRHusxFkIM
eKlRH3y3efAReFMjwilceJmHGjvcNqNQCt8hFVGaGLJhG3vVCyrBEiWkHIyhHFpcxHLBGUhcxYOi
HW7XJJO3UQppABIRc+5qaZUUB/8omAnickD3UX8zc/wGcCSnIA7XQAdgccD1cwPXpiA1YirHhYV8
cS9HXCRlyODij3KKLFlIyC93jgxkcfVGXHZ8sBHCIJdcfv89R2oVV6dB53Ozd8mVtnGG7CAH9yHw
W0SagkLn4SpcA1AJVQQycipLISU4glSdkCMhuCsiCA7FpCcm8nZ7wb/itIxSeCZnw4FNSCW+xIFt
0ysWpBjacM1nwiUDXCupwotGMiJ7kkLJQVHKNCa9wRWvxIFzsTmcVIOKwcw9siu3BILd7IHfHIwY
UQ6vdESo4iKWW1xGx2iwVyGc2GyaJoclRZ6yR56KpADm53rTd3/Bx2TNIoAgRYADYp7ft36fGFIe
VTe953yf6H+vl9IPjXskR1LFJ1IldXszjb7UZ4krx53YIqAAKXHo94gQkrYd3UD8Z4iCk8sjjIJa
czOvMhP/mRUxleNMMEI0BNU46MJT0ji/tXMNO+U4FlMzFLUkxpNH7yMzOgPWFdQfOTkxJHrO8CPV
VpyjqEijp4GKK1QyyhhsMmENOsXDWh1sS9HXXG2LeJFFL1EzNaOMO2q5y4cgeAqZhanHliafBySJ
2eKQ2ssQ3mmAa6hpqjefZ1mGdUOIbUiSEyfaqAuXHolzMu2FnE2JD2ogJZkQ9YqWrY1SeBrajvjb
GreHK0WXTV0LrltHP7k+o1U70xXZwNlKo5UmorPV8naS0DPNnxDM9yNMRog8M/Q+GUFBLyE512BD
/xDAp3UWzPM8KtleewI8hwQ+OElasuEJd5Evw8A+O1kl/zkh3utN1lb0DowVExAcQBRSqog5IN47
0YK5p5MMmhQM2oTpn2OY2f24hkPxE+BLUivnLL8XkOUYl3EDvo6UyrYtdAPphXTwjpbo4ZldqQJI
kJREQC5F4ZV93Eqsy3fUDmQ31b+bDrFk1YQ93apaQdatjXMk4FqrtSJUKMSREbH5SwXzmtmtxMaI
3gglwhlxRc9TH+UCSqSJCs0ji3Vt3/Kr3ySajQtT5olt5W49F58gb3F04AuKACd14gpSkDHu4JEp
4Z8dEbB9qKIN4Y3p4pWokAf0l/yGuqS2l7H94KC5nymelqD9wcdGmYwehzL+E8GtvhoX2jiekSFc
O71gP/89XlDmFJ1hjhXjcxU6MlSwggryFOt1JG8ceuXBrLXG5C7NGE7h/TsrquvapBFx7QlGdWEB
ftc4WqUeOk1xVSeC8qGwdE/hhOZGAD2BJW/1K1rndN3D7tZE+DDDEk2o4D+q3ZECt7m919kOjtpw
E56JWJaOmtKCWZ8BIkneuXKPvKftmdI3x5cnddr4Gekm7oXw/ph1g9G0DWf8boloCEA13n7uyXre
MuOSXu90aQyl7ilMZSupHq2ixWvtcR2y5R6VJ91Zh/Ksxas+blqGtSbEfkg8bK2N0QuLwVlWBfN7
xaxubVvuAfPEw1V0ffJ/5Vgxfw42ElQAA1e0cVb/kPP/a9Iew8BrT7NWpumABJ7GsWVb6cP0TP5O
d1En0PpZ7QCI3qstHZnakJwsmq0QYToh0bfIBLIsBrqmc6qQBGKO3SdwebqmDb6mKX1yDXQtwxWe
wvUtminpoxj32vLoCoEgZOrZ+Ar4imhzknSpv72mjAb43TcgiC+nDMpcm+RetjC5FlY0NhtT6yVe
HlZhOksKOkYLFlGylRuy6YVdAEaz+PWxrl+zFYb7SPD7KCuyUWH7VGCyJosJg7hkoZuw+ApnEctm
z+8MZxYHCPtInSuvHRJm7rq5WgZn1z98q8tkKrb98DqxI/auZeawy/D8ktTxjSDAdFv/9n8EhkBq
4I+9//wPAos4kqV5oql4KKr7wqlyLAHDBLm+873/A4M5xkNoPCKTyiWz6XxCo9Kd65CIYbPaLbfr
/YJdNkZYlGiV0yTEtYSInU8JBLocV8feWb25ruKLAOJxCboUqtxxJZosdi3GCR6eFNo05DQ44EA5
TD01aB4xWOrcpB3QDJYZEKAuHLwNxBQUKgwUtH0l0MymjryexGYFr7Se/A6LIPcKwxxn8cYYlECT
/FJ7nVbTKMcqSKso1zhE2FBEjD5RdDo9FCGN75Quz2td84bvFZgWL1974ae4R2+gCH+pAE57Y3BL
NhP4EOgDZyIAPHhS1K3L6MPiEDK+BhC4oqCArRYGDv+AnIMKwaldKAu0eGkA14IEBAZ8K7DKFyp9
NkvWvPltxE9pKEOuSIkTaNESM0/d3IVzgYGUrqoiOAkSwc03I0G+IsBqJlWrUFk5ZSq04EtXKX8i
1XcWVVWkZatqW1DgZZ2jCZbC1Ot2ajWrXwNrJcB1wJvEixUS08tXcNnAcHWl1HfYpF8SM7/aTTq1
6q1VBsj69bs34kgSe20V3Fn3yoECYmlkW5pT72ird8NRJBeBAoQh5GyQazCBeI7j7XYQN4dDOYUJ
DR5wCoA9AITq6LR3d0C9OMUJE9x1t679QQRNED4Nb29jOYTjHYmGPECAqrTTevef9hdbubn0lwII
MEb/AisKoMVYX6jEspdkCywo4QgLVsiCCCOxMIBLFLJgYUEsEXDgfvrpApN+rgRWgD62zaCPfwIG
OIt+M5xYIoLVwKQTiAxuU+BeQLK4QCw37libiSx6gwyBE244pIcTxjLAGaHZpAuA/Unj4n8x6vVi
ibUZGdmUEh7ZozRoKSklf296SeYINso1lJFXJvAXAggqMBIb+ZU45CxIHWAnThwaSYeSKyJ54jYG
IHpkfjBxxSReJQSnnXo5qPdAcecxcF4AGD2nAwVFRFCEqOx5yul1EzDgwAQ7sIcDqKkGMIEDDlBA
RHuyrgdBEcpxVxwExhYXgX1j+PLNNlcIaGEsitUy/8M2xBQqgmL4BaKPMg1FSAO0+y0AEbflvgiI
QK5YQa65c7IEIbpQ5tfTG9mY22e5R+6SFSqKgeuaV392Wya7er0hEpn8JkNvArwIyJPBDY048bVW
1lSNs3fWFOG9NJjLC77emlkyLwcu0AKYAmEc7RvvjkimviO03PC7Nm7Myyz+bUvzFeYGYyHA8ub2
M8kh//twwsBVtOyxue46a6akupMD1TbYUKs6wArrqg7PARscsRQFgGuu12FHTqsUWMKAOr1qt6w8
B9NcNzRHniTXtew2RM27QJcQsE1oITiA4RHNO689sBBT+OECBxyyHjbae7C5P5F08CzQUN4wvCP8
Tf+y5vfe5CXDZZJkOGN35xUMxQhbXKZ+17w+jMeWp4t77K5fSztIXrJs98uIIzzSgtUQwPrN8QqM
cJbcFBz05MzLvjfgIau+uh5Mk8NRAMo1sPVx8Fxtag7PPVCdsme3OhwF72e3HkXvvx+B9+7D347b
ZXNC//uj5sB7c2vINlR2uzL95SQH4122KMSHSs3rW/IymgHeNbNyuSt3n+OdBf3QuTJJTlvUExnI
9NEzhm1OD0PzXMXmAEHAja4WRqtew6BxBdZJjHfN02EszlCbVhDQSAaE3ciIWMLdmSxhf5ohy4bI
C5gVTwEJ2AlRYnSt5QVRZ28ggH9IEAwYQmOFNPz/4tE0eMPtTaRpPJjA08JGvvNVDYDrAV+mjqUr
/l2CVkWwyA0skgn75fE5qYIbRr4nRwF6JCgYnBCZfCSnm5SMXQZCECAwhqbASWNH2wIabQx1w37t
0EydhJy8zEUmAfXtYxGMCQpZ4pPTOcko0rDk3rIxCwiajm5pStkAZmAUJ9WyGOsqWomo0gqbLFJC
jVRlCItISyRmq1C4zF24ivRE4u2MBrXAD2dAGJFZILNSWiyLIKakQNe9UpcL/FAsTKmZXkazG7jI
lPe4Q4HssK1sRcin2awGx7CtTzlSY085QFGqfK7tBmwjqNuIUIQHTOA4uAIWruoTj0RSpSsdI8kN
/8ViFznlJjJH6VkgQFJMZfzFRUeyxbZegjHQmbQF11jFjg7mUpp8sJ2a8ShuKlfEVXDRSiipDR14
qs4RMIij+xJLC3RIU9twcT+wTBlUpZFUSOYwMiOgKQ8zahuarCJBKbUkM3P3U7FccoEpSx7GPCob
xfTQFmRN3IhSipatJg8pYlleRhP01JeFg6Un3ZBRA5abvDa1Y5Cq6lpto9MR0HNZ8/uaeWDFHfP0
U47PqSwEpGYO45iHPHA8nzkQGlrknPY54XNH+IbDCYFG9KJuqMOB0HDLOigwBbrQFk1qIokNAaK2
SKUDI35brt4C1w95QC4iaJKnNTC3BMI1g3HZcP9cGFgXdISIbrkOQdzkeuG5LphuufyQ3ZR99wUH
Qu6ehqvcQNThvA30Isomwd3hFjcQNJGEEFqlA0zsoAHfAUImgiCeIMQKFALewYERXOAhDJhZsgDE
Kt5LgloYwDYE2TCHO+zhD4M4xK4gad1EPBEgQDR+GllxJ+b2Ag354r4bOoWFTWzjG+M4xzouQ3tN
wA8bG1jFLB4yFG7QA1HEI8JENoKQEaxkIHxiyQaWsg+Q/L0m88DKQ9ayk5fMCS4nAcwQ3ggUFkyK
J1P5yGhWsxKw/AQkRxkJYjaCkXVQHO/VM81AKGQQ7ixZIQBSzzzgM5X9PL8/2zlTRM7zRhC9DnX/
lGoJkdajDwg9BNFWuTiTnrSgG01nTcfRCJbehHCwjGkdMFoIdfZnqjsdhVG7egmwHjKfOT1oRQ+5
1Qx2dEZsfQRf+3rUuoaHr2P9BF3rWdfC5jUQVt0d+0WUOQ3QNH14ANE7jqc56UuVeXAwSG5b1jmo
2ra3kcMcTUnn2dM2t3yE5Z0dvGfawzk1RE/1vc4eqzuiqPa02diDb/vTnpvqjrSXI596x1He50a4
Pc/xHvOUygFVe7as5n2+5cSRAcNRj8alw530cZw+yal22TqLavPYWz5lA0XH2w1yWd3ze8tRj9oS
PnNLfHs66kv4zmV+boykxxIYF/h3MM6eoT+H/+AZtzi6h1WfUz373sPx1GfXzR0BP70466YOet73
qVOpluQ53wE53K2r5XDC7DD/cnxwECrilN0S6Uv3Zxk+DokHMNRVVvA9eWUJtpGvf+hw26ty9QCN
7/Pw/sbVqUKVrH2ONuWQP1aoMsHPB4RvV2VHVtnUtiz7+Z3wpGAb+HjlbQjYSvHY6RUoTIV6xmuK
CLOqVagagKtUEZ6OAWQb4d0mHutkfhwMOFb4tP3fvueT96TfVNzAU6znr4+gwtI4OW61zwfPD/PW
6drYcvC0p60vArAi6B0JCuk4lp8ckoea29BveVUdHvYQlb2mXkV/ykocVsBqh3JiJTXvo56u+P9e
6ZFe41mH361W7VkE6CkfJlSfePQK7VkHRKGN4SHeqIwbdHRe2YyfcAhHBz7f98VfqTWUPmVe7h3g
OWBEZv3AqgHQAmreqFjCd/iX9p2P+jUHJzzHCuog5MnP1bwNDhzYDMIe+cygOgDS/cQgHp0PeQgL
DMpcE6ZaPr1RoHGczI3DsDjfx6GaREmcE0IesamK5bWe+OSgf3XNDY6BDJYDHpEPDrDH2LwRg0nN
E87K05hK2yBhD2ZK25if/PxX1uDgHNVh1YyNsMghDlqhAzIh84mhP/GfZX0H3IgHGqZNwIHecfAg
DHLiOUhNgU2Hrojh2PwhIPoTIIFNqcmPEbb/IdwQFCBNh/yBITwIINyoWhkqWiZqSqCNVgCNzyCi
og8Go2b54A7KkZ1Vh6iYYSHtIa7xDxSSFv1cohv+4hT6IgDhzz11nHn8Hq7M3ftUDQyWijE+oqcQ
lAaKo/9UjcaByqj4DzUekv34zyB2YeTpntW84zASW/3g4KbxIzFaRKQF5OrRjyL6TwxmY/w8IgAl
HXFMIqWth0VsoibmYCdWpP3IzcaJYs350SBOWjOmIh6FpP+8zTUCUnooo3aoI7EJC7ORAi5a5Cew
yte4A3Z8IjDyIQ/+YOTxJEZU4sGFofq5XTMqITQCoiVAoRth5A/4pCJmhyXgof0gZQQIC2vt/9oZ
guEL1tz3EEeomSH/lMp33EC/HSPOccIc3t1xGBmhWUTX2NGt5ZE+euJUMqQhqscctsNA1mNEqiUO
NKMhwUOgfcdCnt/3EIEtHtJ1zCJFPiNj6mJjXqQfDR956GJe3iQxaqBciuQe0ePfmaTEAWVd5hE8
hE8a3iI6euE49B8XXsKsAMvlydEw6uQO4lwxQh4gpUqrhEpQ6lPzJeHnLSEvyoq3TWOgXZ5FxJnV
FEHXQJom2t5r3ZMAqma4haMX9l/taSUgLkfrZSf/rGY/dc3+TNSs/GZvWhRCFQdb8t5dnpsOjOdm
BgdA9WM4Ss36AKHQxVE+KaPcpWfzKaDnzf8HOhDmepzjHeWgCcLKf2LiEm7irPieRbIe2wBS8G0l
bJbPKfJhYGaocOwReS5nqelmSg6nPi0gJZ6mDnBjapZdRDHfZcXctVnWbAojH3ZWRNkmAMFWOYjf
06QoVw6HWTrjY/LiZZlHLmYHjMaKF0IHi/rlfOzoodkoRInfclbWVeJRjaJerujKVjbfGm3pgdbo
//moqLRWzJUnbKlNtHkmHYaWJuRTgJUWJ2gmZ81KYaJoaNXpaMFoHO3pLiafk/pbaYbKkx5fVUKi
4mFWgFUpkaKeRF7kgmqp+AVnDF7bnZmDjbqNoSIpZpqPZmpmmb5WZZWacuzop8BKmCraOc7/WkfE
A/b1wK5sBDoAmCes2SXET4KRAvbhahTMKpQ1WYNZTazE6n+pGCYomJvxQK/uKrzp3bKeWZPFymCi
GZcZaxCYWRQOqxAAK4Gt2bUG2HdUKw8A66xuq60aWIT16pVtAnf6wLWm67siqxRE65kdma4WWLp6
n961ILsaW792mlf6KxB0Fr8GLJOxYMEibMIqbJoNrJwR7MJCbK9FrHbU6sR+j75abMZq7MbSSsW+
JMeCbMiK7MiSbMmaLBO44Mmq7MqybMu67MvK68PC7MzSbM3a7M0qbMri7M7ybM/67M+irMwC7dAS
bdEarcrq7NEq7dIybdMWbNI6bdRK7dRS/+2bCW3VYm3Wam3U6qwE7IDXAgHYBoHXiq0EmO3X8oDZ
qq3YCkHZrq0OgO3anm0AsK0P1C3coi3czm0OxO3b8u3Xym3Y7q3bsu3dBu7fhm3b9oDh6q3a4i3d
+i3d8u3bxm3aPq7kjm3aRu7dQm7hNm7eJm7nDq4TRK7dYi7g+i3hgu7lli3qHu7klm4SOC7r7u3p
/gDnrqHlPu7rGu7ski3inq7n6m7jUu7wIi7n4u7k3i7otu7xsu7lQu/z2u7iZi7wzq71bu7iym3t
Tm/vXm/wAq/10m7g1m3zTm/wpq70gq/zii/1Gu/Ytm7ysu/yDq/50u/5Iu/2yu/+ou7qXv+U+4Zv
++Zt5VauAOPv/XYv7Bbw+w4w9ZrvAwtw4b5u/f6t/gaw5vqu+kIwA5evAgOw8IouBg9u7YJwBH/w
7hLvBmOuCvsv+m4v+/6u6a6w6GawCE+w/kpw7Oou4aavBa/vD2cZd8Zw5zKv+xKwCbsu966u5wrv
C58v5AIu2qpw8z6wElfvDFdw/wIwFv8wD3vvDdtuB0MvFVPwBZdwF39w+iLx+rJwCn8vF2PxEFsu
BOdwEYev/C7BAmfx58qwC1tx7rYv45qxB6tu9MquHQNxGDMBGSPxBuOwFV/vAtuv/0qyBhuy4hpw
345uAYtxIityEl/y9xYy9kayAk/yII//8e46Lu6Wbymjchc/Mg1PcANbMuwi8imzagDL8SfT8i5P
wRDrMRzzMhJ0cB2rsitHQSWbsSBPsfoegRj3rRHjbTDz7hxf8hZfcR+38TNvMQhzMv6+sDKDMzLf
cRPgcCOPLxrvXR638Dd7cSTHsjVf8O2esw3PcgszMPP6cBKf7Sg/sQw3synbsw4XLDALLh6Trgbv
Mz9zb+m6MzHz8TwbQT3L8h8bsiivsRfvqz2/LzPvMQJD9PyaMh6TNDdnMzbnczmH7kpntDOj9Ehz
dExrb+wyMumCcRl7Mj7rtC47L0JL9DwLMku/9E5rcy3/swsyc1AT70dT9D9T8jAbcEgT/7VTU3VT
Gy8uw+9M6zM5v3RQK7VSv3Ix260Tc7AbjzAyW/VQL/M093Fbwy9ZV/Q7W/QykzVGR/RRtx5Yp7QU
X3NfY3JYL7Ja/3RVK4E3F/ZgIzb/ovQpn/EB7/VP+/JFS/YV+/Qjk208y/Nj+7RjD3Zlx7NeTzXu
MkAL8PNf/3VTp7Vbw3Vqt/NCU/RrLzRlx7by6u1JCzYrzzJcw/RYEzQHnzVvi/Js169wa0T+1rVw
o/Y+s/Zb33NotyBpb210S/d0G+1o1wB1Y3d2azfMWvd2e/d3gzfHdnd4k3d5m3esjfd5q/d6s/cU
jLcTa/Lo3rJAQzZV+/Vmi/BEV+9X2/92URuBAAC4AOgAgA94gBd4EBB4AAS4gSu4gB9Bgjd4gUM4
hPsAhR84ECx4hu9Ahlu4Eiz4hROxX/P2Ejc3Udv1Y9+3UI9zidc356Y3LUtxQ7u05AY3W/fvKtM3
Z4v4Uusyjuu4P39xP+94gnN4DhC5gx+5kSP5kit5kz+4g0d4lCd5g394lEs4g/dAh284lDt5lnO4
loO4Nsd2QO+0RW+zjBtx9tKzbv/4VcdvlUE3DJ8wQ89tNct5JzP2ZG/14TbxVb8yF+c5TmM4k0v5
klf5lCM6of83lCd6lW95l2M5lXu5EHw5pQv4hFc6gfuwYhu1LIcuK7u0HiMvUKu4Xp//MSNH9osb
NA1HryNjMArTOE579UzntkqL9CeLtQdHNWdb9ZEfOqEnupMH+6L7OoNP+aNbuYd/OZczAYFbuKM7
umbLeh5L8JyjbxQ/cTBD9myjdhkf8ZHFefe+8bhL76gfr4/Xsp238xKncgLzeCCvsZ4jAbQzOpYX
e6MbO7P/wK9feZgLu6Ev+xIse6TzgLNz+bCHeGdr9TET90STsEnvsFuD9GGH8LkLObhftwVru7i7
MnzD+i5XMSQ/vJ+PMVf3OU+Lc5BHtsDrO7Ij/BMkOZh3OaS3vMwPvMwjeMAXupOHPCL395DFdzgD
9Ij/vGV/NBsfPSmEe5qrcSc89Hxn/zut0/QbqzaMn3ZfUzFmTwHCD7ylbznOV3i9X7mGN7vO57yX
Y3q873rbjrnWJ/PQD7XRT7wco/oTv/htL3Zpf7y7I70WT/xU8zSsu3GnC/q8F7m/DzvOg/2+iz2y
z7zitzyVR3vYLzo77/rGr72J67etC74tc/w64Hm5J30uK7zD13U3v/mNX7zHqzglC73eNzaQD7R8
e73jd73kH/vtJ7u/F7zOEzymV/qk277ZDzraH37C6/j95jCL2zcQ1zPrQ79gOzM0Y3us80DK5PXP
l/WfZ7b2c7zGu73mQzVhb37z737aOz7lz7zw9/7Zpz/7L/76oz+x+z6z43zQ3/Pvrv/6IWcuCEiB
KAajiZ7pWq5o2b7uHM9unZLuojC5BAy2hMIbEfgr2mRLpg3XjD6lqhcxCr1ZjzOB9ytIgcdNL2oM
Npm76HWg7Waf4ba2mE51wcPLbN8Jc+RXRQNoIjiY2CdoxPXXhMPjk0dZaXmJmam5ydnp+QkaKjpK
Wmp6KiWJusra6voKGys7S1tLqmqbq7vL2+v7CxwcgCtcbHyMnKy8fNvD/AwdLT1NDUssFZQzckW4
nX2YOeQ4pEU5uKXdXYW4sqeG9sZnmpYXd2f/jh9v1x6mL/evnrx3ZQYKzBSHXz55awLe+0JwIUQ2
bszAizenosF9F+vwucbuD5SRLMD/lTz0TV0NcY7QKVFXbh3KloXu9ItoMyM9jmQeWpyYZg/DhhDJ
7Izy0+jGORwxSjyqBw9TnDp7OqWicapWOVcPOrWHjyhVnku3LiGK55pJlkp0xEzXtlwMGHJT4ljp
JO8UkyrubuFmVuzNsQH1afyJMyvGpAMZF6QatOziogYRI62M2ezXjQ4HXwXrz45gShdBR306mHFk
rJkjqu1bci4jlYQCjYMbO503wHzvzja09vc5skA5U04tNWdT5YoRH3V8NnQ/ywCP2+xM3PTYzVEV
ek7Y0ePTiVw/h5862vzjy6ddOzs5FzjfbuTWysUtf7hu/TSQ6O0fEmsPBcYHduNp/6feZFYRt153
UPm04GSV/KNYTgY2aBpoFU7YmGTRVaiaTgS6o9UaPCiwwF9x9aZbbfDN15tdetFlzm/GiNahVRce
ViB59MAD3WZhCUUQdaetdqBkQg2FVo7nCdTkktwtx1prnCSFXEQXTtcjCgygWFMS2iDC30y8vbUX
mVmsRCYLjKhp5kvZkdeeFCQOSKWWxRUZWnN0kiZdYX1KV+eVe0bHpXcLbSced1LaOaiihuqJyY/y
fJkimpeMdCaMe0ES5iOe+IUNopBeImiTN4nF6qCJ/VmVn12tap1nBSnUaoOodgmejl3OasmWDvZE
omBD4srrpWBqGpJ+pLa4WzZ4Uf8x3LOQ2OhpgIUyumujjqkqYj6L9rpUhkNNGSuhtgLLFbm6cqsc
lQjulF6V65qqWYk+GpdluAFgGic3pDqrBZyfenqwigJTy/BJXsWb6JJPcrloow5SVK6VTNVLa5JG
4luex792S5iHHD8G3sPwOjTkvcoBTO1s2iqsCZs0/RfzzdGm9N/MEM/JypYsK1mWpNd5+HPI77p8
mdGFOo1echlNDfSwD+ar2Z3lwVxN115/DXbY0XAtdtlmn4122qSQrXbbbr8Nd9psx0133XbfLczc
eO/Nd99+r71stAjjDG3CMOU2U+GFv6mwf40j7NuKKs7Y6X4z7uf44SesCRPPirj/ia3DNeqs+Hyc
s1R6zz6nrjl8L30uKi1cDxwmYM6GHheNMiVOuIvZJuybpprzZq3D9eWl+/HbyGAbXc/WZzuoB7Ml
p/Cmx05C7tLzPnj38Qn+O4vGQz55964wMEn4JJFfquj2bS4+bPG/Ja31zb+ouB/KF5+E49+4Jb/d
yQ+A9nkeOuRTsOltr2Dr856Y4pO9hcVPf4f7nuXGFxy78AyBvTtf+sCnuwu67wm4K+AET1iI462O
gOIAh/8kSD/QbRCDLoJefkyIGwP+bobzQ94CrfAD0Z0OgQSMCfU+1UDahG9362tgEmeBvhh2Dmdl
cuBu1pG55KkOiE8UYRd9WJfM/1kieuLTYhnr17/OZTFOWwxii2A3xvwxgRxFQN0Ns8UmIRqxEf6D
0f9qFyoopo9xU4ScGH+InyIisYMAstG0mnczC6LEep3Aix3L6ELLVbGQcVReD3f2OgFS0Ydm9IYA
N5lJPy4OEM1inxpRGYooNoyGrAtY9WgEwFZ+EpSwpKQMK3et1dkSjnuEjQUVyUs/ilFNdOwZI6fg
yVI185Ss3CAzmXc5Z+5SeNFsXStkqT7QUa6XNXGe9FSYhy8ukHQj3FnsKkFMDJrzevwJYQedGM5G
hvJ9v/zjNNGJQsMxEVo6FCU/uWezXIAzme7E4ori2chUMtSUVCwhIlf5TCWiie1TLYGoG+FHn1cK
jAvxtKQv04Q4ac7RoW9c4ztDGghm7ZOhtwnYQWGxUP7V0p7tVKn5AvnTzVHwpZIkKvCAyroqIhOk
PX1pLefYpvYJFKlMpeo903lRQDbVmzz1YP+qt1VvDhOrY3VqgLLIUeKdaYXA9B0fXyec0G01rWBN
Klk54VFf5tV89cyqEeXKSHKCYqF/K6xhD4vYJRA2sYxtrGPrttjHSnaylPVaZCuL2cxqNm8f3Kxn
PwtaQYZ2tKQtbSnQh9rUqna1rG2ta18L29jKdra0ra1tb4vb3Op2t7ztrW9/C9zgCne4xP1tCAAA
Ow==
--bcaec51dd641d0c11d04feb88eea
Content-Type: image/gif; name="201407210944267_QKNMBDIF.gif"
Content-Disposition: inline; filename="201407210944267_QKNMBDIF.gif"
Content-Transfer-Encoding: base64
Content-ID: 
X-Attachment-Id: eb38c4492533b79_0.1

R0lGODlhCAKQAMQAAAAAAP///8k6OspMTNRiYtt0dOSOjumiovLExPfZ2fvt7f/+/uvr69TU1Lm5
uYyMjG9vb0dHRzMzMyoqKgICAv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEA
ABUALAAAAAAIApAAAAX/ICOOZGmeaKqubOu+cCzPdG3feK7vfO//uYBwSCwaj8ikcslsOp/QqHRK
rVqv2Kx2y+16v1YReEwum8/otHrNbhcX8Lh8Tq/b73al2M3v+/+AgYKDVniGh4h1egyEjY6PkJGS
k0OJlpd5SXsBDQ6engwNjFKilHoNSaVYqkisTK5CoUqdo02waLJMubGogg6Nt1S/a3IIeAoJmHAJ
CnTIipq1EBETFBERDRHDUdqmSQ8PSd1GENzbR+NN6UPgqRPYr+Hrae1MDhFE94MUfA3hRvOKlHPC
z8xAIXIG4EFQAJGBOQWMzWEIDckmIfqEBFR3zhuWgk82DhGJrmOAekcy/zJpR5IMSiUqA8T8A5LN
yyc1l+QEU9MSxUMKD/2cs6iIyggQKExAxSCCtVoBmlKgIC/pBEZSIzBw8I/ryWr/hDSYRjUpvq9U
ozpdGiBp2rZTyzUAO9BqLyHt3IZt22Cs03Jm0YbzS2HgA2sTfj0AixfxNqlsszLqtjgtuAfDMA+p
BlgpqgdJh82d8ACpZ7VPiUA4HNlp2tVKHVT7NbewWKUR9kpNy4Azvt6F8SGdIBg1W71C7CY/rTru
ycr/kiYlAm620+hxm4o9K5ax5Las+04gvTschL5kD8LFBmFCZ9twp8NlO6S21uJfE7dNygD6+kpx
NGTAAQMQkIwCBAxggP+AySTw0AEJPmTAAAU4SIABBiQDIYUKDCVHUflwd81JgJWomlz8UMMABCay
OFdyDzBAgXh3OTBjA1T1JsqNS5VG4lxbEVeaCEut1hQ+i/VHHDsPACkbEdrYuGNfFDggI41SXnml
jVbyiGWV7CDZYjnaXDmXP+CcNWOY/ly12En3xeLiiKDtZ+dISOLDIicpCucmPuTlFkBiMu61J47g
HZnoiFWK4KWPoDkppJuTKkmdVjomieiQ8uHl5o38DKkjW3Vu5gCOK5pIp1YuHpqiJzNeWV+VNjIi
ao+shkoplPLE6OWVbyLlKI04bpPQAgU0dICAByiQLLLGUDSAMQMkkMD/tAgMoICzCChQLbIHeBgH
iEMc9Ys+a8pIhBg2BiCoumsiqh8F/dUVVkYFaVPqaj6KIBsjvQCcGL0yCTcMfc8ByQmUnpzVTaj2
ZqTvQIntCw7F2/TLSLyvWgyOjEGG6O7BaBbB0rn4pFtTN/qw++pzBb8Y85KrrctIuwT7mHPKeNmr
8b8Lj7OU0HdFxUnF/7yMKJMFC1GQwA7sqV93GMmKKMtIhuPyyBKfw49KUHdzNckjDUYijKXKo5i9
AfQUh0IRLSBtM8tCK3dD3yazgEI/xd3ggOLCQS5GIqLc9lRTEWHfy2037jR4Lx6G+L1qasQV4jlS
E2N8TK01MOHuYp6x/3mFFR2lw7+EijlmqNej7+quP6b5xkN0DHuvNZdrsOU3ndw05isbvvjIMN9j
I+LanPXS8AWhC3pBkk8V4+ych474PaIPARnSj49TUzv4GpcYkDXFBNLL+rQz/OmWE/H1Wdsb3332
3QkaPVUvUba64wi9bbe0cKBI3CgCobjt7W5wiNuECECAcDWEDoNrWvucJxYiTO1l8MLK19xTjnoU
LXwj82BUQtGeqPiDXnsaGcH0MY6iqa8/BLNc1xonwq7FToSx0x4JiUMwdenrH58JB2jWpDviDYor
e4EZ1vhnOsNdkHjgS14stqK8vTyxeTz7HV6AOMKxECcUh2mKaIxYtP8U/rB7w/heOMJnxl9wUGQy
AVlU0Je1QSWNa6hznwTb6D0yKq5g/KpgPdQGs4XxLwDHGiDeAtgQRS6AGcs6wAH7hoBl0c2BFTnC
RSRIPBaucUlOs1WKOigcIZ5lPKgAmqBA57goXcVdoNEaVU4pv2KxSFH9QthlaDmShrVvg5NhneVe
VCxVYoY4xRpCzXxoSq69MjftkBEoQeejTSXRd56UyTSXmLOXRbFtnynHmkjjPlHCsi2lRKfjjLnM
WQqhYr/BVVQQJrYq1QNiJ1GjBJUGptAUgV4gs9/u0heObuKxfbWTYD250sFQxfMuhLqHwnLzoiex
7JkFxQgi/efIAkj/ckHgWsCyEkCAZgxokg+MyAEegiBMQjAaRilc03DklHO0xz30okY1UEFTIjpF
meOZJgi7cVNkIiZGQcWHjaiRG+BMY57UUM/HksqwGY5nRUFV6C+KutWstiWo26ApOXuKCqJm1XVJ
bNl4wNS7WQrPGmDqZdNuyh/KrBFJ71jTYsZjqPHwR6z4GM07+FdUPs2Oqr2JKlTdkw/EQPOOvckr
de76uKW+Y4072SuKnFJWwx0GNH7NqS+N+M7EnMWyTR3PTxPLWHYc9avjSc5sjFjYQV2FH4mMVkNI
ysCGZCtZAiJAAQy0AAZS0lvDxVDgFhDBJpzKCH0xSi22ApUidAIK/9eNxXMxcpfsnsRW3NluSoqm
BytxwiT5gIp342iErdyFutA1CcLGOwvylsu+0MVvfGsR3fyuq2i7sO5jxCtemXzQvutNCXbPUSrr
vte8reCpfjUJYbF05ML2ha+F84Ff71I3HIh4RhysVQyJLKBDzZgDig3RXI9MYTGHQa+Ln+CXGdsY
DIuR8Y2x0B+PiEAZQA6ykO/AJB0bYchITrIcFNAsJTs5yDvOgieiTGUt/BgTzLhElp9siS0X48R6
C7KXtZxiMSNgzGM2hIjn4OU1TyTMSXYzi1NRXezWeRBGhgkYaHNn66q3zyaUQp4DrQmeArrQTbgy
HB5yCAMmwtFcbv+0if13AEkKudJAxnSQfwtpSN/hIct19HIN0EAlg/qBiDiCP0grhZtoQTNLWJFO
qLATLYQqiSVhWBJm0oRaxxQmu3tCOXitSQYcS9KX8HSkM23pIGsaE89WRrQDNOk7BMUOyqZDtoF8
bUscwXeEaAkrk+BrJpT7CucuwjpIQmwstHvcUHhfoo29aAqJtECWJhBxC7DAZAyoQAcqAIfs1u9H
ChxDzoJDwkccoQSSesQLGoAkLYShBBQgxRlS1sQbfm9+N4jj1xJusx+ZoH0T6OKPLJBHi8FASTpr
4P82EG9XqiEKEcAYG5p4xCVEIQedWOASt9syJKTvBBT95SjHULX/Ir5Se9+bQxOqEEsFnvSij0sy
siGNaVqTGhY9JRtb7Q/pyDkfF1ZmbVWqTUOXovbupOUvZV9OpwqZNb7KvSDKGWJYq8GW3FhDI4ep
HPjsXh53WWUyilHKXlrmGsw00ysjeY7d10NFvnCiHE7VE3rgHrqnKtMasuE8a3RD75SfWebaIqnR
CYAsZT3kWXXD0AJkr9KLQ2j2BnBWQ4i7Ujk0sKV761YcstUsbWVrWxE5KUkPiOnfe9RbHZpWcZu1
8ptfa+SlrlvQq3/moMfh5seXPe2VdfGKR0T12Tp9t4xfLW9ZC1sCesjyRd1I8jurWeJ/fe6z9f5m
ydzk14IAFJF//60nUqhmJ7c0J2KCgGQCAWJkI76SMFfxJEPyJK7VCUJyH+QRKEg1PeEwPvSyGP6g
FRSYK5P1OEnSLpziUCHzJhbUTIXRFAXlgIJya0dUK4dCHCqyJ9pwJqhSRK7CQvyQOyg4gSyIFCxk
ODxoMFkyIyuoOLQSK/TigzE0QsfSe7NXaYwmSR2lW3vTIHDDEJZmINqCQLJ3cwzHSAfEcovmUrUn
Ug+hEJWGAKx3N1gIfnXIEMuXhUt2YtoHB5W2hye1DHnofin3PxoHLXdYSYwGOClFLQi0LXIThsPX
SF4YN3lDiT8RFH7zc5LEN3gDhog4LhyjRIajMlCUJlIEDkBTVv//oEsUUzIWmISziA2vZCXZNChg
xycnSEN3VE/npIs3gRU6k0opY4y+KDNWsjWr1DFsAzpbww/WsIsJdU/EsxVJ+DvgdVAj0w3qokc2
9IxWSGkDUI4SF21diEDXFoYGFBFBQRGq120/AUDF8EBz+IjFZTdyGC7mSCGaFhHZYo4RYY8jp2/P
EhT3CIjN5iHrOIqYplKWplL96IaQCI8JInBCh0Dp2JCOtIYKVCClBopreEAdyVznY4q/gzmdhBQw
JkSkcx7WMxWjwzuU1TRRgjlSVESuIZN9xDS+iEbzcz1t9Q5ZREHOw4rccTRwZUS2MzlFNDyJ4R7t
okfWmA7ZaJT/TIg6PZlQNrQ/U3SFlqYh+TaKjlSG3gItBnRzZfgTF8JoAZSHi1SPCklJ01eG+/gT
27KIeNkhBMlwyUCPCSlSC/lA69cMZ+lID1lJEamYy4BA+ohAaEiSJiZAl0gthqmJD8SJlYRymCaS
ZomZpKhBKElBQUMboAd6MANGQzNGPnlGtciN/nJalddCTNmLNtg4fUSby8MWWLlOPIOUVfNE3tgx
XFRETzQNuUEN/1RISuNL3AQ67NONv/CNXNk6xfmV/kNSzeBRy0eHZHmJklQ3b3gtuKd79VZt37Jy
3TaJyWAgdAkhjLaPXwiH1xJ91KIhcdgMpfaWCRSXnamfI6ct/+63cuLphYm5fAGoneBCl55JN5So
hulIoJbomJrZe8AnkhI6ioIjUKOZThZ1MDqYM2nyTlzxG1X4JtbkNK5IPHolTsOSPiZaL/lEHcN2
m/h0GHAyR2KXD0vCKOZRUD/6kwA1IwaFFDnagxhVRAYFYzaiHj9JQx0EAdnkI4LyVNGpLyYIjqgz
UWGhaMVVUqTGQIuWIMaQjvBIIenZLQxUagiiIIS5npPIQM2wnnTIQKeWQMZwfXAgnyf3LfqGhn1a
cy3ne3bKeggZniBZkHaacgKXDIjJhd0SpmgoqY4ZN8YVXBdSLfT3nYyaphSKp8jVll96po2qocxF
VvlUGm9VU/9G9FMlBDOIpVNSFVQu6SlX9VWXw1n5gSI06FeLVRM09VPWyFr80BS+ehNBVUKI8UrL
SjvtoFmwlRTZsFadBVtCpSehRSW+kkQ2ClUzog9LNSKClZXtIx05MR4zVFvYqXDClwCTJnyJsGJv
Boh0Y49uKQfuegd6WG2WsGJGBwfEdWLwCmZ1MLB1IGfLEGbyiggGm692sLAkFmQLewgLW7EG+1Ia
xgn4lbFOUGAF9hwfu2HlghUV1l/nxV35QGFLgGEwUQv0sg0vmwrdRV7olWCKM2FOwLGExgtLoBlL
oz0Vpjgd4aXLhgcQQiA4F5mXsFxAhiALUodFG7VSO7VAFgj/rlZly6lHWCsMs+SkUUC0VDsHcxhA
/IoI/+pkRtdkYbu2bNu2gTBlW4sE1xS3wnC1ULAJuxBgQgtdgIZEYJC3OGsEnxC0W6C3WsAKnTC4
h8azMPExXICNcFu4gdtegwYgIwZnbftIZXYMmMu5dUBiZbtpSztkz5Bmn7stnXuwqZsHm6ASxLZU
ACFj17AYXhsGHWQenNRr16CrWzBsSbkF6TAN1XANk/tuXwFai9uz2xCut6oJtUsOudsEItgKezEH
F5K5jwSpiDBtC4FqctCZTwandRAuIwlklEkH9wotTKtwDzJyLNa64fW7WwQFPjJPlduxSZluSAAS
DZYF+msF//NgvL9Gbr1AhFNglSKCa3A0awe8SkbwEvg6XNibmMu2XNy7ttu2tN47B+K7vo55CSNU
RNQEHaMxPdLDF150EAjzXP5BGEMUWGSBHWwBFhczjZjnFPfhd3HyONBZQtAha2qhlHKRHusxFkIM
eKlRH3y3efAReFMjwilceJmHGjvcNqNQCt8hFVGaGLJhG3vVCyrBEiWkHIyhHFpcxHLBGUhcxYOi
HW7XJJO3UQppABIRc+5qaZUUB/8omAnickD3UX8zc/wGcCSnIA7XQAdgccD1cwPXpiA1YirHhYV8
cS9HXCRlyODij3KKLFlIyC93jgxkcfVGXHZ8sBHCIJdcfv89R2oVV6dB53Ozd8mVtnGG7CAH9yHw
W0SagkLn4SpcA1AJVQQycipLISU4glSdkCMhuCsiCA7FpCcm8nZ7wb/itIxSeCZnw4FNSCW+xIFt
0ysWpBjacM1nwiUDXCupwotGMiJ7kkLJQVHKNCa9wRWvxIFzsTmcVIOKwcw9siu3BILd7IHfHIwY
UQ6vdESo4iKWW1xGx2iwVyGc2GyaJoclRZ6yR56KpADm53rTd3/Bx2TNIoAgRYADYp7ft36fGFIe
VTe953yf6H+vl9IPjXskR1LFJ1IldXszjb7UZ4krx53YIqAAKXHo94gQkrYd3UD8Z4iCk8sjjIJa
czOvMhP/mRUxleNMMEI0BNU46MJT0ji/tXMNO+U4FlMzFLUkxpNH7yMzOgPWFdQfOTkxJHrO8CPV
VpyjqEijp4GKK1QyyhhsMmENOsXDWh1sS9HXXG2LeJFFL1EzNaOMO2q5y4cgeAqZhanHliafBySJ
2eKQ2ssQ3mmAa6hpqjefZ1mGdUOIbUiSEyfaqAuXHolzMu2FnE2JD2ogJZkQ9YqWrY1SeBrajvjb
GreHK0WXTV0LrltHP7k+o1U70xXZwNlKo5UmorPV8naS0DPNnxDM9yNMRog8M/Q+GUFBLyE512BD
/xDAp3UWzPM8KtleewI8hwQ+OElasuEJd5Evw8A+O1kl/zkh3utN1lb0DowVExAcQBRSqog5IN47
0YK5p5MMmhQM2oTpn2OY2f24hkPxE+BLUivnLL8XkOUYl3EDvo6UyrYtdAPphXTwjpbo4ZldqQJI
kJREQC5F4ZV93Eqsy3fUDmQ31b+bDrFk1YQ93apaQdatjXMk4FqrtSJUKMSREbH5SwXzmtmtxMaI
3gglwhlxRc9TH+UCSqSJCs0ji3Vt3/Kr3ySajQtT5olt5W49F58gb3F04AuKACd14gpSkDHu4JEp
4Z8dEbB9qKIN4Y3p4pWokAf0l/yGuqS2l7H94KC5nymelqD9wcdGmYwehzL+E8GtvhoX2jiekSFc
O71gP/89XlDmFJ1hjhXjcxU6MlSwggryFOt1JG8ceuXBrLXG5C7NGE7h/TsrquvapBFx7QlGdWEB
ftc4WqUeOk1xVSeC8qGwdE/hhOZGAD2BJW/1K1rndN3D7tZE+DDDEk2o4D+q3ZECt7m919kOjtpw
E56JWJaOmtKCWZ8BIkneuXKPvKftmdI3x5cnddr4Gekm7oXw/ph1g9G0DWf8boloCEA13n7uyXre
MuOSXu90aQyl7ilMZSupHq2ixWvtcR2y5R6VJ91Zh/Ksxas+blqGtSbEfkg8bK2N0QuLwVlWBfN7
xaxubVvuAfPEw1V0ffJ/5Vgxfw42ElQAA1e0cVb/kPP/a9Iew8BrT7NWpumABJ7GsWVb6cP0TP5O
d1En0PpZ7QCI3qstHZnakJwsmq0QYToh0bfIBLIsBrqmc6qQBGKO3SdwebqmDb6mKX1yDXQtwxWe
wvUtminpoxj32vLoCoEgZOrZ+Ar4imhzknSpv72mjAb43TcgiC+nDMpcm+RetjC5FlY0NhtT6yVe
HlZhOksKOkYLFlGylRuy6YVdAEaz+PWxrl+zFYb7SPD7KCuyUWH7VGCyJosJg7hkoZuw+ApnEctm
z+8MZxYHCPtInSuvHRJm7rq5WgZn1z98q8tkKrb98DqxI/auZeawy/D8ktTxjSDAdFv/9n8EhkBq
4I+9//wPAos4kqV5oql4KKr7wqlyLAHDBLm+873/A4M5xkNoPCKTyiWz6XxCo9Kd65CIYbPaLbfr
/YJdNkZYlGiV0yTEtYSInU8JBLocV8feWb25ruKLAOJxCboUqtxxJZosdi3GCR6eFNo05DQ44EA5
TD01aB4xWOrcpB3QDJYZEKAuHLwNxBQUKgwUtH0l0MymjryexGYFr7Se/A6LIPcKwxxn8cYYlECT
/FJ7nVbTKMcqSKso1zhE2FBEjD5RdDo9FCGN75Quz2td84bvFZgWL1974ae4R2+gCH+pAE57Y3BL
NhP4EOgDZyIAPHhS1K3L6MPiEDK+BhC4oqCArRYGDv+AnIMKwaldKAu0eGkA14IEBAZ8K7DKFyp9
NkvWvPltxE9pKEOuSIkTaNESM0/d3IVzgYGUrqoiOAkSwc03I0G+IsBqJlWrUFk5ZSq04EtXKX8i
1XcWVVWkZatqW1DgZZ2jCZbC1Ot2ajWrXwNrJcB1wJvEixUS08tXcNnAcHWl1HfYpF8SM7/aTTq1
6q1VBsj69bs34kgSe20V3Fn3yoECYmlkW5pT72ird8NRJBeBAoQh5GyQazCBeI7j7XYQN4dDOYUJ
DR5wCoA9AITq6LR3d0C9OMUJE9x1t679QQRNED4Nb29jOYTjHYmGPECAqrTTevef9hdbubn0lwII
MEb/AisKoMVYX6jEspdkCywo4QgLVsiCCCOxMIBLFLJgYUEsEXDgfvrpApN+rgRWgD62zaCPfwIG
OIt+M5xYIoLVwKQTiAxuU+BeQLK4QCw37libiSx6gwyBE244pIcTxjLAGaHZpAuA/Unj4n8x6vVi
ibUZGdmUEh7ZozRoKSklf296SeYINso1lJFXJvAXAggqMBIb+ZU45CxIHWAnThwaSYeSKyJ54jYG
IHpkfjBxxSReJQSnnXo5qPdAcecxcF4AGD2nAwVFRFCEqOx5yul1EzDgwAQ7sIcDqKkGMIEDDlBA
RHuyrgdBEcpxVxwExhYXgX1j+PLNNlcIaGEsitUy/8M2xBQqgmL4BaKPMg1FSAO0+y0AEbflvgiI
QK5YQa65c7IEIbpQ5tfTG9mY22e5R+6SFSqKgeuaV392Wya7er0hEpn8JkNvArwIyJPBDY048bVW
1lSNs3fWFOG9NJjLC77emlkyLwcu0AKYAmEc7RvvjkimviO03PC7Nm7Myyz+bUvzFeYGYyHA8ub2
M8kh//twwsBVtOyxue46a6akupMD1TbYUKs6wArrqg7PARscsRQFgGuu12FHTqsUWMKAOr1qt6w8
B9NcNzRHniTXtew2RM27QJcQsE1oITiA4RHNO689sBBT+OECBxyyHjbae7C5P5F08CzQUN4wvCP8
Tf+y5vfe5CXDZZJkOGN35xUMxQhbXKZ+17w+jMeWp4t77K5fSztIXrJs98uIIzzSgtUQwPrN8QqM
cJbcFBz05MzLvjfgIau+uh5Mk8NRAMo1sPVx8Fxtag7PPVCdsme3OhwF72e3HkXvvx+B9+7D347b
ZXNC//uj5sB7c2vINlR2uzL95SQH4122KMSHSs3rW/IymgHeNbNyuSt3n+OdBf3QuTJJTlvUExnI
9NEzhm1OD0PzXMXmAEHAja4WRqtew6BxBdZJjHfN02EszlCbVhDQSAaE3ciIWMLdmSxhf5ohy4bI
C5gVTwEJ2AlRYnSt5QVRZ28ggH9IEAwYQmOFNPz/4tE0eMPtTaRpPJjA08JGvvNVDYDrAV+mjqUr
/l2CVkWwyA0skgn75fE5qYIbRr4nRwF6JCgYnBCZfCSnm5SMXQZCECAwhqbASWNH2wIabQx1w37t
0EydhJy8zEUmAfXtYxGMCQpZ4pPTOcko0rDk3rIxCwiajm5pStkAZmAUJ9WyGOsqWomo0gqbLFJC
jVRlCItISyRmq1C4zF24ivRE4u2MBrXAD2dAGJFZILNSWiyLIKakQNe9UpcL/FAsTKmZXkazG7jI
lPe4Q4HssK1sRcin2awGx7CtTzlSY085QFGqfK7tBmwjqNuIUIQHTOA4uAIWruoTj0RSpSsdI8kN
/8ViFznlJjJH6VkgQFJMZfzFRUeyxbZegjHQmbQF11jFjg7mUpp8sJ2a8ShuKlfEVXDRSiipDR14
qs4RMIij+xJLC3RIU9twcT+wTBlUpZFUSOYwMiOgKQ8zahuarCJBKbUkM3P3U7FccoEpSx7GPCob
xfTQFmRN3IhSipatJg8pYlleRhP01JeFg6Un3ZBRA5abvDa1Y5Cq6lpto9MR0HNZ8/uaeWDFHfP0
U47PqSwEpGYO45iHPHA8nzkQGlrknPY54XNH+IbDCYFG9KJuqMOB0HDLOigwBbrQFk1qIokNAaK2
SKUDI35brt4C1w95QC4iaJKnNTC3BMI1g3HZcP9cGFgXdISIbrkOQdzkeuG5LphuufyQ3ZR99wUH
Qu6ehqvcQNThvA30Isomwd3hFjcQNJGEEFqlA0zsoAHfAUImgiCeIMQKFALewYERXOAhDJhZsgDE
Kt5LgloYwDYE2TCHO+zhD4M4xK4gad1EPBEgQDR+GllxJ+b2Ag354r4bOoWFTWzjG+M4xzouQ3tN
wA8bG1jFLB4yFG7QA1HEI8JENoKQEaxkIHxiyQaWsg+Q/L0m88DKQ9ayk5fMCS4nAcwQ3ggUFkyK
J1P5yGhWsxKw/AQkRxkJYjaCkXVQHO/VM81AKGQQ7ixZIQBSzzzgM5X9PL8/2zlTRM7zRhC9DnX/
lGoJkdajDwg9BNFWuTiTnrSgG01nTcfRCJbehHCwjGkdMFoIdfZnqjsdhVG7egmwHjKfOT1oRQ+5
1Qx2dEZsfQRf+3rUuoaHr2P9BF3rWdfC5jUQVt0d+0WUOQ3QNH14ANE7jqc56UuVeXAwSG5b1jmo
2ra3kcMcTUnn2dM2t3yE5Z0dvGfawzk1RE/1vc4eqzuiqPa02diDb/vTnpvqjrSXI596x1He50a4
Pc/xHvOUygFVe7as5n2+5cSRAcNRj8alw530cZw+yal22TqLavPYWz5lA0XH2w1yWd3ze8tRj9oS
PnNLfHs66kv4zmV+boykxxIYF/h3MM6eoT+H/+AZtzi6h1WfUz373sPx1GfXzR0BP70466YOet73
qVOpluQ53wE53K2r5XDC7DD/cnxwECrilN0S6Uv3Zxk+DokHMNRVVvA9eWUJtpGvf+hw26ty9QCN
7/Pw/sbVqUKVrH2ONuWQP1aoMsHPB4RvV2VHVtnUtiz7+Z3wpGAb+HjlbQjYSvHY6RUoTIV6xmuK
CLOqVagagKtUEZ6OAWQb4d0mHutkfhwMOFb4tP3fvueT96TfVNzAU6znr4+gwtI4OW61zwfPD/PW
6drYcvC0p60vArAi6B0JCuk4lp8ckoea29BveVUdHvYQlb2mXkV/ykocVsBqh3JiJTXvo56u+P9e
6ZFe41mH361W7VkE6CkfJlSfePQK7VkHRKGN4SHeqIwbdHRe2YyfcAhHBz7f98VfqTWUPmVe7h3g
OWBEZv3AqgHQAmreqFjCd/iX9p2P+jUHJzzHCuog5MnP1bwNDhzYDMIe+cygOgDS/cQgHp0PeQgL
DMpcE6ZaPr1RoHGczI3DsDjfx6GaREmcE0IesamK5bWe+OSgf3XNDY6BDJYDHpEPDrDH2LwRg0nN
E87K05hK2yBhD2ZK25if/PxX1uDgHNVh1YyNsMghDlqhAzIh84mhP/GfZX0H3IgHGqZNwIHecfAg
DHLiOUhNgU2Hrojh2PwhIPoTIIFNqcmPEbb/IdwQFCBNh/yBITwIINyoWhkqWiZqSqCNVgCNzyCi
og8Go2b54A7KkZ1Vh6iYYSHtIa7xDxSSFv1cohv+4hT6IgDhzz11nHn8Hq7M3ftUDQyWijE+oqcQ
lAaKo/9UjcaByqj4DzUekv34zyB2YeTpntW84zASW/3g4KbxIzFaRKQF5OrRjyL6TwxmY/w8IgAl
HXFMIqWth0VsoibmYCdWpP3IzcaJYs350SBOWjOmIh6FpP+8zTUCUnooo3aoI7EJC7ORAi5a5Cew
yte4A3Z8IjDyIQ/+YOTxJEZU4sGFofq5XTMqITQCoiVAoRth5A/4pCJmhyXgof0gZQQIC2vt/9oZ
guEL1tz3EEeomSH/lMp33EC/HSPOccIc3t1xGBmhWUTX2NGt5ZE+euJUMqQhqscctsNA1mNEqiUO
NKMhwUOgfcdCnt/3EIEtHtJ1zCJFPiNj6mJjXqQfDR956GJe3iQxaqBciuQe0ePfmaTEAWVd5hE8
hE8a3iI6euE49B8XXsKsAMvlydEw6uQO4lwxQh4gpUqrhEpQ6lPzJeHnLSEvyoq3TWOgXZ5FxJnV
FEHXQJom2t5r3ZMAqma4haMX9l/taSUgLkfrZSf/rGY/dc3+TNSs/GZvWhRCFQdb8t5dnpsOjOdm
BgdA9WM4Ss36AKHQxVE+KaPcpWfzKaDnzf8HOhDmepzjHeWgCcLKf2LiEm7irPieRbIe2wBS8G0l
bJbPKfJhYGaocOwReS5nqelmSg6nPi0gJZ6mDnBjapZdRDHfZcXctVnWbAojH3ZWRNkmAMFWOYjf
06QoVw6HWTrjY/LiZZlHLmYHjMaKF0IHi/rlfOzoodkoRInfclbWVeJRjaJerujKVjbfGm3pgdbo
//moqLRWzJUnbKlNtHkmHYaWJuRTgJUWJ2gmZ81KYaJoaNXpaMFoHO3pLiafk/pbaYbKkx5fVUKi
4mFWgFUpkaKeRF7kgmqp+AVnDF7bnZmDjbqNoSIpZpqPZmpmmb5WZZWacuzop8BKmCraOc7/WkfE
A/b1wK5sBDoAmCes2SXET4KRAvbhahTMKpQ1WYNZTazE6n+pGCYomJvxQK/uKrzp3bKeWZPFymCi
GZcZaxCYWRQOqxAAK4Gt2bUG2HdUKw8A66xuq60aWIT16pVtAnf6wLWm67siqxRE65kdma4WWLp6
n961ILsaW792mlf6KxB0Fr8GLJOxYMEibMIqbJoNrJwR7MJCbK9FrHbU6sR+j75abMZq7MbSSsW+
JMeCbMiK7MiSbMmaLBO44Mmq7MqybMu67MvK68PC7MzSbM3a7M0qbMri7M7ybM/67M+irMwC7dAS
bdEarcrq7NEq7dIybdMWbNI6bdRK7dRS/+2bCW3VYm3Wam3U6qwE7IDXAgHYBoHXiq0EmO3X8oDZ
qq3YCkHZrq0OgO3anm0AsK0P1C3coi3czm0OxO3b8u3Xym3Y7q3bsu3dBu7fhm3b9oDh6q3a4i3d
+i3d8u3bxm3aPq7kjm3aRu7dQm7hNm7eJm7nDq4TRK7dYi7g+i3hgu7lli3qHu7klm4SOC7r7u3p
/gDnrqHlPu7rGu7ski3inq7n6m7jUu7wIi7n4u7k3i7otu7xsu7lQu/z2u7iZi7wzq71bu7iym3t
Tm/vXm/wAq/10m7g1m3zTm/wpq70gq/zii/1Gu/Ytm7ysu/yDq/50u/5Iu/2yu/+ou7qXv+U+4Zv
++Zt5VauAOPv/XYv7Bbw+w4w9ZrvAwtw4b5u/f6t/gaw5vqu+kIwA5evAgOw8IouBg9u7YJwBH/w
7hLvBmOuCvsv+m4v+/6u6a6w6GawCE+w/kpw7Oou4aavBa/vD2cZd8Zw5zKv+xKwCbsu966u5wrv
C58v5AIu2qpw8z6wElfvDFdw/wIwFv8wD3vvDdtuB0MvFVPwBZdwF39w+iLx+rJwCn8vF2PxEFsu
BOdwEYev/C7BAmfx58qwC1tx7rYv45qxB6tu9MquHQNxGDMBGSPxBuOwFV/vAtuv/0qyBhuy4hpw
345uAYtxIityEl/y9xYy9kayAk/yII//8e46Lu6Wbymjchc/Mg1PcANbMuwi8imzagDL8SfT8i5P
wRDrMRzzMhJ0cB2rsitHQSWbsSBPsfoegRj3rRHjbTDz7hxf8hZfcR+38TNvMQhzMv6+sDKDMzLf
cRPgcCOPLxrvXR638Dd7cSTHsjVf8O2esw3PcgszMPP6cBKf7Sg/sQw3synbsw4XLDALLh6Trgbv
Mz9zb+m6MzHz8TwbQT3L8h8bsiivsRfvqz2/LzPvMQJD9PyaMh6TNDdnMzbnczmH7kpntDOj9Ehz
dExrb+wyMumCcRl7Mj7rtC47L0JL9DwLMku/9E5rcy3/swsyc1AT70dT9D9T8jAbcEgT/7VTU3VT
Gy8uw+9M6zM5v3RQK7VSv3Ix260Tc7AbjzAyW/VQL/M093Fbwy9ZV/Q7W/QykzVGR/RRtx5Yp7QU
X3NfY3JYL7Ja/3RVK4E3F/ZgIzb/ovQpn/EB7/VP+/JFS/YV+/Qjk208y/Nj+7RjD3Zlx7NeTzXu
MkAL8PNf/3VTp7Vbw3Vqt/NCU/RrLzRlx7by6u1JCzYrzzJcw/RYEzQHnzVvi/Js169wa0T+1rVw
o/Y+s/Zb33NotyBpb210S/d0G+1o1wB1Y3d2azfMWvd2e/d3gzfHdnd4k3d5m3esjfd5q/d6s/cU
jLcTa/Lo3rJAQzZV+/Vmi/BEV+9X2/92URuBAAC4AOgAgA94gBd4EBB4AAS4gSu4gB9Bgjd4gUM4
hPsAhR84ECx4hu9Ahlu4Eiz4hROxX/P2Ejc3Udv1Y9+3UI9zidc356Y3LUtxQ7u05AY3W/fvKtM3
Z4v4Uusyjuu4P39xP+94gnN4DhC5gx+5kSP5kit5kz+4g0d4lCd5g394lEs4g/dAh284lDt5lnO4
loO4Nsd2QO+0RW+zjBtx9tKzbv/4VcdvlUE3DJ8wQ89tNct5JzP2ZG/14TbxVb8yF+c5TmM4k0v5
klf5lCM6of83lCd6lW95l2M5lXu5EHw5pQv4hFc6gfuwYhu1LIcuK7u0HiMvUKu4Xp//MSNH9osb
NA1HryNjMArTOE579UzntkqL9CeLtQdHNWdb9ZEfOqEnupMH+6L7OoNP+aNbuYd/OZczAYFbuKM7
umbLeh5L8JyjbxQ/cTBD9myjdhkf8ZHFefe+8bhL76gfr4/Xsp238xKncgLzeCCvsZ4jAbQzOpYX
e6MbO7P/wK9feZgLu6Ev+xIse6TzgLNz+bCHeGdr9TET90STsEnvsFuD9GGH8LkLObhftwVru7i7
MnzD+i5XMSQ/vJ+PMVf3OU+Lc5BHtsDrO7Ij/BMkOZh3OaS3vMwPvMwjeMAXupOHPCL395DFdzgD
9Ij/vGV/NBsfPSmEe5qrcSc89Hxn/zut0/QbqzaMn3ZfUzFmTwHCD7ylbznOV3i9X7mGN7vO57yX
Y3q873rbjrnWJ/PQD7XRT7wco/oTv/htL3Zpf7y7I70WT/xU8zSsu3GnC/q8F7m/DzvOg/2+iz2y
z7zitzyVR3vYLzo77/rGr72J67etC74tc/w64Hm5J30uK7zD13U3v/mNX7zHqzglC73eNzaQD7R8
e73jd73kH/vtJ7u/F7zOEzymV/qk277ZDzraH37C6/j95jCL2zcQ1zPrQ79gOzM0Y3us80DK5PXP
l/WfZ7b2c7zGu73mQzVhb37z737aOz7lz7zw9/7Zpz/7L/76oz+x+z6z43zQ3/Pvrv/6IWcuCEiB
KAajiZ7pWq5o2b7uHM9unZLuojC5BAy2hMIbEfgr2mRLpg3XjD6lqhcxCr1ZjzOB9ytIgcdNL2oM
Npm76HWg7Waf4ba2mE51wcPLbN8Jc+RXRQNoIjiY2CdoxPXXhMPjk0dZaXmJmam5ydnp+QkaKjpK
Wmp6KiWJusra6voKGys7S1tLqmqbq7vL2+v7CxwcgCtcbHyMnKy8fNvD/AwdLT1NDUssFZQzckW4
nX2YOeQ4pEU5uKXdXYW4sqeG9sZnmpYXd2f/jh9v1x6mL/evnrx3ZQYKzBSHXz55awLe+0JwIUQ2
bszAizenosF9F+vwucbuD5SRLMD/lTz0TV0NcY7QKVFXbh3KloXu9ItoMyM9jmQeWpyYZg/DhhDJ
7Izy0+jGORwxSjyqBw9TnDp7OqWicapWOVcPOrWHjyhVnku3LiGK55pJlkp0xEzXtlwMGHJT4ljp
JO8UkyrubuFmVuzNsQH1afyJMyvGpAMZF6QatOziogYRI62M2ezXjQ4HXwXrz45gShdBR306mHFk
rJkjqu1bci4jlYQCjYMbO503wHzvzja09vc5skA5U04tNWdT5YoRH3V8NnQ/ywCP2+xM3PTYzVEV
ek7Y0ePTiVw/h5862vzjy6ddOzs5FzjfbuTWysUtf7hu/TSQ6O0fEmsPBcYHduNp/6feZFYRt153
UPm04GSV/KNYTgY2aBpoFU7YmGTRVaiaTgS6o9UaPCiwwF9x9aZbbfDN15tdetFlzm/GiNahVRce
ViB59MAD3WZhCUUQdaetdqBkQg2FVo7nCdTkktwtx1prnCSFXEQXTtcjCgygWFMS2iDC30y8vbUX
mVmsRCYLjKhp5kvZkdeeFCQOSKWWxRUZWnN0kiZdYX1KV+eVe0bHpXcLbSced1LaOaiihuqJyY/y
fJkimpeMdCaMe0ES5iOe+IUNopBeImiTN4nF6qCJ/VmVn12tap1nBSnUaoOodgmejl3OasmWDvZE
omBD4srrpWBqGpJ+pLa4WzZ4Uf8x3LOQ2OhpgIUyumujjqkqYj6L9rpUhkNNGSuhtgLLFbm6cqsc
lQjulF6V65qqWYk+GpdluAFgGic3pDqrBZyfenqwigJTy/BJXsWb6JJPcrloow5SVK6VTNVLa5JG
4luex792S5iHHD8G3sPwOjTkvcoBTO1s2iqsCZs0/RfzzdGm9N/MEM/JypYsK1mWpNd5+HPI77p8
mdGFOo1echlNDfSwD+ar2Z3lwVxN115/DXbY0XAtdtlmn4122qSQrXbbbr8Nd9psx0133XbfLczc
eO/Nd99+r71stAjjDG3CMOU2U+GFv6mwf40j7NuKKs7Y6X4z7uf44SesCRPPirj/ia3DNeqs+Hyc
s1R6zz6nrjl8L30uKi1cDxwmYM6GHheNMiVOuIvZJuybpprzZq3D9eWl+/HbyGAbXc/WZzuoB7Ml
p/Cmx05C7tLzPnj38Qn+O4vGQz55964wMEn4JJFfquj2bS4+bPG/Ja31zb+ouB/KF5+E49+4Jb/d
yQ+A9nkeOuRTsOltr2Dr856Y4pO9hcVPf4f7nuXGFxy78AyBvTtf+sCnuwu67wm4K+AET1iI462O
gOIAh/8kSD/QbRCDLoJefkyIGwP+bobzQ94CrfAD0Z0OgQSMCfU+1UDahG9362tgEmeBvhh2Dmdl
cuBu1pG55KkOiE8UYRd9WJfM/1kieuLTYhnr17/OZTFOWwxii2A3xvwxgRxFQN0Ns8UmIRqxEf6D
0f9qFyoopo9xU4ScGH+InyIisYMAstG0mnczC6LEep3Aix3L6ELLVbGQcVReD3f2OgFS0Ydm9IYA
N5lJPy4OEM1inxpRGYooNoyGrAtY9WgEwFZ+EpSwpKQMK3et1dkSjnuEjQUVyUs/ilFNdOwZI6fg
yVI185Ss3CAzmXc5Z+5SeNFsXStkqT7QUa6XNXGe9FSYhy8ukHQj3FnsKkFMDJrzevwJYQedGM5G
hvJ9v/zjNNGJQsMxEVo6FCU/uWezXIAzme7E4ori2chUMtSUVCwhIlf5TCWiie1TLYGoG+FHn1cK
jAvxtKQv04Q4ac7RoW9c4ztDGghm7ZOhtwnYQWGxUP7V0p7tVKn5AvnTzVHwpZIkKvCAyroqIhOk
PX1pLefYpvYJFKlMpeo903lRQDbVmzz1YP+qt1VvDhOrY3VqgLLIUeKdaYXA9B0fXyec0G01rWBN
Klk54VFf5tV89cyqEeXKSHKCYqF/K6xhD4vYJRA2sYxtrGPrttjHSnaylPVaZCuL2cxqNm8f3Kxn
PwtaQYZ2tKQtbSnQh9rUqna1rG2ta18L29jKdra0ra1tb4vb3Op2t7ztrW9/C9zgCne4xP1tCAAA
Ow==
--bcaec51dd641d0c11d04feb88eea--


From nobody Mon Jul 21 11:56:45 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BA41A032A for ; Mon, 21 Jul 2014 11:56:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIk3mQkl6iDb for ; Mon, 21 Jul 2014 11:56:39 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C37A11A026F for ; Mon, 21 Jul 2014 11:56:30 -0700 (PDT)
Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s6LIuQ8h012426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Jul 2014 13:56:27 -0500 (CDT)
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s6LIuPpg025187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Jul 2014 14:56:25 -0400
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Mon, 21 Jul 2014 14:56:25 -0400
From: "Makaraju, Maridi Raju (Raju)" 
To: "kiran.guduru@samsung.com" , Justin Uberti , franklin blek 
Thread-Topic: [rtcweb] New Version Notification for draft-guduru-rtcweb-codec-preferences-01.txt
Thread-Index: AQHPpJo4FyolNSJL+EudWqaZ2lX2RpuqcssA
Date: Mon, 21 Jul 2014 18:56:24 +0000
Message-ID: 
References: <38.D7.22787.2939CC35@epcpsbgx2.samsung.com>
In-Reply-To: <38.D7.22787.2939CC35@epcpsbgx2.samsung.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.17]
Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E48C2E7US70UWXCHMBA02z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nDlnYU3kAZ7I-sJsD5vbWJM1vos
Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" 
Subject: Re: [rtcweb] New Version Notification for draft-guduru-rtcweb-codec-preferences-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 21 Jul 2014 18:56:42 -0000

--_000_E1FE4C082A89A246A11D7F32A95A17828E48C2E7US70UWXCHMBA02z_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>This seems like a pretty big hammer to solve a fairly small problem. This =
proposal adds 6 new API points for the purpose of >changing the order of co=
decs in createOffer, which seems like a high cost-benefit ratio. And while =
the use cases listed here are >helpful, they seem somewhat contrived to me,=
 since it seems unlikely that the application can make better choices about=
 >bandwidth >or power consumption than the browser.



[Raju] Per my understanding, the main object of this draft can be achieved =
with no additional APIs and with just the proposed introduction of preferre=
dAudioCodecs and preferredVideoCodecs options to RTCOfferAnswerOptions cons=
traint of createOffer()/createAnswer().

So, IMO I don't think getCodecPreferences()/setCodecPreferences() add much =
value, so can be delayed or dropped.



The need for getSupportedAudioCodecs()/getSupportedVideoCodecs() in 1.0 can=
 be questionable as the application can specify codecs order per known code=
cs (or get the list via a dummy createOffer() call).



The draft talks about fulfilling A5 in [I-D.ietf-rtcweb-use-cases-and-requi=
rements], but I do not see any explicit mention of how codecs can be remove=
d? preferredAudio/VideoCodecs constraint only specifies the order of prefer=
ence. Don't you need another constraint to exclude specified codecs? It's p=
robably a bad design to have codecs not in the preferred list be removed au=
tomatically.



BR

Raju





--_000_E1FE4C082A89A246A11D7F32A95A17828E48C2E7US70UWXCHMBA02z_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable





Samsung Enterprise Portal mySingle






>This seems like a pretty big hammer to solve a fairly small problem. T=
his proposal adds 6 new API points for the purpose of >changing
 the order of codecs in createOffer, which seems like a high cost-benefit r=
atio. And while the use cases listed here are >helpful, they seem somewh=
at contrived to me, since it seems unlikely that the application can make b=
etter choices about >bandwidth >or
 power consumption than the browser. 


 


[Raju] Per my understanding, the main object of this draft c=
an be achieved with no additional APIs and with just the proposed introduct=
ion of preferredAudioCodecs and preferredVideoCodecs options to RTCOfferAns=
werOptions constraint of createOffer()/createAnswer(). 

So, IMO I don’t think getCodecPreferences()/setCodecPr=
eferences() add much value, so can be delayed or dropped.=



 


The need for getSupportedAudioCodecs()/getSupportedVideoCode=
cs() in 1.0 can be questionable as the application can specify codecs order=
 per known codecs (or get the list via a dummy createOffer() call). 


 


The draft talks about fulfilling A5 in [I-D.ietf-rtcweb-use-=
cases-and-requirements], but I do not see any explicit mention of how codec=
s can be removed? preferredAudio/VideoCodecs constraint only specifies the =
order of preference. Don’t you need another constraint to exclude spe=
cified codecs? It’s probably a bad design to have codecs not in the p=
referred list be removed automatically.


 


BR


Raju


 


 






--_000_E1FE4C082A89A246A11D7F32A95A17828E48C2E7US70UWXCHMBA02z_--


From nobody Mon Jul 21 13:29:14 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A581A0373 for ; Mon, 21 Jul 2014 13:29:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 6BLnK2GKq3UE for ; Mon, 21 Jul 2014 13:29:10 -0700 (PDT)
Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E383C1A01DC for ; Mon, 21 Jul 2014 13:29:09 -0700 (PDT)
Received: by mail-vc0-f176.google.com with SMTP id id10so8477845vcb.21 for ; Mon, 21 Jul 2014 13:29:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2sr8IMT6ne45PO28QrRFn3XL2jMlavRYiwha2OemC28=; b=o1VR8jHkTA/QUbnPAlNd5YgDmtVv3HmVs/ONSxf0Kd/wOSFCAfNBf0C31ko9LS7FE3 jhHZRDPhKAyKO0nf95f4ZrE1xDbC0A5hLSl/VaGqZI88bu7De/1Nbp0c7jA3oFJzf1rf 8q4Ls6tGr+KR4ULlCkv2a3otNwe553te+T+xhN2zb92YkBteG2k2iO7MwKwE6tcTDNZE EuKDisAn4jNsHMn3eJsXNgk4wHvDSjPxFYWRx8yG3MH6Jy3xQGwAcA9i6rRKtMcATuTD ve0T6l5jcV+80HxdZc+jwZZtgjHpqFBKg+3+JmV6An8EdJVkjidiRhvylLGGVbZZo9C1 gmpg==
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:content-type; bh=2sr8IMT6ne45PO28QrRFn3XL2jMlavRYiwha2OemC28=; b=Z4jrfspmRyRK/MxPpg8mvrTJGzVrzUp58PJV3RLROSq9UM5fRj4DRzyEuE+QHXlyoi Th8gMSosxNDsXO2Rn0wEZ90JbCQ+XS0VHZugWByJ1OSCnnsiX9hUu1clPkqq+h+vG1Vw ybw1aG9Syillvrq9QFY/i7aIRyYgk4dQx/L/qpRmkwWdJ/3tMxyjwqLlpe/fBTQNoXdw YbJePESEId4GQIyAmoJ2L7iXNoRr+F+tt7eiRKCF5teU7ZPZGECp2TDAADI3Ho4SlQDM 6G0J1aN/HB+zEyseMHvUxwtmyZ38y+jv6uQi4ec1Cmo6zu+zHREvUsLFMPUbzaxzRQ+r MffA==
X-Gm-Message-State: ALoCoQkN+qEQ/ojZ/n5xCLbY8aNsp+AlNFwzm5Umt1QhRanW/BEFRbnriQeHrcnIW+VlUep9XwNy
X-Received: by 10.52.249.83 with SMTP id ys19mr6691468vdc.77.1405974548668; Mon, 21 Jul 2014 13:29:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.66.242 with HTTP; Mon, 21 Jul 2014 13:28:48 -0700 (PDT)
In-Reply-To: <53C96838.6020507@alum.mit.edu>
References: <53C96838.6020507@alum.mit.edu>
From: Justin Uberti 
Date: Mon, 21 Jul 2014 16:28:48 -0400
Message-ID: 
To: Paul Kyzivat 
Content-Type: multipart/alternative; boundary=089e0149cdd689803604feb9f591
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lu73bvYaDLNIclB9cXxrIcBObx8
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 21 Jul 2014 20:29:12 -0000

--089e0149cdd689803604feb9f591
Content-Type: text/plain; charset=UTF-8

Thanks for the review. Comments inline.

On Fri, Jul 18, 2014 at 2:32 PM, Paul Kyzivat  wrote:

> I just did my first thorough read-through of JSEP in quite some time. I
> came away with a number of concerns:
>
> Section 1.1:
>
> When describing offers, modification by the application is mentioned:
>
>    JSEP's handling of session descriptions is simple and
>    straightforward.  Whenever an offer/answer exchange is needed, the
>    initiating side creates an offer by calling a createOffer() API.  The
>    application *optionally modifies that offer*, and then uses it to set
>    up its local config via the setLocalDescription() API.
>
> but when describing answers it is not:
>
>    When the call is accepted, the callee uses the createAnswer() API to
>    generate an appropriate answer, applies it using
>    setLocalDescription(), and sends the answer back to the initiator
>    over the signaling channel.  When the offerer gets that answer, it
>    installs it using setRemoteDescription(), and initial setup is
>    complete.
>
> And Section 6 only talks about changing offers, not answers. It is equally
> important to be able to modify answers. (More on this in later comment on
> section 6.)
>

Agreed. This was simply an oversight.

>
> Section 4.1.4:
>
>    The only difference between a provisional and final answer is that
>    the final answer results in the freeing of any unused resources that
>    were allocated as a result of the offer.  As such, the application
>    can use some discretion on whether an answer should be applied as
>    provisional or final, and can change the type of the session
>    description as needed.  For example, in a serial forking scenario, an
>    application may receive multiple "final" answers, one from each
>    remote endpoint.  The application could choose to accept the initial
>    answers as provisional answers, and only apply an answer as final
>    when it receives one that meets its criteria (e.g. a live user
>    instead of voicemail).
>
> Issue: in this forking case, until the final selection is made it is
> unclear which one will need ICE completed. Only when a setlocal is done on
> one of the answers will ICE begin to be performed. Then, if another answer
> is provisionally set, won't that stop ICE for the prior one? And won't it
> require new candidates? What if one of the earlier ones is eventually
> chosen as final?
>

Yes. This will be discussed in the setRemoteDescription handling section,
when it is written. Basically, ICE will be performed with the current
answer, and may complete. If another answer is set, that will cause all
current remote ICE candidates to be discarded, breaking any existing
connections; ICE will resume using any candidates supplied in the new
answer (or after the fact in addIceCandidate).


> And what if ICE completes for one of the candidates? Can't media start to
> flow? Then what if a different candidate is set as the final answer?
>

Yes. This is an application problem to resolve.

>
> Section 4.1.4.1:
>
> I question the following:
>
>    ...  While it is good practice to send an immediate
>    response to an "offer", in order to warm up the session transport and
>    prevent media clipping, the preferred handling for a web application
>    would be to create and send an "inactive" final answer immediately
>    after receiving the offer.  Later, when the called user actually
>    accepts the call, the application can create a new "sendrecv" offer
>    to update the previous offer/answer pair and start the media flow.
>
> This is very unfriendly when receiving calls that might be forked. By
> immediately "answering" a call before knowing if the user will accept it,
> you preempt the possibility that it will be answered on some other fork.
>
> For instance, if a call could come to your browser, or be sent to an
> answering service, and your broswer is on but you aren't present to accept
> the call, then the call will be accepted and then dropped rather than sent
> to the answering machine.


> So this technique should not be used if there is any possibility that the
> request could be coming from a source that might try other possibilities.
>

Agreed. But if you are building an application from scratch, I think it
would be better to use a separate PeerConnection for each remote endpoint,
so that you can use this technique without any downsides.

>
> Section 5.2.1:
>
>    When createOffer is called for the first time, the result is known as
>    the initial offer.
>
> By this definition, if a peer connection initially *received* an offer and
> sent an answer, and then it later sends an offer then that offer would be
> considered an initial offer.
>
> I think perhaps what is intended is:
>
>    When createOffer is called before setLocal has been called with
>    an offer,  the result is known as the initial offer.
>

OK. Will clarify.

>
> The following doesn't support the "balanced" BUNDLE policy:
>
>    Once all m= sections have been generated, a session-level "a=group"
>    attribute MUST be added as specified in [RFC5888].  This attribute
>    MUST have semantics "BUNDLE", and MUST include the mid identifiers of
>    each m= section.  The effect of this is that the browser offers all
>    m= sections as one BUNDLE group.  However, whether the m= sections
>    are bundle-only or not depends on the BUNDLE policy.
>

Not sure what you mean; the BUNDLE policy controls the use of bundle-only,
as described here, so I don't see an issue.

>
> Section 5.2.2 says:
>
>    o  If any MediaStreamTracks have been added, and there exist recvonly
>       m= sections of the appropriate media type with no associated
>       MediaStreamTracks, or rejected m= sections of any media type,
>       those m= sections MUST be recycled, and a local MediaStreamTrack
>       associated with these recycled m= sections until all such existing
>       m= sections have been used.  This includes any recvonly or
>       rejected m= sections created by the preceding paragraph.
>
> This fails to say anything about codec compatibility. SDP O/A requires the
> answer to be a subset of the offer in terms of PT/codec configuration. You
> should not use the same m-line unless there is a desire to use the same
> settings for the new track as are currently in use in the other direction.
>

OK. This is an open issue (https://github.com/rtcweb-wg/jsep/issues/21) and
we were waiting for someone to point out a specific problem here. Would you
mind coming up with a specific example to illustrate the issue?

>
> Section 5.3.1:
>
>    When createAnswer is called for the first time after a remote
>    description has been provided, the result is known as the initial
>    answer.
>
> By this definition, if a peer connection initially sent an offer and
> received an answer, and then it later receives an offer then the answer to
> that first *received* offer would be considered an Initial Answer.
>
> I think perhaps what is intended is:
>
>    When createAnswer is called before setLocal has been called with
>    an offer,  the result is known as the initial answer.
>

As above.

>
> When specifying the mapping of local tracks to m-lines in a received
> offer, there is again no discussion of codec compatibility. It is quite
> possible that the m-line chosen by the algorithm in this section won't have
> compatible codec attributes, but some other m-line will.
>

As above.

>
> Sections 5.3.2, 5.3.3, and 5.4-5.7:
>
> Are these empty because the content is yet to be written?
>

Yes.

>
> Section 6:
>
> Other likely changes are addition of extra attributes and maybe other
> parameters. For instance, CLUE will want to add another grouping construct.
>

Would these things be changed prior to setLocalDescription? The browser
won't act on them, so I would think they could be added after the fact.

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

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


Thanks for the review. Comments=
 inline.

On Fri, Jul 18, 2014 at 2:32 PM,=
 Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:



I just did my first thorough read-through of JSEP in quite=
 some time. I came away with a number of concerns:





Section 1.1:



When describing offers, modification by the application is mentioned:



=C2=A0 =C2=A0JSEP's handling of session descriptions is simple and

=C2=A0 =C2=A0straightforward. =C2=A0Whenever an offer/answer exchange is ne=
eded, the

=C2=A0 =C2=A0initiating side creates an offer by calling a createOffer() AP=
I. =C2=A0The

=C2=A0 =C2=A0application *optionally modifies that offer*, and then uses it=
 to set

=C2=A0 =C2=A0up its local config via the setLocalDescription() API.



but when describing answers it is not:



=C2=A0 =C2=A0When the call is accepted, the callee uses the createAnswer() =
API to

=C2=A0 =C2=A0generate an appropriate answer, applies it using

=C2=A0 =C2=A0setLocalDescription(), and sends the answer back to the initia=
tor

=C2=A0 =C2=A0over the signaling channel. =C2=A0When the offerer gets that a=
nswer, it

=C2=A0 =C2=A0installs it using setRemoteDescription(), and initial setup is=


=C2=A0 =C2=A0complete.



And Section 6 only talks about changing offers, not answers. It is equally =
important to be able to modify answers. (More on this in later comment on s=
ection 6.)

Agreed. This was simply an o=
versight.=C2=A0






Section 4.1.4:



=C2=A0 =C2=A0The only difference between a provisional and final answer is =
that

=C2=A0 =C2=A0the final answer results in the freeing of any unused resource=
s that

=C2=A0 =C2=A0were allocated as a result of the offer. =C2=A0As such, the ap=
plication

=C2=A0 =C2=A0can use some discretion on whether an answer should be applied=
 as

=C2=A0 =C2=A0provisional or final, and can change the type of the session
=C2=A0 =C2=A0description as needed. =C2=A0For example, in a serial forking =
scenario, an

=C2=A0 =C2=A0application may receive multiple "final" answers, on=
e from each

=C2=A0 =C2=A0remote endpoint. =C2=A0The application could choose to accept =
the initial

=C2=A0 =C2=A0answers as provisional answers, and only apply an answer as fi=
nal

=C2=A0 =C2=A0when it receives one that meets its criteria (e.g. a live user=


=C2=A0 =C2=A0instead of voicemail).



Issue: in this forking case, until the final selection is made it is unclea=
r which one will need ICE completed. Only when a setlocal is done on one of=
 the answers will ICE begin to be performed. Then, if another answer is pro=
visionally set, won't that stop ICE for the prior one? And won't it=
 require new candidates? What if one of the earlier ones is eventually chos=
en as final?




Yes. This will be discussed in the setRemo=
teDescription handling section, when it is written. Basically, ICE will be =
performed with the current answer, and may complete. If another answer is s=
et, that will cause all current remote ICE candidates to be discarded, brea=
king any existing connections; ICE will resume using any candidates supplie=
d in the new answer (or after the fact in addIceCandidate).=C2=A0







And what if ICE completes for one of the candidates? Can't media start =
to flow? Then what if a different candidate is set as the final answer?
=


Yes. This is an application problem to res=
olve.=C2=A0






Section 4.1.4.1:



I question the following:



=C2=A0 =C2=A0... =C2=A0While it is good practice to send an immediate

=C2=A0 =C2=A0response to an "offer", in order to warm up the sess=
ion transport and

=C2=A0 =C2=A0prevent media clipping, the preferred handling for a web appli=
cation

=C2=A0 =C2=A0would be to create and send an "inactive" final answ=
er immediately

=C2=A0 =C2=A0after receiving the offer. =C2=A0Later, when the called user a=
ctually

=C2=A0 =C2=A0accepts the call, the application can create a new "sendr=
ecv" offer

=C2=A0 =C2=A0to update the previous offer/answer pair and start the media f=
low.



This is very unfriendly when receiving calls that might be forked. By immed=
iately "answering" a call before knowing if the user will accept =
it, you preempt the possibility that it will be answered on some other fork=
.





For instance, if a call could come to your browser, or be sent to an answer=
ing service, and your broswer is on but you aren't present to accept th=
e call, then the call will be accepted and then dropped rather than sent to=
 the answering machine.






So this technique should not be used if there is any possibility that the r=
equest could be coming from a source that might try other possibilities.

Agreed. But if you are building an applic=
ation from scratch, I think it would be better to use a separate PeerConnec=
tion for each remote endpoint, so that you can use this technique without a=
ny downsides.=C2=A0






Section 5.2.1:



=C2=A0 =C2=A0When createOffer is called for the first time, the result is k=
nown as

=C2=A0 =C2=A0the initial offer.



By this definition, if a peer connection initially *received* an offer and =
sent an answer, and then it later sends an offer then that offer would be c=
onsidered an initial offer.



I think perhaps what is intended is:



=C2=A0 =C2=A0When createOffer is called before setLocal has been called wit=
h

=C2=A0 =C2=A0an offer, =C2=A0the result is known as the initial offer.
<=
/blockquote>

OK. Will clarify.=C2=A0





The following doesn't support the "balanced" BUNDLE policy:


=C2=A0 =C2=A0Once all m=3D sections have been generated, a session-level &q=
uot;a=3Dgroup"

=C2=A0 =C2=A0attribute MUST be added as specified in [RFC5888]. =C2=A0This =
attribute

=C2=A0 =C2=A0MUST have semantics "BUNDLE", and MUST include the m=
id identifiers of

=C2=A0 =C2=A0each m=3D section. =C2=A0The effect of this is that the browse=
r offers all

=C2=A0 =C2=A0m=3D sections as one BUNDLE group. =C2=A0However, whether the =
m=3D sections

=C2=A0 =C2=A0are bundle-only or not depends on the BUNDLE policy.

Not sure what you mean; the BUNDLE policy contro=
ls the use of bundle-only, as described here, so I don't see an issue.=
=C2=A0






Section 5.2.2 says:



=C2=A0 =C2=A0o =C2=A0If any MediaStreamTracks have been added, and there ex=
ist recvonly

=C2=A0 =C2=A0 =C2=A0 m=3D sections of the appropriate media type with no as=
sociated

=C2=A0 =C2=A0 =C2=A0 MediaStreamTracks, or rejected m=3D sections of any me=
dia type,

=C2=A0 =C2=A0 =C2=A0 those m=3D sections MUST be recycled, and a local Medi=
aStreamTrack

=C2=A0 =C2=A0 =C2=A0 associated with these recycled m=3D sections until all=
 such existing

=C2=A0 =C2=A0 =C2=A0 m=3D sections have been used. =C2=A0This includes any =
recvonly or

=C2=A0 =C2=A0 =C2=A0 rejected m=3D sections created by the preceding paragr=
aph.



This fails to say anything about codec compatibility. SDP O/A requires the =
answer to be a subset of the offer in terms of PT/codec configuration. You =
should not use the same m-line unless there is a desire to use the same set=
tings for the new track as are currently in use in the other direction.




OK. This is an open issue (https://github.com/rtcweb-wg/jsep/=
issues/21) and we were waiting for someone to point out a specific prob=
lem here. Would you mind coming up with a specific example to illustrate th=
e issue?






Section 5.3.1:



=C2=A0 =C2=A0When createAnswer is called for the first time after a remote<=
br>
=C2=A0 =C2=A0description has been provided, the result is known as the init=
ial

=C2=A0 =C2=A0answer.



By this definition, if a peer connection initially sent an offer and receiv=
ed an answer, and then it later receives an offer then the answer to that f=
irst *received* offer would be considered an Initial Answer.



I think perhaps what is intended is:



=C2=A0 =C2=A0When createAnswer is called before setLocal has been called wi=
th

=C2=A0 =C2=A0an offer, =C2=A0the result is known as the initial answer.
=


As above.=C2=A0





When specifying the mapping of local tracks to m-lines in a received offer,=
 there is again no discussion of codec compatibility. It is quite possible =
that the m-line chosen by the algorithm in this section won't have comp=
atible codec attributes, but some other m-line will.




As above.=C2=A0



Sections 5.3.2, 5.3.3, and 5.4-5.7:



Are these empty because the content is yet to be written?
<=
div>
Yes.=C2=A0





Section 6:



Other likely changes are addition of extra attributes and maybe other param=
eters. For instance, CLUE will want to add another grouping construct.
<=
/blockquote>

Would these things be changed prior to setL=
ocalDescription? The browser won't act on them, so I would think they c=
ould be added after the fact.=C2=A0






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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul



_______________________________________________

rtcweb mailing list

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





--089e0149cdd689803604feb9f591--


From nobody Mon Jul 21 16:21:48 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1019C1A0085 for ; Mon, 21 Jul 2014 16:21:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.579
X-Spam-Level: 
X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMEfntTGRs5W for ; Mon, 21 Jul 2014 16:21:45 -0700 (PDT)
Received: from mail-wi0-f173.google.com (na3sys009aog106.obsmtp.com [74.125.149.77]) by ietfa.amsl.com (Postfix) with SMTP id 073B41A0188 for ; Mon, 21 Jul 2014 16:21:44 -0700 (PDT)
Received: from mail-wi0-f173.google.com ([209.85.212.173]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKU82giLP7waAoRFtlXuAnAtl4l/DkfwsT@postini.com; Mon, 21 Jul 2014 16:21:45 PDT
Received: by mail-wi0-f173.google.com with SMTP id f8so5009036wiw.12 for ; Mon, 21 Jul 2014 16:21:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=pHXnwDszQDmVXmQZdGAhlkP9a0uQrZbxRXg8PvJU3X0=; b=FIYvh5kjttIy5sGZe4vzirL9yfPamTa3WIr1YG8u2l8TdvWBsJ4f/DGxP6gWr/stjM uT5ifkWzrNtZJtiJ7qG1NxWspgyclQLq21ERC5rsWyd9/s+0KN4ja1W9RdwH3yERmEPL 2jsHvY8tRmAStEgYtVhuG4USnjVYJle6g7gw5FJDn8H3rcs7A5IwFF7yN99yTdtfbtq7 ONwFhRQV4XnEuJtJnNv17UvDpiT/ZbFgoQGQ58pk/okFFL4WMKmHxyN6LZOpT7amAvuW w+R3xqya91oOVLWwa8eBc/2UL7YCLsKXXB0ZGAMmvz1wTxYJ/v1sEGpXickdFq1Xoutb ZAJQ==
X-Gm-Message-State: ALoCoQlRu0eFzl0ykpyEhFwM21+aCs3vlvNjiBDy7NYooecHDTdCJU7P3nI4mF3MR0iqn5Bf02cLzJlT4gttOp7g1xIgmhGxkHowegDh+zj5++tMt/m8/AE0TYAXpjRgudjhTfHUYPUm
X-Received: by 10.194.219.70 with SMTP id pm6mr27626105wjc.53.1405984902765; Mon, 21 Jul 2014 16:21:42 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.219.70 with SMTP id pm6mr27626094wjc.53.1405984902671; Mon, 21 Jul 2014 16:21:42 -0700 (PDT)
Received: by 10.194.60.178 with HTTP; Mon, 21 Jul 2014 16:21:42 -0700 (PDT)
Date: Mon, 21 Jul 2014 19:21:42 -0400
Message-ID: 
From: Michael Procter 
To: "" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xzmJkwfd0UQ1A_CFFyn8rWqXD0M
Subject: [rtcweb] security-arch: 5.6.5.3.3: Managing User Login
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 21 Jul 2014 23:21:47 -0000

In the security-arch draft, section 5.6.5.3.3 contains the following
in the penultimate paragraph:

   Once any user
   interactions are complete, the IFRAME MUST send a postMessage
   [WebMessaging] to its containing window indicating completion.  Any
   message is sufficient for this purpose, the "source" parameter
   identifies the originating IFRAME.

The "Any message is sufficient for this purpose" part appears to
conflict with the w3c draft section 8.2.1 which contains:

   The message MUST be the DOMString "LOGINDONE".

Given the choice between a null message and the string "LOGINDONE" I
am drawn to sending the string.  It seems to go well with the IdP
proxy protocol, and also gives an opportunity to extend it in the
future if needed (LOGINFAILED maybe?).

Rather than simply duplicating the string in the security-arch draft,
I suggest changing the end of that paragraph to:

   Once any user
   interactions are complete, the IFRAME MUST send a postMessage
   [WebMessaging] to its containing window indicating completion, as
   described in section 8.2.1 of [webrtc-api].

Regards,

Michael


From nobody Mon Jul 21 16:51:21 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7811A0306 for ; Mon, 21 Jul 2014 16:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.579
X-Spam-Level: 
X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTJOSDjw7zB2 for ; Mon, 21 Jul 2014 16:51:18 -0700 (PDT)
Received: from mail-we0-f172.google.com (na3sys009aog127.obsmtp.com [74.125.149.107]) by ietfa.amsl.com (Postfix) with SMTP id 87B7F1A02F3 for ; Mon, 21 Jul 2014 16:51:18 -0700 (PDT)
Received: from mail-we0-f172.google.com ([74.125.82.172]) (using TLSv1) by na3sys009aob127.postini.com ([74.125.148.12]) with SMTP ID DSNKU82ndkfUdPedFHQizg3wtUq8FF5vLrpC@postini.com; Mon, 21 Jul 2014 16:51:18 PDT
Received: by mail-we0-f172.google.com with SMTP id x48so8369750wes.3 for ; Mon, 21 Jul 2014 16:51:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=O72cvJNX4655NtwgQWmQ56EqQmAKCsvhW+uxmQbPFaY=; b=fOgV38/yV0Dp4v7GhxD3D9wsEeFKItYywN2x0+c/o7y3aPFh64073YhrBBtuFmqpjk f3Tox4G+kSyMj5rdgAKN6O1FAo00AHWMEvXPOKLb5Qu5Jjgv1AJkPto8VBVBAkrxXcjY g8PdHNkLg93ZtKb/yO+t+2weETwoUKJUSoF59HWs+Cga6FdYMfdKpqrhmtW++NJTDgmf g5YhGthCFYuOayx75w75G4TD9ueycAxv43xs/YciqLGYgYdHUQ2BCJJ+qXnrqzd9Gy0X oa/z9Vim4N0rBI+igXEU15qiUuOWhpn3pXRb6fTaim93WOl41vuPNi4EFjqRUjMTwSDz iQOQ==
X-Gm-Message-State: ALoCoQlfqItRDt1COBEAZTyHCdfSnf/RdEFXk4MKgI62dYUJaw6/FIZOwZKHpPTnP2jMt3l7myJSlFsCMyAxW7uBi/mM/yBDRlNjIEBDJ8L+jDT4/tPFjhC9w+NAld2mBTlC63RRW5YT
X-Received: by 10.180.86.7 with SMTP id l7mr8859271wiz.55.1405986677140; Mon, 21 Jul 2014 16:51:17 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.86.7 with SMTP id l7mr8859266wiz.55.1405986677063; Mon, 21 Jul 2014 16:51:17 -0700 (PDT)
Received: by 10.194.60.178 with HTTP; Mon, 21 Jul 2014 16:51:17 -0700 (PDT)
Date: Mon, 21 Jul 2014 19:51:17 -0400
Message-ID: 
From: Michael Procter 
To: "" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/C2se43GaJtWsikEtBEOehqaO9Uc
Subject: [rtcweb] security-arch: 6.4.1 PeerConnection Origin Check
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 21 Jul 2014 23:51:20 -0000

Section 6.4.1 begins like this:

   Fundamentally, the IdP proxy is just a piece of HTML and JS loaded by
   the browser, so nothing stops a Web attacker o from creating their
   own IFRAME, loading the IdP proxy HTML/JS, and requesting a
   signature.  In order to prevent this attack, we require that all
   signatures be tied to a specific origin ("rtcweb://...") which cannot
   be produced by content JavaScript.

The corresponding section in the w3c draft (8.1.2, bullet 2) describes
how this is achieved, based on the principle of communicating via a
MessageChannel identified by a variable that cannot be set by another
page.  I suggest removing the text about tying signatures to specific
origins (and also the mention of HTML), so that the beginning of 6.4.1
looks more like:

   Fundamentally, the IdP proxy is just a piece of JS loaded by
   the browser, so nothing stops a Web attacker from creating their
   own IFRAME, loading the IdP proxy JS, and requesting a
   signature.  In order to prevent this attack, we require that communication
   with the IdP proxy be via a MessageChannel in a way that cannot
   be emulated by hostile JS.  This is discussed in section 8.2.1 of
[webrtc-api].

Regards,

Michael


From nobody Mon Jul 21 19:59:36 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633621A0251 for ; Mon, 21 Jul 2014 19:59:32 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -4.584
X-Spam-Level: 
X-Spam-Status: No, score=-4.584 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFmOZINC6qwL for ; Mon, 21 Jul 2014 19:59:28 -0700 (PDT)
Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FB371A03BA for ; Mon, 21 Jul 2014 19:59:24 -0700 (PDT)
Received: from epcpsbgr4.samsung.com (u144.gpu120.samsung.co.kr [203.254.230.144]) by mailout3.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N9300MWUEYXBWC0@mailout3.samsung.com> for rtcweb@ietf.org; Tue, 22 Jul 2014 11:59:21 +0900 (KST)
Received: from epcpsbgx3.samsung.com ( [172.20.52.124]) by epcpsbgr4.samsung.com (EPCPMTA) with SMTP id 57.16.13369.983DDC35; Tue, 22 Jul 2014 11:59:21 +0900 (KST)
X-AuditID: cbfee690-b7fb56d000003439-32-53cdd3894212
Received: from epmailer01 ( [203.254.219.141]) by epcpsbgx3.samsung.com (EPCPMTA) with SMTP id E0.95.13458.983DDC35; Tue, 22 Jul 2014 11:59:21 +0900 (KST)
Message-id: <01.95.13458.983DDC35@epcpsbgx3.samsung.com>
Date: Tue, 22 Jul 2014 02:59:21 +0000 (GMT)
From: Kiran Kumar Guduru 
To: Justin Uberti 
MIME-version: 1.0
X-MTR: 20140722012959340@kiran.guduru
Msgkey: 20140722012959340@kiran.guduru
X-EPLocale: en_US.windows-1252
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20140722012959340@kiran.guduru
X-ParentMTR: 
X-ArchiveUser: 
X-CPGSPASS: N
MIME-version: 1.0
Content-type: multipart/related; boundary="=_NamoWEC-rk8v0jzu41"
X-Generator: Namo ActiveSquare 7 7.0.0.45
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPJsWRmVeSWpSXmKPExsWyRsSkRrfz8tlgg3n3jS3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRu/JDSwFDy6wVKxqP83SwNh8kKWLkZNDSEBdYsPqe2wgtoSA icTLa7NZIWwxiQv31gPFuYBqljJKHF/bwQxT1HlxBRNEYg6jxJGPl5lAErwCFhIbZ+wD62YR UJWYfvc6O4jNBtTw68QaRhBbWCBO4syUFWDbRAQ0JN5ebAYbxCzQyihxdedUqJOUJNZevckK MVRQ4uTMJywQm1Ul/h2fD7VMTeLu8s9Qp8pJLJkKcYSEAK/EjPanLDDxaV/XQF0tLXF+1gZG mNcWf38MFeeXOHZ7B1AvB1jvk/vBMGN2b/4CDRUBialnDkK1akm8W9vEDmHzSaxZ+JYFZsyu U8uZYXrvb5nLhOp8DqAfnSQOX/SAKNGUeLSolWUCo/IsJFWobLgOkDCzgKHEl3mPGSFsRYkp 3Q/ZIWw7iW2XjzJhiqtKXDlyjRmm5vanRWzY1Mxa/J8Vpubjjk1YzFeVeP2vgX0BI98qRtHU guSC4qT0IhO94sTc4tK8dL3k/NxNjMBkePrfswk7GO8dsD7EuIIRGP0TmaVEk/OB6TSvJN7Q 2MzIwtTE1NjI3NJsAISVxHnVHiUFCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBk3+XzZ7PF d59wfuHinb0JoWzNcw8nKN9yXsTDHZX3R9qP73VKXuRlriPm6p/PFj6wPSxeFLH7yHEhKxl+ pc8zt39Kv+Hxj3tJ0Gom48frz988vL/nDdub0Jv5lYduX1zZnr7AZekdzffrs17lnVuw7/ZS D79z30r6Nt4yvjmr/+W5KYt/m8vEKrEUZyQaajEXFScCAO/wP0niAwAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmrlkOLIzCtJLcpLzFFi42I5/e92r27n5bPBBotXq1is/dfO7sDosWTJ T6YAxqg0m4zUxJTUIoXUvOT8lMy8dFsl7+B453hTMwNDXUNLC3MlhbzE3FRbJRefAF23zByg qUoKZYk5pUChgMTiYiV9O5ui/NKSVIWM/OISW6VoQ3MjPSMDPVMjPUPTWCtDAwMjU6CahLSM 3pMbWAoeXGCpWNV+mqWBsfkgSxcjJ4eQgLrEhtX32EBsCQETic6LK5ggbDGJC/fWA8W5gGrm MEoc+XgZLMEioCox/e51dhCbDajh14k1jCC2sECcxJkpK8AGiQhoSLy92MwE0sws0MoocXXn VKhtShJrr95kBbF5BQQlTs58wgKxTVXi3/H5TBBxNYm7yz+zQsTlJJZMvQx1Ea/EjPanLDDx aV/XMEPY0hLnZ21ghLl68ffHUHF+iWO3dwD1coD1PrkfDDNm9+YvUA8LSEw9cxCqVUvi3dom dgibT2LNwrcsMGN2nVrODNN7f8tcJlTncwD96CRx+KIHRImmxKNFrSwTGGVnIalCZcN1gISZ BQwlvsx7zAhhK0pM6X7IDmHbSWy7fJQJU1xV4sqRa8wwNbc/LWLDpmbW4v+sMDUfd2zCYr6q xOt/DewLGPlWMYqmFiQXFCelVxjrFSfmFpfmpesl5+duYgSn3meLdzD+P299iFGAg1GJh9dC /mywEGtiWXFl7iFGFaA5jzasvsAoxZKXn5eqJMLbvgcozZuSWFmVWpQfX1Sak1p8iPEtIzDh TGSWEk3OB2aMvJJ4Q2MTc1NjUwsDQ3Nzs6EqrCTOG38rKUhIID2xJDU7NbUgtQjmYSYOTqkG xrqqtY0bvJo9o18f2q77aC7ncg0Rz43ily+vEb7tMHfBJXEph90Ttvbev6H69+uDd5vkVzxw PHLh4TqJ/UzdeZ4L2P+ma94NbPNYctHcX0XohJPVTvNsMf9NZ7tOG37JXCFW+e/m9Df/nz7V n/5zrVhpYNodkdbufKk1h65x7DjjG31/sfRkTmslluKMREMt5qLiRACXr6O7mAQAAA==
DLP-Filter: Pass
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/pUgLfvEpHizVg3BUZfvR0zc5eZc
Cc: franklin blek , "rtcweb@ietf.org" , "public-webrtc@w3.org" 
Subject: Re: [rtcweb] New Version Notification for draft-guduru-rtcweb-codec-preferences-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: kiran.guduru@samsung.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: Tue, 22 Jul 2014 02:59:32 -0000

--=_NamoWEC-rk8v0jzu41
Content-Type: text/html;
	charset="windows-1252"
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PHRpdGxlPlNhbXN1bmcgRW50ZXJwcmlzZSBQb3J0YWwgbXlTaW5nbGU8L3Rp
dGxlPgo8bWV0YSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9d2luZG93cy0xMjUyIiBodHRw
LWVxdWl2PSJDb250ZW50LVR5cGUiPgo8c3R5bGUgaWQ9Im15c2luZ2xlX3N0eWxlIiB0eXBlPSJ0
ZXh0L2NzcyI+UCB7CglNQVJHSU4tVE9QOiA1cHg7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJpYWw7
IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiA5cHQKfQpURCB7CglNQVJHSU4tVE9QOiA1
cHg7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJpYWw7IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1T
SVpFOiA5cHQKfQpMSSB7CglNQVJHSU4tVE9QOiA1cHg7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJp
YWw7IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiA5cHQKfQpCT0RZIHsKCUxJTkUtSEVJ
R0hUOiAxLjQ7IE1BUkdJTjogMTBweDsgRk9OVC1GQU1JTFk6IEFyaWFsLCBhcmlhbDsgRk9OVC1T
SVpFOiA5cHQKfQo8L3N0eWxlPgoKPG1ldGEgbmFtZT0iR0VORVJBVE9SIiBjb250ZW50PSJBY3Rp
dmVTcXVhcmUiPgo8L2hlYWQ+PGJvZHk+CjxwPkhpIEp1c3Rpbiw8L3A+CjxwPlBsZWFzZSBmaW5k
IG15IGNvbW1lbnRzIGlubGluZS48L3A+CjxwPiZuYnNwOzwvcD4KPHA+LS0tLS0tLSA8Yj5Pcmln
aW5hbCBNZXNzYWdlPC9iPiAtLS0tLS0tPC9wPgo8cD48Yj5TZW5kZXI8L2I+IDogSnVzdGluIFVi
ZXJ0aSZsdDtqdWJlcnRpQGdvb2dsZS5jb20mZ3Q7PC9wPgo8cD48Yj5EYXRlPC9iPiA6IEp1bCAy
MiwgMjAxNCAwMzo0OCAoR01UKzA5OjAwKTwvcD4KPHA+PGI+VGl0bGU8L2I+IDogUmU6IFJlOiBO
ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWd1ZHVydS1ydGN3ZWItY29kZWMtcHJl
ZmVyZW5jZXMtMDEudHh0PC9wPgo8cD4mbmJzcDs8L3A+CjxkaXYgZGlyPSJsdHIiPjxicj4KPGRp
diBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj48YnI+CjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5P
biBNb24sIEp1bCAyMSwgMjAxNCBhdCAxMjoxNCBBTSwgS2lyYW4gS3VtYXIgR3VkdXJ1IDxzcGFu
IGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmtpcmFuLmd1ZHVydUBzYW1zdW5nLmNvbSIg
dGFyZ2V0PSJfYmxhbmsiPmtpcmFuLmd1ZHVydUBzYW1zdW5nLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3
cm90ZTo8YnI+CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDAuOGV4OyBw
YWRkaW5nLWxlZnQ6IDFleDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsg
Ym9yZGVyLWxlZnQtd2lkdGg6IDFweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyIgY2xhc3M9
ImdtYWlsX3F1b3RlIj4KPGRpdj4KPHA+SGkgSnVzdGluLDwvcD4KPHA+SSBkb24ndCBmZWVsIHRo
ZSBudW1iZXIgb2YgQVBJIGFkZGl0aW9uLCZuYnNwO2lzIGEgYmlnIHByb2JsZW0gOikuPC9wPjwv
ZGl2PjwvYmxvY2txdW90ZT4KPGRpdj5Zb3UgYXJlIHByb3Bvc2luZyBleHBhbmRpbmcgdGhlIEFQ
SSBzdXJmYWNlIG9mIFdlYlJUQyAxLjAgYnkgb3ZlciAxMCUuIFRoaXMgaXMgYSBzaWduaWZpY2Fu
dCBhZGRpdGlvbiAodGhlIGN1cnJlbnQgUGVlckNvbm5lY3Rpb24gb2JqZWN0IGl0c2VsZiBvbmx5
IGhhcyAyMSBtZXRob2RzKSwgYW5kIGRvZXNuJ3QgY291bnQgdGhlIGNvZGVjIG9iamVjdCB0aGF0
IHdvdWxkIGhhdmUgdG8gYmUgYWRkZWQgdG8gdGhlIHNwZWMgdG8gY29tcGxldGUgdGhpcyBkZXNp
Z24uPC9kaXY+CjxkaXY+W0tJUkFOXSBBbGwgdGhlIEFQSSdzIGFyZSBub3QgbmV3IGhlcmUuIGNy
ZWF0ZU9mZmVyIGFuZCBjcmVhdGVBbnN3ZXIgYXJlIGFueWhvdyBvbGQgQVBJcyBvbmx5LCB3ZSBh
cmUganVzdCBleHRlbmRpbmcgdGhlIG9wdGlvbnMgZm9yIHRoZSBzYWtlIG9mIGZ1dHVyZSBzdHJl
YW1zLiAoRmlyc3QgSSB0aG91Z2h0IG9mIHRvIHJlbW92ZSBtb2RpZnlpbmcgdGhpcyBwbGFjZS4g
QWZ0ZXIgY2hlY2tpbmcgdGhlIEhhcmFsZCdzIHBvaW50Jm5ic3A7dGhhdCBnaXZpbmcgdGhlIHBy
ZWZlcmVuY2VzIGZvciBmdXR1cmUgc3RyZWFtcyBJIGZlbHQgaXQgaXMgcmVhc29uYWJsZSB0byBh
ZGQgaXQgaGVyZSkuPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdlIGNh
biByZWR1Y2UgdGhlIG51bWJlciBvZiBBUEkncyBmb3IgZ2V0dGluZ0NvZGVjcyB0byAxIGluc3Rl
YWQgb2YgMi4ganVzdCBieSBtb2RpZnlpbmcgPC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGdldFN1cHBvcnRlZENv
ZGVjcyhzdHJpbmcgdHlwZSk7IDwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwO1RoaXMgd2lsbCByZXR1cm4gdGhlIHR5cGUgb2YgY29kZWNzIGJhc2VkIG9u
IHRoZSB0eXBlICJhdWRpbyIgb3IgInZpZGVvIjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBUaGUgb3RoZXIgcGxhY2Ugd2hpY2ggd2UgYWRkZWQgdGhpcyBpcyBS
VENSVFBTZW5kZXIvUmVjZWl2ZXIuIEkgYWRkZWQgdGhpcyBBUEkgYXMgcGVyIHlvdXIgc3VnZ2Vz
dGlvbiB0aGF0IHRoZSByaWdodCBwbGFjZSB0byBhZGQgdGhlc2UgaXMgUlRDUlRQU2VuZGVyL1Jl
Y2VpdmVyIGJ1dCBub3QgY3JlYXRlT2ZmZXIvQW5zd2VyLjwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBJIGZlZWwgdGhlIG5ldyBBUEkgYWRkaXRpb24gd2lsbCBub3cgYmVj
b21lIDMmbmJzcDsrIGNvbnN0cmFpbnQgYWRkaXRpb24gaW4mbmJzcDtjcmVhdGVPZmZlci9BbnN3
ZXImbmJzcDtidXQgbm90IDYuPC9kaXY+CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46IDBweCAw
cHggMHB4IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigy
MDQsIDIwNCwgMjA0KTsgYm9yZGVyLWxlZnQtd2lkdGg6IDFweDsgYm9yZGVyLWxlZnQtc3R5bGU6
IHNvbGlkOyIgY2xhc3M9ImdtYWlsX3F1b3RlIj4KPGRpdj4KPHA+SSBmZWVsIHRoaXMgaXMgdmVy
eSB1c2VmdWwgdG8gYWRkIGluIDEuMC4gSSBkb24ndCBrbm93IHdoYXQgbWFkZSB5b3UgZmVlbCB0
aGUgZXhpc3RpbmcgdXNlY2FzZXMgdG8gYmUgY29udHJpdmVkLiBBRkFJSywgYXBwcyBoYXMgdGhh
dCBpbnRlbGxlZ2VuY2UgdG8gYW5hbHl6ZSBvbiB0aGUgYmFuZHdpZHRoIHV0aWxpemF0aW9uLjwv
cD48L2Rpdj48L2Jsb2NrcXVvdGU+CjxkaXY+SSB0aGluayB0aGUgZXhhbXBsZXMgYXJlIGNvbnRy
aXZlZCwgYmVjYXVzZSB0aGV5IGRvbid0IHNob3cgaG93IHRoZSBhcHBzIHdvdWxkIHVzZSB0aGlz
IEFQSSB0byBhY2NvbXBsaXNoIHRoZSBkZXNpcmVkIGJlaGF2aW9yLiA8L2Rpdj4KPGRpdj5bS0lS
QU5dIEFncmVlZCwgSSB0aGluayB5b3UgYXJlIGV4cGVjdGluZyBzb21lIG1vcmUgZXhwbGVuYXRp
b24gaGVyZS4gSSB3aWxsIGFkZCBpdC48L2Rpdj4KPGRpdj5BcHBzIGNlcnRhaW5seSBkb24ndCBr
bm93IHRoZSBwb3dlciBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIHZhcmlvdXMgY29kZWNzIChpLmUu
IHdoZXRoZXIgdGhleSBhcmUgaGFyZHdhcmUtYmFja2VkIG9yIG5vdCksIGFuZCBvbmx5IGhhdmUg
aW5kaXJlY3Qga25vd2xlZGdlIG9mIHRoZSBiYW5kd2lkdGggc2l0dWF0aW9uOyB0aGV5IGRvbid0
IGhhdmUgYWxsIHRoZSBkZXRhaWxzIG9uIGNvbmdlc3Rpb24gdGhhdCB0aGUgYnJvd3NlciBoYXMg
YWNjZXNzIHRvLCBhbmQgY291bGQgZW5kIHVwIGluY29ycmVjdGx5IGRyb3BwaW5nIHRvIGEgbG93
LWJhbmR3aWR0aCBjb2RlYywgb3Igb3NjaWxsYXRpbmcgYmV0d2VlbiBjb2RlY3MsIGJlY2F1c2Ug
b2YgdGhlIGxhY2sgb2YgZGV0YWlsZWQgaW5mb3JtYXRpb24uPC9kaXY+CjxkaXY+W0tJUkFOXSBJ
IGRvbid0Jm5ic3A7b2JqZWN0IHRoaXMgZXhwbGVuYXRpb24gcmVnYXJkaW5nIHBvd2VyIGNvbnN1
bXB0aW9uIGJ1dCBjZXJ0YWlubHkgc29tZSBjb2RlY3MgaW4gbWFya2VkJm5ic3A7YXJlIGFscmVh
ZHkgcHJvdmVkIGFib3V0IHRoaWVyIHByb2Nlc3Npbmcgc3BlZWRzIGFuZCBiYW5kd2lkdGggdXRp
bGl6YXRpb25zLiA8L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtS
ZWdhcmRpbmcga25vd2xlZGdlIG9mIGJhbmR3aWR0aCwgQXBwIGNhbiBjaGVjayZuYnNwO2JhbmR3
aWRodGggYXZhaWxhYmlsaXR5Jm5ic3A7dGhyb3VnaCBvdGhlciBBUElzLiBBbHNvIGluIGNhc2Ug
b2YgdXNpbmcgYXBwbGljYXRpb25zIHVzaW5nIGZlYXR1cmVzJm5ic3A7bGlrZSB2aWRlbyBvbiBk
ZW1hbmQgZXRjLCB3aGVyZSB0aGUgQVBQIGhhcyB0aGUgY29udHJvbCBvbiBiYW5kd2lkdGggdG8g
aW5jcmVhc2Ugb3IgZGVjcmVhc2UgdGhlIGJhbmR3aWR0aCwgYXBwbGljYXRpb25zIGNhbiBnZXQg
dGhhdCBrbm93bGVkZ2UgcHJpb3IgdG8gYnJvd3NlciB0aHJvdWdoIHNpZ25hbGxpbmcuPC9kaXY+
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDAuOGV4OyBwYWRkaW5nLWxl
ZnQ6IDFleDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgYm9yZGVyLWxl
ZnQtd2lkdGg6IDFweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyIgY2xhc3M9ImdtYWlsX3F1
b3RlIj4KPGRpdj4KPHA+T25lIHVzZSBjYXNlIEkgbWlzc2VkIGluIHRoZSBkcmFmdCBhbmQgSSB3
b3VsZCBsaWtlIHRvIGFkZCBpbiB0aGUgbmV4dCB2ZXJzaW9uIGlzLCB0aGUgcHJvYmxlbSBhcmlz
aW5nIGF0IGdhdGV3YXlzLCB3aGljaCBjYW4gb25seSBiZSBzb2x2ZWQgYnkgYXBwcywgYnV0IG5l
dmVyIGJ5IGJyb3dzZXIgYXMgZXhwbGFpbmVkIGJlbG93LjwvcD4KPHA+Jm5ic3A7PC9wPgo8cD4i
Q29uc2lkZXJpbmcgdGhlIHVzZWNhc2Ugb2ZmIGFuIGFwcGxpY2F0aW9uIGlzIHNlcnZpbmcgdGhl
IG5lZWRzIGJldHdlZW4gd2VicnRjIGNsaWVudCBhbmQgbm9uLXdlYnJ0YyBjbGllbnQgKElNUyBm
b3IgZXhhbXBsZSksIHRoYXQgZG9lcyBub3Qgc3VwcG9ydCB0aGUgbWFuZGF0b3J5IGNvZGVjcyBz
cGVjaWZpZWQgZm9yIFdlYlJUQywgdGhlbiBnYXRld2F5cyB3aWxsIHNvbHZlIHRoZSBwcm9ibGVt
IGJ5IHRyYW5zY29kaW5nLiA8L3A+CjxwPklmIGEgYnJvd3NlciBpcyBzdXBwb3J0aW5nIGNvZGVj
cyB3aGljaCBkb24ndCBuZWVkIHRoaXMga2luZCBvZiB0cmFuc2NvZGluZywgYnV0IGdpdmluZyBs
b3cgcHJpb3JpdHkgdG8gdGhlbSwgdGhlbiBhY2NvcmRpbmcgdG8mbmJzcDtleGlzdGluZyBzcGVj
aWZpY2F0aW9ucywgdGhlIGdhdGV3YXkgaGFzIHRvIGFjY2VwdCB0aGUgb2ZmZXIgd2l0aCBwcmlv
cml0aWVzIHNwZWNpZmllZCBieSB3ZWJydGMgKGNvbnNpZGVyaW5nIHRoZSBjYXNlIGZvciB3ZWJy
dGMgY2xpZW50IGFzIG9mZmVyZXIpIGNsaWVudCB0aHJvdWdoIGFuc3dlciwgdGhlbiBhZ2FpbiBn
YXRld2F5IGhhcyB0byBzZW5kIHRoZSBvZmZlciB3aXRoIGl0cyBvcmRlciBvZiBwcmlvcml0eSB0
byBjaGFuZ2UgdG8gY29kZWMgcHJlZmVyZW5jZXMsIHJlc3VsdGluZyBpbiBhIHNlY29uZCBvZmZl
ci1hbnN3ZXIgbmVnb3RpYXRpb24uIiZuYnNwOyBJbiB0aGlzIGtpbmQgb2YgdXNlY2FzZXMgQVBJ
IGFyZSBrbm93biBhYm91dCB0aGUgcHJpb3JpdHkgb2YgY29kZWNzIHJlcXVpcmVkIGFuZCB3ZSBj
YW4gYXZvaWQgdGhpcyBraW5kIG9mIHVubmVjZXNzYXJ5IHNpZ25hbGluZyBpZiBBUElzIGFyZSBw
cm92aWRlZCB0byBhcHBzIHRvIHByaW9yaXRpemUgdGhlIGNvZGVjcy48L3A+CjxwPiZuYnNwOzwv
cD4KPHA+SSBob3BlIHRoaXMgZXhhbXBsZSB3aWxsIGFkZCBzb21lIG1vcmUgdmFsdWUgdG8gdGhp
cyBpZGVhLjwvcD48L2Rpdj48L2Jsb2NrcXVvdGU+CjxkaXY+PGJyPjwvZGl2Pgo8ZGl2PlRoaXMg
aXMgYSB1c2VmdWwgZXhhbXBsZSwgdGhhbmtzIGZvciBleHBsYWluaW5nIHRoaXMuIEJ1dCBJIHRo
aW5rIHRoaXMgaXMgdGhlIHdyb25nIHNvbHV0aW9uLiBRdW90aCBSRkMzMjY0LCBTLiA3OjwvZGl2
Pgo8ZGl2Pjxicj48L2Rpdj4KPGRpdj48aT4mbmJzcDsgJm5ic3A7V2hlbiB0aGUgb2ZmZXJlciBy
ZWNlaXZlcyB0aGUgYW5zd2VyLCBpdCBNQVkgc2VuZCBtZWRpYSBvbiB0aGU8L2k+PC9kaXY+Cjxk
aXY+PGk+Jm5ic3A7ICZuYnNwO2FjY2VwdGVkIHN0cmVhbShzKSAoYXNzdW1pbmcgaXQgaXMgbGlz
dGVkIGFzIHNlbmRyZWN2IG9yIHJlY3Zvbmx5IGluPC9pPjwvZGl2Pgo8ZGl2PjxpPiZuYnNwOyAm
bmJzcDt0aGUgYW5zd2VyKS4gJm5ic3A7SXQgTVVTVCBzZW5kIHVzaW5nIGEgbWVkaWEgZm9ybWF0
IGxpc3RlZCBpbiB0aGUgYW5zd2VyLDwvaT48L2Rpdj4KPGRpdj48aT4mbmJzcDsgJm5ic3A7YW5k
IGl0IFNIT1VMRCB1c2UgdGhlIGZpcnN0IG1lZGlhIGZvcm1hdCBsaXN0ZWQgaW4gdGhlIGFuc3dl
ciB3aGVuIGl0PC9pPjwvZGl2Pgo8ZGl2PjxpPiZuYnNwOyAmbmJzcDtkb2VzIHNlbmQuPC9pPjwv
ZGl2Pgo8ZGl2PjxpPjxicj48L2k+PC9kaXY+CjxkaXY+Tm90ZSB0aGUgdXNlIG9mIFNIT1VMRCB2
cyBNVVNULjwvZGl2Pgo8ZGl2Pgo8ZGl2PltLSVJBTl0gc2VjdGlvbiA3IGV4cGxhaW5zIGFib3V0
ICJvZmZlcmVyIHByb2Nlc3Npbmcgb2YgdGhlIEFuc3dlciIuIEJ1dCBJIHRoaW5rIHRoZSBjb3Jy
ZWN0IHNlY3Rpb24gZm9yIG15IGV4cGxhbmF0aW9uIGlzIHNlY3Rpb24gNiwgIiBHZW5lcmF0aW5n
IHRoZSBBbnN3ZXIiLCB3aGljaCByZWNvbW1vbmRzIHRvIHVzZSB0aGUgc2FtZSBvcmRlciBvZiBw
cmVmZXJlbmNlIGFzIHRoYXQgaW4gdGhlIG9mZmVyLjwvZGl2Pgo8ZGl2PjwvZGl2Pgo8ZGl2Pjxw
cmUgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IHRleHQtdHJhbnNmb3JtOiBub25lOyBsaW5l
LWhlaWdodDogbm9ybWFsOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFs
OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDog
bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyB3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPiAgICJBbHRo
b3VnaCB0aGUgYW5zd2VyZXIgTUFZIGxpc3QgdGhlIGZvcm1hdHMgaW4gdGhlaXIgZGVzaXJlZCBv
cmRlciBvZgogICBwcmVmZXJlbmNlLCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0IHVubGVzcyB0aGVy
ZSBpcyBhIHNwZWNpZmljIHJlYXNvbiwKICAgdGhlIGFuc3dlcmVyIGxpc3QgZm9ybWF0cyBpbiB0
aGUgc2FtZSByZWxhdGl2ZSBvcmRlciB0aGV5IHdlcmUKICAgcHJlc2VudCBpbiB0aGUgb2ZmZXIu
IjwvcHJlPjwvZGl2PjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PkVyZ28sIGV2ZW4gaWYg
dGhlIG9mZmVyIGhhcyBtPWF1ZGlvIDExMTEgUlRQL1NBVlBGIFggWSBaLCBpdCBpcyBjb21wbGV0
ZWx5IGxlZ2FsIGZvciB0aGUgY2FsbGVlIHRvIGFwcGx5IGl0cyBvd24gcHJpb3JpdGllcyBhbmQg
c2VuZCB3aXRoIGNvZGVjIFkgb3IgWiBpbnN0ZWFkIG9mIFggaWYgdGhlcmUgYXJlIGNvbXBlbGxp
bmcgcmVhc29ucyB0byBkbyBzby4gVGhpcyBtYWtlcyBtb3JlIHNlbnNlIHRvIG1lIHRoYW4gZG9p
bmcgYW4gaW1tZWRpYXRlIHJlLW9mZmVyLCBvciBhZGRpbmcgQVBJcyB0byByZW9yZGVyIHRoZSBi
cm93c2VyJ3MgY29kZWMgbGlzdC48L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5bS0lSQU5d
IEkgYWdyZWUgY2hhbmdpbmcgdGhlIG9yZGVyIGlzIGxlYWdlbCBidXQgbm90IFJFQ09NTUVOREVE
IGFzIGV4cGxhaW5lZCBhYm92ZS4gU28gZ2VuZXJhbGx5IGltcGxlbWVudG9ycyBtYXkgbm90IGRv
IHRoaXMgcHJhY3RpY2UuPC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+Q2hyb21lIGFsc28g
c2VlbXMgdG8gYWNjZXB0IHRoaXMgPGEgaHJlZj0iaHR0cHM6Ly9jb2RlLmdvb2dsZS5jb20vcC93
ZWJydGMvaXNzdWVzL2RldGFpbD9pZD0yODY4Ij5odHRwczovL2NvZGUuZ29vZ2xlLmNvbS9wL3dl
YnJ0Yy9pc3N1ZXMvZGV0YWlsP2lkPTI4Njg8L2E+PC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+Cjxk
aXY+UmVnYXJkcyw8L2Rpdj4KPGRpdj5LaXJhbi48L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRp
dj4mbmJzcDs8L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp
bjogMHB4IDBweCAwcHggMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyBib3JkZXItbGVmdC1jb2xv
cjogcmdiKDIwNCwgMjA0LCAyMDQpOyBib3JkZXItbGVmdC13aWR0aDogMXB4OyBib3JkZXItbGVm
dC1zdHlsZTogc29saWQ7IiBjbGFzcz0iZ21haWxfcXVvdGUiPgo8ZGl2Pgo8cD4mbmJzcDs8L3A+
CjxwPiZuYnNwOzwvcD4KPHA+LS0tLS0tLSA8Yj5PcmlnaW5hbCBNZXNzYWdlPC9iPiAtLS0tLS0t
PC9wPgo8cD48Yj5TZW5kZXI8L2I+IDogSnVzdGluIFViZXJ0aSZsdDs8YSBocmVmPSJtYWlsdG86
anViZXJ0aUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+anViZXJ0aUBnb29nbGUuY29tPC9h
PiZndDs8L3A+CjxwPjxiPkRhdGU8L2I+IDogSnVsIDIxLCAyMDE0IDEyOjMwIChHTVQrMDk6MDAp
PC9wPgo8cD48Yj5UaXRsZTwvYj4gOiBSZTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk
cmFmdC1ndWR1cnUtcnRjd2ViLWNvZGVjLXByZWZlcmVuY2VzLTAxLnR4dDwvcD4KPGRpdj4KPGRp
diBjbGFzcz0iaDUiPgo8cD4mbmJzcDs8L3A+CjxkaXYgZGlyPSJsdHIiPlRoaXMgc2VlbXMgbGlr
ZSBhIHByZXR0eSBiaWcgaGFtbWVyIHRvIHNvbHZlIGEgZmFpcmx5IHNtYWxsIHByb2JsZW0uIFRo
aXMgcHJvcG9zYWwgYWRkcyA2IG5ldyBBUEkgcG9pbnRzIGZvciB0aGUgcHVycG9zZSBvZiBjaGFu
Z2luZyB0aGUgb3JkZXIgb2YgY29kZWNzIGluIGNyZWF0ZU9mZmVyLCB3aGljaCBzZWVtcyBsaWtl
IGEgaGlnaCBjb3N0LWJlbmVmaXQgcmF0aW8uIEFuZCB3aGlsZSB0aGUgdXNlIGNhc2VzIGxpc3Rl
ZCBoZXJlIGFyZSBoZWxwZnVsLCB0aGV5IHNlZW0gc29tZXdoYXQgY29udHJpdmVkIHRvIG1lLCBz
aW5jZSBpdCBzZWVtcyB1bmxpa2VseSB0aGF0IHRoZSBhcHBsaWNhdGlvbiBjYW4gbWFrZSBiZXR0
ZXIgY2hvaWNlcyBhYm91dCBiYW5kd2lkdGggb3IgcG93ZXIgY29uc3VtcHRpb24gdGhhbiB0aGUg
YnJvd3Nlci4gCjxkaXY+PGJyPjwvZGl2Pgo8ZGl2PldpdGhvdXQgYSBzcGVjaWZpYywgY29uY3Jl
dGUgZXhhbXBsZSwgSSByZW1haW4gdW5jb252aW5jZWQgdGhhdCB0aGlzIGlzIHdvcnRoIGRvaW5n
IGluIHRoZSAxLjAgdGltZWZyYW1lLiBQb3N0LTEuMCwgd2UgY2FuIHByb2JhYmx5IGZpbmQgYSB3
YXkgdG8gcHJvdmlkZSB0aGlzIHNvcnQgb2YgbG93ZXItbGV2ZWwgY29udHJvbC48L2Rpdj48L2Rp
dj4KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj48YnI+CjxkaXYgY2xhc3M9ImdtYWlsX3F1
b3RlIj5PbiBTYXQsIEp1bCAxMiwgMjAxNCBhdCA5OjQxIFBNLCBmcmFua2xpbiBibGVrIDxzcGFu
IGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmZyYW5rbGluLmJsZWtAZ21haWwuY29tIiB0
YXJnZXQ9Il9ibGFuayI+ZnJhbmtsaW4uYmxla0BnbWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj4gd3Jv
dGU6PGJyPgo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCAwLjhleDsgcGFk
ZGluZy1sZWZ0OiAxZXg7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7IGJv
cmRlci1sZWZ0LXdpZHRoOiAxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsiIGNsYXNzPSJn
bWFpbF9xdW90ZSI+CjxkaXY+SGksPC9kaXY+CjxkaXY+VGhlIGRyYWZ0IHNlZW1zIHRvIGV4cGxh
aW4gY29kZWMgcHJlZmVyZW5jZXMgaW4gYSBnb29kIHdheS48L2Rpdj4KPGRpdj5JIHRoaW5rIHRo
aXMgaGFzIGEgZ29vZCBwb3Rlbml0aWFsIHRvJm5ic3A7YmUgYSBwYXJ0IG9mJm5ic3A7V2ViUlRD
MS4wLjwvZGl2Pgo8ZGl2Pgo8ZGl2Pgo8ZGl2Pjxicj48YnI+Jm5ic3A7PC9kaXY+CjxkaXYgY2xh
c3M9ImdtYWlsX3F1b3RlIj5PbiBTYXQsIEp1bCA1LCAyMDE0IGF0IDEwOjI2IEFNLCBLaXJhbiBL
dW1hciBHdWR1cnUgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86a2lyYW4uZ3Vk
dXJ1QHNhbXN1bmcuY29tIiB0YXJnZXQ9Il9ibGFuayI+a2lyYW4uZ3VkdXJ1QHNhbXN1bmcuY29t
PC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjogMHB4
IDBweCAwcHggMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyBib3JkZXItbGVmdC1jb2xvcjogcmdi
KDIwNCwgMjA0LCAyMDQpOyBib3JkZXItbGVmdC13aWR0aDogMXB4OyBib3JkZXItbGVmdC1zdHls
ZTogc29saWQ7IiBjbGFzcz0iZ21haWxfcXVvdGUiPgo8ZGl2Pgo8cD5IaSw8L3A+CjxwPkEgbmV3
IHZlcnNpb24gb2YgY29kZWMgcHJlZmVyZW5jZXMgZHJhZnQgaGFzIGJlZW4gcHVibGlzaGVkLCBi
eSBtb2RpZnlpbmcgYXMgcGVyIHRoZSByZXZpZXcgY29tbWVudHMgcmVjZWl2ZWQuPC9wPgo8cD5Q
bGVhc2UgcmV2aWV3IGFuZCBsZXQgbWUga25vdyB5b3VyIGNvbW1lbnRzLjwvcD4KPHA+Jm5ic3A7
PC9wPgo8cD5UaGFua3MgJmFtcDsgUmVnYXJkcyw8L3A+CjxwPktpcmFuLjwvcD4KPHA+Jm5ic3A7
PC9wPgo8cD4tLS0tLS0tIDxiPk9yaWdpbmFsIE1lc3NhZ2U8L2I+IC0tLS0tLS08L3A+CjxwPjxi
PlNlbmRlcjwvYj4gOiA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0
YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZsdDs8YSBocmVmPSJt
YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQt
ZHJhZnRzQGlldGYub3JnPC9hPiZndDs8L3A+CjxwPjxiPkRhdGU8L2I+IDogSnVsIDAyLCAyMDE0
IDE4OjI4IChHTVQrMDk6MDApPC9wPgo8cD48Yj5UaXRsZTwvYj4gOiBOZXcgVmVyc2lvbiBOb3Rp
ZmljYXRpb24gZm9yIGRyYWZ0LWd1ZHVydS1ydGN3ZWItY29kZWMtcHJlZmVyZW5jZXMtMDEudHh0
PC9wPgo8cD4mbmJzcDs8L3A+PGJyPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1ndWR1cnUt
cnRjd2ViLWNvZGVjLXByZWZlcmVuY2VzLTAxLnR4dDxicj5oYXMgYmVlbiBzdWNjZXNzZnVsbHkg
c3VibWl0dGVkIGJ5IEtpcmFuIEt1bWFyIEd1ZHVydSBhbmQgcG9zdGVkIHRvIHRoZTxicj5JRVRG
IHJlcG9zaXRvcnkuPGJyPjxicj5OYW1lOiBkcmFmdC1ndWR1cnUtcnRjd2ViLWNvZGVjLXByZWZl
cmVuY2VzPGJyPlJldmlzaW9uOiAwMTxicj5UaXRsZTogV2ViUlRDIENvZGVjIFByZWZlcmVuY2Vz
PGJyPkRvY3VtZW50IGRhdGU6IDIwMTQtMDctMDI8YnI+R3JvdXA6IEluZGl2aWR1YWwgU3VibWlz
c2lvbjxicj5QYWdlczogNzxicj5VUkw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3
dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZ3VkdXJ1LXJ0Y3dlYi1jb2RlYy1wcmVm
ZXJlbmNlcy0wMS50eHQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVy
bmV0LWRyYWZ0cy9kcmFmdC1ndWR1cnUtcnRjd2ViLWNvZGVjLXByZWZlcmVuY2VzLTAxLnR4dDwv
YT48YnI+U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ndWR1
cnUtcnRjd2ViLWNvZGVjLXByZWZlcmVuY2VzLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWd1ZHVydS1ydGN3ZWItY29kZWMtcHJlZmVyZW5j
ZXMvPC9hPjxicj5IdG1saXplZDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ3VkdXJ1LXJ0Y3dlYi1j
b2RlYy1wcmVmZXJlbmNlcy0wMSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9y
Zy9odG1sL2RyYWZ0LWd1ZHVydS1ydGN3ZWItY29kZWMtcHJlZmVyZW5jZXMtMDE8L2E+PGJyPkRp
ZmY6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWd1
ZHVydS1ydGN3ZWItY29kZWMtcHJlZmVyZW5jZXMtMDEiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8v
d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1ndWR1cnUtcnRjd2ViLWNvZGVjLXByZWZl
cmVuY2VzLTAxPC9hPjxicj48YnI+QWJzdHJhY3Q6PGJyPiZuYnNwOyZuYnNwOyBXZWJSVEMgc3Bl
Y2lmaWVzIHRvIGltcGxlbWVudCBhIG1pbmltdW0gc2V0IG9mIHJlcXVpcmVkIGNvZGVjcyB0bzxi
cj4mbmJzcDsmbmJzcDsgZW5zdXJlIGd1YXJhbnRlZWQgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVu
IFdlYlJUQyBwZWVycy4mbmJzcDsmbmJzcDtXZWJSVEM8YnI+Jm5ic3A7Jm5ic3A7IGFsbG93cyBi
cm93c2VyIGltcGxlbWVudGVycyB0byBzdXBwb3J0IHZlbmRvciBzcGVjaWZpYyBjb2RlY3MgYXBh
cnQ8YnI+Jm5ic3A7Jm5ic3A7IGZyb20gbWFuZGF0b3J5IGNvZGVjcy4mbmJzcDsmbmJzcDtUaGlz
IGRvY3VtZW50IHNwZWNpZmllcyB0aGUgd2F5IGZvcjxicj4mbmJzcDsmbmJzcDsgSmF2YVNjcmlw
dCBhcHBsaWNhdGlvbnMgdG8gZ2l2ZSBwcmVmZXJlbmNlcyBmb3IgbWVkaWEgY29kZWNzIGluPGJy
PiZuYnNwOyZuYnNwOyBXZWJSVEMgY29udGV4dCBvdXQgb2YgdGhlIGF2YWlsYWJsZSBjb2RlY3Mg
aW4gYnJvd3NlciBmb3IgY3JlYXRpbmc8YnI+Jm5ic3A7Jm5ic3A7IHRoZSBvZmZlciAvIGFuc3dl
ci48YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxicj48YnI+PGJy
PlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo
ZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp
ZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvIiB0YXJn
ZXQ9Il9ibGFuayI+dG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj48YnI+VGhlIElFVEYgU2VjcmV0YXJp
YXQ8YnI+PGJyPgo8cD4mbmJzcDs8L3A+CjxwPiZuYnNwOzwvcD4KPHRhYmxlPgo8dGJvZHk+Cjx0
cj4KPHRkPgo8cD48aW1nIGJvcmRlcj0iMCIgc3JjPSJjaWQ6QkVJMFhUNE5aNUpFQG5hbW8uY28u
a3IiPjwvcD48L3RkPjwvdHI+PC90Ym9keT48L3RhYmxlPjwvZGl2PjxpbWcgYm9yZGVyPSIwIiBz
cmM9Imh0dHA6Ly9leHQuc2Ftc3VuZy5uZXQvbWFpbGNoZWNrL1NlZW5UaW1lQ2hlY2tlcj9kbz01
YjBmNjdhZjkwOTBkYTM1Mjc1ODU1NTIyNzA1Yzk3OGE2ZWVjMjNiZmZkNmY4MjM1MmNjYWFhNWU3
OGQ3OTE3ZGU2ZWVlMmJlODc0ZTA1MjNlY2QzMTQ2YmExZWRiM2VmNGJjZGVjZWQ0NmVkNWVlMDhj
ZWNlODU0MWJjMTRlYWNmODc4ZjlhMjZjZTE1YTAiIHdpZHRoPSIwIiBoZWlnaHQ9IjAiPjwvYmxv
Y2txdW90ZT48L2Rpdj48YnI+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48L2Rp
dj4KPHA+Jm5ic3A7PC9wPgo8cD4mbmJzcDs8L3A+PC9kaXY+PC9kaXY+Cjx0YWJsZT4KPHRib2R5
Pgo8dHI+Cjx0ZD4KPHA+PGltZyBib3JkZXI9IjAiIHNyYz0iY2lkOjJMTDVYT0swTEs3Q0BuYW1v
LmNvLmtyIj48L3A+PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT48L2Rpdj48aW1nIGJvcmRlcj0i
MCIgc3JjPSJodHRwOi8vZXh0LnNhbXN1bmcubmV0L21haWxjaGVjay9TZWVuVGltZUNoZWNrZXI/
ZG89ZjRmYjcwYmE4YjcyYzllYzU3ZjJjMWUyYjE3NGVmODA1NTg4N2MzNTVmMDZjMzlhNTJjY2Fh
YTVlNzhkNzkxN2ExODZlNGZjYzlhZmY4ZmZlZDEzOTRiZjMwYmEzNTE5NTNjYjhiMTkzNGFmYWJh
YzJmNmFhZjNkOTJkZWQxNDJjZjg3OGY5YTI2Y2UxNWEwIiB3aWR0aD0iMCIgaGVpZ2h0PSIwIj48
L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2PjwvZGl2Pgo8cD4mbmJzcDs8L3A+PCEtLVNQOmtp
cmFuLmd1ZHVydS0tPjwhLS1raXJhbi5ndWR1cnU6RVAtLT4KPHA+Jm5ic3A7PC9wPgo8dGFibGUg
aWQ9ImNvbmZpZGVudGlhbHNpZ25pbWciPgo8dGJvZHk+Cjx0cj4KPHRkIE5BTU9fTE9DSz0iIj4K
PHA+PGltZyBib3JkZXI9IjAiIHNyYz0iY2lkOkE2WDdMUDdLQlNMOEBuYW1vLmNvLmtyIj48L3A+
PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT48L2JvZHk+PC9odG1sPjxpbWcgc3JjPSdodHRwOi8v
ZXh0LnNhbXN1bmcubmV0L21haWxjaGVjay9TZWVuVGltZUNoZWNrZXI/ZG89ZjRmYjcwYmE4Yjcy
YzllYzA1MmQ3YWE5OWIwZjczNjUzMTRlNzgxM2YyOGI0MmFjNTJjY2FhYTVlNzhkNzkxN2E1ODZh
OGM5OWRmYmZiYWIwZWRiZTY4M2M4NTNmZTcxZGI5ZmRkZGRhMzNlODJjYmU0YTM5MTQyNGU2MmZj
ZjZjZjg3OGY5YTI2Y2UxNWEwJyBib3JkZXI9MCB3aWR0aD0wIGhlaWdodD0wIHN0eWxlPSdkaXNw
bGF5Om5vbmUnPg==


--=_NamoWEC-rk8v0jzu41
Content-Type: image/gif;
	name="201407220829439_QKNMBDIF.gif"
Content-Transfer-Encoding: base64
Content-ID: 

R0lGODlhCAKQAMQAAAAAAP///8k6OspMTNRiYtt0dOSOjumiovLExPfZ2fvt7f/+/uvr69TU1Lm5
uYyMjG9vb0dHRzMzMyoqKgICAv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEA
ABUALAAAAAAIApAAAAX/ICOOZGmeaKqubOu+cCzPdG3feK7vfO//uYBwSCwaj8ikcslsOp/QqHRK
rVqv2Kx2y+16v1YReEwum8/otHrNbhcX8Lh8Tq/b73al2M3v+/+AgYKDVniGh4h1egyEjY6PkJGS
k0OJlpd5SXsBDQ6engwNjFKilHoNSaVYqkisTK5CoUqdo02waLJMubGogg6Nt1S/a3IIeAoJmHAJ
CnTIipq1EBETFBERDRHDUdqmSQ8PSd1GENzbR+NN6UPgqRPYr+Hrae1MDhFE94MUfA3hRvOKlHPC
z8xAIXIG4EFQAJGBOQWMzWEIDckmIfqEBFR3zhuWgk82DhGJrmOAekcy/zJpR5IMSiUqA8T8A5LN
yyc1l+QEU9MSxUMKD/2cs6iIyggQKExAxSCCtVoBmlKgIC/pBEZSIzBw8I/ryWr/hDSYRjUpvq9U
ozpdGiBp2rZTyzUAO9BqLyHt3IZt22Cs03Jm0YbzS2HgA2sTfj0AixfxNqlsszLqtjgtuAfDMA+p
BlgpqgdJh82d8ACpZ7VPiUA4HNlp2tVKHVT7NbewWKUR9kpNy4Azvt6F8SGdIBg1W71C7CY/rTru
ycr/kiYlAm620+hxm4o9K5ax5Las+04gvTschL5kD8LFBmFCZ9twp8NlO6S21uJfE7dNygD6+kpx
NGTAAQMQkIwCBAxggP+AySTw0AEJPmTAAAU4SIABBiQDIYUKDCVHUflwd81JgJWomlz8UMMABCay
OFdyDzBAgXh3OTBjA1T1JsqNS5VG4lxbEVeaCEut1hQ+i/VHHDsPACkbEdrYuGNfFDggI41SXnml
jVbyiGWV7CDZYjnaXDmXP+CcNWOY/ly12En3xeLiiKDtZ+dISOLDIicpCucmPuTlFkBiMu61J47g
HZnoiFWK4KWPoDkppJuTKkmdVjomieiQ8uHl5o38DKkjW3Vu5gCOK5pIp1YuHpqiJzNeWV+VNjIi
ao+shkoplPLE6OWVbyLlKI04bpPQAgU0dICAByiQLLLGUDSAMQMkkMD/tAgMoICzCChQLbIHeBgH
iEMc9Ys+a8pIhBg2BiCoumsiqh8F/dUVVkYFaVPqaj6KIBsjvQCcGL0yCTcMfc8ByQmUnpzVTaj2
ZqTvQIntCw7F2/TLSLyvWgyOjEGG6O7BaBbB0rn4pFtTN/qw++pzBb8Y85KrrctIuwT7mHPKeNmr
8b8Lj7OU0HdFxUnF/7yMKJMFC1GQwA7sqV93GMmKKMtIhuPyyBKfw49KUHdzNckjDUYijKXKo5i9
AfQUh0IRLSBtM8tCK3dD3yazgEI/xd3ggOLCQS5GIqLc9lRTEWHfy2037jR4Lx6G+L1qasQV4jlS
E2N8TK01MOHuYp6x/3mFFR2lw7+EijlmqNej7+quP6b5xkN0DHuvNZdrsOU3ndw05isbvvjIMN9j
I+LanPXS8AWhC3pBkk8V4+ych474PaIPARnSj49TUzv4GpcYkDXFBNLL+rQz/OmWE/H1Wdsb3332
3QkaPVUvUba64wi9bbe0cKBI3CgCobjt7W5wiNuECECAcDWEDoNrWvucJxYiTO1l8MLK19xTjnoU
LXwj82BUQtGeqPiDXnsaGcH0MY6iqa8/BLNc1xonwq7FToSx0x4JiUMwdenrH58JB2jWpDviDYor
e4EZ1vhnOsNdkHjgS14stqK8vTyxeTz7HV6AOMKxECcUh2mKaIxYtP8U/rB7w/heOMJnxl9wUGQy
AVlU0Je1QSWNa6hznwTb6D0yKq5g/KpgPdQGs4XxLwDHGiDeAtgQRS6AGcs6wAH7hoBl0c2BFTnC
RSRIPBaucUlOs1WKOigcIZ5lPKgAmqBA57goXcVdoNEaVU4pv2KxSFH9QthlaDmShrVvg5NhneVe
VCxVYoY4xRpCzXxoSq69MjftkBEoQeejTSXRd56UyTSXmLOXRbFtnynHmkjjPlHCsi2lRKfjjLnM
WQqhYr/BVVQQJrYq1QNiJ1GjBJUGptAUgV4gs9/u0heObuKxfbWTYD250sFQxfMuhLqHwnLzoiex
7JkFxQgi/efIAkj/ckHgWsCyEkCAZgxokg+MyAEegiBMQjAaRilc03DklHO0xz30okY1UEFTIjpF
meOZJgi7cVNkIiZGQcWHjaiRG+BMY57UUM/HksqwGY5nRUFV6C+KutWstiWo26ApOXuKCqJm1XVJ
bNl4wNS7WQrPGmDqZdNuyh/KrBFJ71jTYsZjqPHwR6z4GM07+FdUPs2Oqr2JKlTdkw/EQPOOvckr
de76uKW+Y4072SuKnFJWwx0GNH7NqS+N+M7EnMWyTR3PTxPLWHYc9avjSc5sjFjYQV2FH4mMVkNI
ysCGZCtZAiJAAQy0AAZS0lvDxVDgFhDBJpzKCH0xSi22ApUidAIK/9eNxXMxcpfsnsRW3NluSoqm
BytxwiT5gIp342iErdyFutA1CcLGOwvylsu+0MVvfGsR3fyuq2i7sO5jxCtemXzQvutNCXbPUSrr
vte8reCpfjUJYbF05ML2ha+F84Ff71I3HIh4RhysVQyJLKBDzZgDig3RXI9MYTGHQa+Ln+CXGdsY
DIuR8Y2x0B+PiEAZQA6ykO/AJB0bYchITrIcFNAsJTs5yDvOgieiTGUt/BgTzLhElp9siS0X48R6
C7KXtZxiMSNgzGM2hIjn4OU1TyTMSXYzi1NRXezWeRBGhgkYaHNn66q3zyaUQp4DrQmeArrQTbgy
HB5yCAMmwtFcbv+0if13AEkKudJAxnSQfwtpSN/hIct19HIN0EAlg/qBiDiCP0grhZtoQTNLWJFO
qLATLYQqiSVhWBJm0oRaxxQmu3tCOXitSQYcS9KX8HSkM23pIGsaE89WRrQDNOk7BMUOyqZDtoF8
bUscwXeEaAkrk+BrJpT7CucuwjpIQmwstHvcUHhfoo29aAqJtECWJhBxC7DAZAyoQAcqAIfs1u9H
ChxDzoJDwkccoQSSesQLGoAkLYShBBQgxRlS1sQbfm9+N4jj1xJusx+ZoH0T6OKPLJBHi8FASTpr
4P82EG9XqiEKEcAYG5p4xCVEIQedWOASt9syJKTvBBT95SjHULX/Ir5Se9+bQxOqEEsFnvSij0sy
siGNaVqTGhY9JRtb7Q/pyDkfF1ZmbVWqTUOXovbupOUvZV9OpwqZNb7KvSDKGWJYq8GW3FhDI4ep
HPjsXh53WWUyilHKXlrmGsw00ysjeY7d10NFvnCiHE7VE3rgHrqnKtMasuE8a3RD75SfWebaIqnR
CYAsZT3kWXXD0AJkr9KLQ2j2BnBWQ4i7Ujk0sKV761YcstUsbWVrWxE5KUkPiOnfe9RbHZpWcZu1
8ptfa+SlrlvQq3/moMfh5seXPe2VdfGKR0T12Tp9t4xfLW9ZC1sCesjyRd1I8jurWeJ/fe6z9f5m
ydzk14IAFJF//60nUqhmJ7c0J2KCgGQCAWJkI76SMFfxJEPyJK7VCUJyH+QRKEg1PeEwPvSyGP6g
FRSYK5P1OEnSLpziUCHzJhbUTIXRFAXlgIJya0dUK4dCHCqyJ9pwJqhSRK7CQvyQOyg4gSyIFCxk
ODxoMFkyIyuoOLQSK/TigzE0QsfSe7NXaYwmSR2lW3vTIHDDEJZmINqCQLJ3cwzHSAfEcovmUrUn
Ug+hEJWGAKx3N1gIfnXIEMuXhUt2YtoHB5W2hye1DHnofin3PxoHLXdYSYwGOClFLQi0LXIThsPX
SF4YN3lDiT8RFH7zc5LEN3gDhog4LhyjRIajMlCUJlIEDkBTVv//oEsUUzIWmISziA2vZCXZNChg
xycnSEN3VE/npIs3gRU6k0opY4y+KDNWsjWr1DFsAzpbww/WsIsJdU/EsxVJ+DvgdVAj0w3qokc2
9IxWSGkDUI4SF21diEDXFoYGFBFBQRGq120/AUDF8EBz+IjFZTdyGC7mSCGaFhHZYo4RYY8jp2/P
EhT3CIjN5iHrOIqYplKWplL96IaQCI8JInBCh0Dp2JCOtIYKVCClBopreEAdyVznY4q/gzmdhBQw
JkSkcx7WMxWjwzuU1TRRgjlSVESuIZN9xDS+iEbzcz1t9Q5ZREHOw4rccTRwZUS2MzlFNDyJ4R7t
okfWmA7ZaJT/TIg6PZlQNrQ/U3SFlqYh+TaKjlSG3gItBnRzZfgTF8JoAZSHi1SPCklJ01eG+/gT
27KIeNkhBMlwyUCPCSlSC/lA69cMZ+lID1lJEamYy4BA+ohAaEiSJiZAl0gthqmJD8SJlYRymCaS
ZomZpKhBKElBQUMboAd6MANGQzNGPnlGtciN/nJalddCTNmLNtg4fUSby8MWWLlOPIOUVfNE3tgx
XFRETzQNuUEN/1RISuNL3AQ67NONv/CNXNk6xfmV/kNSzeBRy0eHZHmJklQ3b3gtuKd79VZt37Jy
3TaJyWAgdAkhjLaPXwiH1xJ91KIhcdgMpfaWCRSXnamfI6ct/+63cuLphYm5fAGoneBCl55JN5So
hulIoJbomJrZe8AnkhI6ioIjUKOZThZ1MDqYM2nyTlzxG1X4JtbkNK5IPHolTsOSPiZaL/lEHcN2
m/h0GHAyR2KXD0vCKOZRUD/6kwA1IwaFFDnagxhVRAYFYzaiHj9JQx0EAdnkI4LyVNGpLyYIjqgz
UWGhaMVVUqTGQIuWIMaQjvBIIenZLQxUagiiIIS5npPIQM2wnnTIQKeWQMZwfXAgnyf3LfqGhn1a
cy3ne3bKeggZniBZkHaacgKXDIjJhd0SpmgoqY4ZN8YVXBdSLfT3nYyaphSKp8jVll96po2qocxF
VvlUGm9VU/9G9FMlBDOIpVNSFVQu6SlX9VWXw1n5gSI06FeLVRM09VPWyFr80BS+ehNBVUKI8UrL
SjvtoFmwlRTZsFadBVtCpSehRSW+kkQ2ClUzog9LNSKClZXtIx05MR4zVFvYqXDClwCTJnyJsGJv
Boh0Y49uKQfuegd6WG2WsGJGBwfEdWLwCmZ1MLB1IGfLEGbyiggGm692sLAkFmQLewgLW7EG+1Ia
xgn4lbFOUGAF9hwfu2HlghUV1l/nxV35QGFLgGEwUQv0sg0vmwrdRV7olWCKM2FOwLGExgtLoBlL
oz0Vpjgd4aXLhgcQQiA4F5mXsFxAhiALUodFG7VSO7VAFgj/rlZly6lHWCsMs+SkUUC0VDsHcxhA
/IoI/+pkRtdkYbu2bNu2gTBlW4sE1xS3wnC1ULAJuxBgQgtdgIZEYJC3OGsEnxC0W6C3WsAKnTC4
h8azMPExXICNcFu4gdtegwYgIwZnbftIZXYMmMu5dUBiZbtpSztkz5Bmn7stnXuwqZsHm6ASxLZU
ACFj17AYXhsGHWQenNRr16CrWzBsSbkF6TAN1XANk/tuXwFai9uz2xCut6oJtUsOudsEItgKezEH
F5K5jwSpiDBtC4FqctCZTwandRAuIwlklEkH9wotTKtwDzJyLNa64fW7WwQFPjJPlduxSZluSAAS
DZYF+msF//NgvL9Gbr1AhFNglSKCa3A0awe8SkbwEvg6XNibmMu2XNy7ttu2tN47B+K7vo55CSNU
RNQEHaMxPdLDF150EAjzXP5BGEMUWGSBHWwBFhczjZjnFPfhd3HyONBZQtAha2qhlHKRHusxFkIM
eKlRH3y3efAReFMjwilceJmHGjvcNqNQCt8hFVGaGLJhG3vVCyrBEiWkHIyhHFpcxHLBGUhcxYOi
HW7XJJO3UQppABIRc+5qaZUUB/8omAnickD3UX8zc/wGcCSnIA7XQAdgccD1cwPXpiA1YirHhYV8
cS9HXCRlyODij3KKLFlIyC93jgxkcfVGXHZ8sBHCIJdcfv89R2oVV6dB53Ozd8mVtnGG7CAH9yHw
W0SagkLn4SpcA1AJVQQycipLISU4glSdkCMhuCsiCA7FpCcm8nZ7wb/itIxSeCZnw4FNSCW+xIFt
0ysWpBjacM1nwiUDXCupwotGMiJ7kkLJQVHKNCa9wRWvxIFzsTmcVIOKwcw9siu3BILd7IHfHIwY
UQ6vdESo4iKWW1xGx2iwVyGc2GyaJoclRZ6yR56KpADm53rTd3/Bx2TNIoAgRYADYp7ft36fGFIe
VTe953yf6H+vl9IPjXskR1LFJ1IldXszjb7UZ4krx53YIqAAKXHo94gQkrYd3UD8Z4iCk8sjjIJa
czOvMhP/mRUxleNMMEI0BNU46MJT0ji/tXMNO+U4FlMzFLUkxpNH7yMzOgPWFdQfOTkxJHrO8CPV
VpyjqEijp4GKK1QyyhhsMmENOsXDWh1sS9HXXG2LeJFFL1EzNaOMO2q5y4cgeAqZhanHliafBySJ
2eKQ2ssQ3mmAa6hpqjefZ1mGdUOIbUiSEyfaqAuXHolzMu2FnE2JD2ogJZkQ9YqWrY1SeBrajvjb
GreHK0WXTV0LrltHP7k+o1U70xXZwNlKo5UmorPV8naS0DPNnxDM9yNMRog8M/Q+GUFBLyE512BD
/xDAp3UWzPM8KtleewI8hwQ+OElasuEJd5Evw8A+O1kl/zkh3utN1lb0DowVExAcQBRSqog5IN47
0YK5p5MMmhQM2oTpn2OY2f24hkPxE+BLUivnLL8XkOUYl3EDvo6UyrYtdAPphXTwjpbo4ZldqQJI
kJREQC5F4ZV93Eqsy3fUDmQ31b+bDrFk1YQ93apaQdatjXMk4FqrtSJUKMSREbH5SwXzmtmtxMaI
3gglwhlxRc9TH+UCSqSJCs0ji3Vt3/Kr3ySajQtT5olt5W49F58gb3F04AuKACd14gpSkDHu4JEp
4Z8dEbB9qKIN4Y3p4pWokAf0l/yGuqS2l7H94KC5nymelqD9wcdGmYwehzL+E8GtvhoX2jiekSFc
O71gP/89XlDmFJ1hjhXjcxU6MlSwggryFOt1JG8ceuXBrLXG5C7NGE7h/TsrquvapBFx7QlGdWEB
ftc4WqUeOk1xVSeC8qGwdE/hhOZGAD2BJW/1K1rndN3D7tZE+DDDEk2o4D+q3ZECt7m919kOjtpw
E56JWJaOmtKCWZ8BIkneuXKPvKftmdI3x5cnddr4Gekm7oXw/ph1g9G0DWf8boloCEA13n7uyXre
MuOSXu90aQyl7ilMZSupHq2ixWvtcR2y5R6VJ91Zh/Ksxas+blqGtSbEfkg8bK2N0QuLwVlWBfN7
xaxubVvuAfPEw1V0ffJ/5Vgxfw42ElQAA1e0cVb/kPP/a9Iew8BrT7NWpumABJ7GsWVb6cP0TP5O
d1En0PpZ7QCI3qstHZnakJwsmq0QYToh0bfIBLIsBrqmc6qQBGKO3SdwebqmDb6mKX1yDXQtwxWe
wvUtminpoxj32vLoCoEgZOrZ+Ar4imhzknSpv72mjAb43TcgiC+nDMpcm+RetjC5FlY0NhtT6yVe
HlZhOksKOkYLFlGylRuy6YVdAEaz+PWxrl+zFYb7SPD7KCuyUWH7VGCyJosJg7hkoZuw+ApnEctm
z+8MZxYHCPtInSuvHRJm7rq5WgZn1z98q8tkKrb98DqxI/auZeawy/D8ktTxjSDAdFv/9n8EhkBq
4I+9//wPAos4kqV5oql4KKr7wqlyLAHDBLm+873/A4M5xkNoPCKTyiWz6XxCo9Kd65CIYbPaLbfr
/YJdNkZYlGiV0yTEtYSInU8JBLocV8feWb25ruKLAOJxCboUqtxxJZosdi3GCR6eFNo05DQ44EA5
TD01aB4xWOrcpB3QDJYZEKAuHLwNxBQUKgwUtH0l0MymjryexGYFr7Se/A6LIPcKwxxn8cYYlECT
/FJ7nVbTKMcqSKso1zhE2FBEjD5RdDo9FCGN75Quz2td84bvFZgWL1974ae4R2+gCH+pAE57Y3BL
NhP4EOgDZyIAPHhS1K3L6MPiEDK+BhC4oqCArRYGDv+AnIMKwaldKAu0eGkA14IEBAZ8K7DKFyp9
NkvWvPltxE9pKEOuSIkTaNESM0/d3IVzgYGUrqoiOAkSwc03I0G+IsBqJlWrUFk5ZSq04EtXKX8i
1XcWVVWkZatqW1DgZZ2jCZbC1Ot2ajWrXwNrJcB1wJvEixUS08tXcNnAcHWl1HfYpF8SM7/aTTq1
6q1VBsj69bs34kgSe20V3Fn3yoECYmlkW5pT72ird8NRJBeBAoQh5GyQazCBeI7j7XYQN4dDOYUJ
DR5wCoA9AITq6LR3d0C9OMUJE9x1t679QQRNED4Nb29jOYTjHYmGPECAqrTTevef9hdbubn0lwII
MEb/AisKoMVYX6jEspdkCywo4QgLVsiCCCOxMIBLFLJgYUEsEXDgfvrpApN+rgRWgD62zaCPfwIG
OIt+M5xYIoLVwKQTiAxuU+BeQLK4QCw37libiSx6gwyBE244pIcTxjLAGaHZpAuA/Unj4n8x6vVi
ibUZGdmUEh7ZozRoKSklf296SeYINso1lJFXJvAXAggqMBIb+ZU45CxIHWAnThwaSYeSKyJ54jYG
IHpkfjBxxSReJQSnnXo5qPdAcecxcF4AGD2nAwVFRFCEqOx5yul1EzDgwAQ7sIcDqKkGMIEDDlBA
RHuyrgdBEcpxVxwExhYXgX1j+PLNNlcIaGEsitUy/8M2xBQqgmL4BaKPMg1FSAO0+y0AEbflvgiI
QK5YQa65c7IEIbpQ5tfTG9mY22e5R+6SFSqKgeuaV392Wya7er0hEpn8JkNvArwIyJPBDY048bVW
1lSNs3fWFOG9NJjLC77emlkyLwcu0AKYAmEc7RvvjkimviO03PC7Nm7Myyz+bUvzFeYGYyHA8ub2
M8kh//twwsBVtOyxue46a6akupMD1TbYUKs6wArrqg7PARscsRQFgGuu12FHTqsUWMKAOr1qt6w8
B9NcNzRHniTXtew2RM27QJcQsE1oITiA4RHNO689sBBT+OECBxyyHjbae7C5P5F08CzQUN4wvCP8
Tf+y5vfe5CXDZZJkOGN35xUMxQhbXKZ+17w+jMeWp4t77K5fSztIXrJs98uIIzzSgtUQwPrN8QqM
cJbcFBz05MzLvjfgIau+uh5Mk8NRAMo1sPVx8Fxtag7PPVCdsme3OhwF72e3HkXvvx+B9+7D347b
ZXNC//uj5sB7c2vINlR2uzL95SQH4122KMSHSs3rW/IymgHeNbNyuSt3n+OdBf3QuTJJTlvUExnI
9NEzhm1OD0PzXMXmAEHAja4WRqtew6BxBdZJjHfN02EszlCbVhDQSAaE3ciIWMLdmSxhf5ohy4bI
C5gVTwEJ2AlRYnSt5QVRZ28ggH9IEAwYQmOFNPz/4tE0eMPtTaRpPJjA08JGvvNVDYDrAV+mjqUr
/l2CVkWwyA0skgn75fE5qYIbRr4nRwF6JCgYnBCZfCSnm5SMXQZCECAwhqbASWNH2wIabQx1w37t
0EydhJy8zEUmAfXtYxGMCQpZ4pPTOcko0rDk3rIxCwiajm5pStkAZmAUJ9WyGOsqWomo0gqbLFJC
jVRlCItISyRmq1C4zF24ivRE4u2MBrXAD2dAGJFZILNSWiyLIKakQNe9UpcL/FAsTKmZXkazG7jI
lPe4Q4HssK1sRcin2awGx7CtTzlSY085QFGqfK7tBmwjqNuIUIQHTOA4uAIWruoTj0RSpSsdI8kN
/8ViFznlJjJH6VkgQFJMZfzFRUeyxbZegjHQmbQF11jFjg7mUpp8sJ2a8ShuKlfEVXDRSiipDR14
qs4RMIij+xJLC3RIU9twcT+wTBlUpZFUSOYwMiOgKQ8zahuarCJBKbUkM3P3U7FccoEpSx7GPCob
xfTQFmRN3IhSipatJg8pYlleRhP01JeFg6Un3ZBRA5abvDa1Y5Cq6lpto9MR0HNZ8/uaeWDFHfP0
U47PqSwEpGYO45iHPHA8nzkQGlrknPY54XNH+IbDCYFG9KJuqMOB0HDLOigwBbrQFk1qIokNAaK2
SKUDI35brt4C1w95QC4iaJKnNTC3BMI1g3HZcP9cGFgXdISIbrkOQdzkeuG5LphuufyQ3ZR99wUH
Qu6ehqvcQNThvA30Isomwd3hFjcQNJGEEFqlA0zsoAHfAUImgiCeIMQKFALewYERXOAhDJhZsgDE
Kt5LgloYwDYE2TCHO+zhD4M4xK4gad1EPBEgQDR+GllxJ+b2Ag354r4bOoWFTWzjG+M4xzouQ3tN
wA8bG1jFLB4yFG7QA1HEI8JENoKQEaxkIHxiyQaWsg+Q/L0m88DKQ9ayk5fMCS4nAcwQ3ggUFkyK
J1P5yGhWsxKw/AQkRxkJYjaCkXVQHO/VM81AKGQQ7ixZIQBSzzzgM5X9PL8/2zlTRM7zRhC9DnX/
lGoJkdajDwg9BNFWuTiTnrSgG01nTcfRCJbehHCwjGkdMFoIdfZnqjsdhVG7egmwHjKfOT1oRQ+5
1Qx2dEZsfQRf+3rUuoaHr2P9BF3rWdfC5jUQVt0d+0WUOQ3QNH14ANE7jqc56UuVeXAwSG5b1jmo
2ra3kcMcTUnn2dM2t3yE5Z0dvGfawzk1RE/1vc4eqzuiqPa02diDb/vTnpvqjrSXI596x1He50a4
Pc/xHvOUygFVe7as5n2+5cSRAcNRj8alw530cZw+yal22TqLavPYWz5lA0XH2w1yWd3ze8tRj9oS
PnNLfHs66kv4zmV+boykxxIYF/h3MM6eoT+H/+AZtzi6h1WfUz373sPx1GfXzR0BP70466YOet73
qVOpluQ53wE53K2r5XDC7DD/cnxwECrilN0S6Uv3Zxk+DokHMNRVVvA9eWUJtpGvf+hw26ty9QCN
7/Pw/sbVqUKVrH2ONuWQP1aoMsHPB4RvV2VHVtnUtiz7+Z3wpGAb+HjlbQjYSvHY6RUoTIV6xmuK
CLOqVagagKtUEZ6OAWQb4d0mHutkfhwMOFb4tP3fvueT96TfVNzAU6znr4+gwtI4OW61zwfPD/PW
6drYcvC0p60vArAi6B0JCuk4lp8ckoea29BveVUdHvYQlb2mXkV/ykocVsBqh3JiJTXvo56u+P9e
6ZFe41mH361W7VkE6CkfJlSfePQK7VkHRKGN4SHeqIwbdHRe2YyfcAhHBz7f98VfqTWUPmVe7h3g
OWBEZv3AqgHQAmreqFjCd/iX9p2P+jUHJzzHCuog5MnP1bwNDhzYDMIe+cygOgDS/cQgHp0PeQgL
DMpcE6ZaPr1RoHGczI3DsDjfx6GaREmcE0IesamK5bWe+OSgf3XNDY6BDJYDHpEPDrDH2LwRg0nN
E87K05hK2yBhD2ZK25if/PxX1uDgHNVh1YyNsMghDlqhAzIh84mhP/GfZX0H3IgHGqZNwIHecfAg
DHLiOUhNgU2Hrojh2PwhIPoTIIFNqcmPEbb/IdwQFCBNh/yBITwIINyoWhkqWiZqSqCNVgCNzyCi
og8Go2b54A7KkZ1Vh6iYYSHtIa7xDxSSFv1cohv+4hT6IgDhzz11nHn8Hq7M3ftUDQyWijE+oqcQ
lAaKo/9UjcaByqj4DzUekv34zyB2YeTpntW84zASW/3g4KbxIzFaRKQF5OrRjyL6TwxmY/w8IgAl
HXFMIqWth0VsoibmYCdWpP3IzcaJYs350SBOWjOmIh6FpP+8zTUCUnooo3aoI7EJC7ORAi5a5Cew
yte4A3Z8IjDyIQ/+YOTxJEZU4sGFofq5XTMqITQCoiVAoRth5A/4pCJmhyXgof0gZQQIC2vt/9oZ
guEL1tz3EEeomSH/lMp33EC/HSPOccIc3t1xGBmhWUTX2NGt5ZE+euJUMqQhqscctsNA1mNEqiUO
NKMhwUOgfcdCnt/3EIEtHtJ1zCJFPiNj6mJjXqQfDR956GJe3iQxaqBciuQe0ePfmaTEAWVd5hE8
hE8a3iI6euE49B8XXsKsAMvlydEw6uQO4lwxQh4gpUqrhEpQ6lPzJeHnLSEvyoq3TWOgXZ5FxJnV
FEHXQJom2t5r3ZMAqma4haMX9l/taSUgLkfrZSf/rGY/dc3+TNSs/GZvWhRCFQdb8t5dnpsOjOdm
BgdA9WM4Ss36AKHQxVE+KaPcpWfzKaDnzf8HOhDmepzjHeWgCcLKf2LiEm7irPieRbIe2wBS8G0l
bJbPKfJhYGaocOwReS5nqelmSg6nPi0gJZ6mDnBjapZdRDHfZcXctVnWbAojH3ZWRNkmAMFWOYjf
06QoVw6HWTrjY/LiZZlHLmYHjMaKF0IHi/rlfOzoodkoRInfclbWVeJRjaJerujKVjbfGm3pgdbo
//moqLRWzJUnbKlNtHkmHYaWJuRTgJUWJ2gmZ81KYaJoaNXpaMFoHO3pLiafk/pbaYbKkx5fVUKi
4mFWgFUpkaKeRF7kgmqp+AVnDF7bnZmDjbqNoSIpZpqPZmpmmb5WZZWacuzop8BKmCraOc7/WkfE
A/b1wK5sBDoAmCes2SXET4KRAvbhahTMKpQ1WYNZTazE6n+pGCYomJvxQK/uKrzp3bKeWZPFymCi
GZcZaxCYWRQOqxAAK4Gt2bUG2HdUKw8A66xuq60aWIT16pVtAnf6wLWm67siqxRE65kdma4WWLp6
n961ILsaW792mlf6KxB0Fr8GLJOxYMEibMIqbJoNrJwR7MJCbK9FrHbU6sR+j75abMZq7MbSSsW+
JMeCbMiK7MiSbMmaLBO44Mmq7MqybMu67MvK68PC7MzSbM3a7M0qbMri7M7ybM/67M+irMwC7dAS
bdEarcrq7NEq7dIybdMWbNI6bdRK7dRS/+2bCW3VYm3Wam3U6qwE7IDXAgHYBoHXiq0EmO3X8oDZ
qq3YCkHZrq0OgO3anm0AsK0P1C3coi3czm0OxO3b8u3Xym3Y7q3bsu3dBu7fhm3b9oDh6q3a4i3d
+i3d8u3bxm3aPq7kjm3aRu7dQm7hNm7eJm7nDq4TRK7dYi7g+i3hgu7lli3qHu7klm4SOC7r7u3p
/gDnrqHlPu7rGu7ski3inq7n6m7jUu7wIi7n4u7k3i7otu7xsu7lQu/z2u7iZi7wzq71bu7iym3t
Tm/vXm/wAq/10m7g1m3zTm/wpq70gq/zii/1Gu/Ytm7ysu/yDq/50u/5Iu/2yu/+ou7qXv+U+4Zv
++Zt5VauAOPv/XYv7Bbw+w4w9ZrvAwtw4b5u/f6t/gaw5vqu+kIwA5evAgOw8IouBg9u7YJwBH/w
7hLvBmOuCvsv+m4v+/6u6a6w6GawCE+w/kpw7Oou4aavBa/vD2cZd8Zw5zKv+xKwCbsu966u5wrv
C58v5AIu2qpw8z6wElfvDFdw/wIwFv8wD3vvDdtuB0MvFVPwBZdwF39w+iLx+rJwCn8vF2PxEFsu
BOdwEYev/C7BAmfx58qwC1tx7rYv45qxB6tu9MquHQNxGDMBGSPxBuOwFV/vAtuv/0qyBhuy4hpw
345uAYtxIityEl/y9xYy9kayAk/yII//8e46Lu6Wbymjchc/Mg1PcANbMuwi8imzagDL8SfT8i5P
wRDrMRzzMhJ0cB2rsitHQSWbsSBPsfoegRj3rRHjbTDz7hxf8hZfcR+38TNvMQhzMv6+sDKDMzLf
cRPgcCOPLxrvXR638Dd7cSTHsjVf8O2esw3PcgszMPP6cBKf7Sg/sQw3synbsw4XLDALLh6Trgbv
Mz9zb+m6MzHz8TwbQT3L8h8bsiivsRfvqz2/LzPvMQJD9PyaMh6TNDdnMzbnczmH7kpntDOj9Ehz
dExrb+wyMumCcRl7Mj7rtC47L0JL9DwLMku/9E5rcy3/swsyc1AT70dT9D9T8jAbcEgT/7VTU3VT
Gy8uw+9M6zM5v3RQK7VSv3Ix260Tc7AbjzAyW/VQL/M093Fbwy9ZV/Q7W/QykzVGR/RRtx5Yp7QU
X3NfY3JYL7Ja/3RVK4E3F/ZgIzb/ovQpn/EB7/VP+/JFS/YV+/Qjk208y/Nj+7RjD3Zlx7NeTzXu
MkAL8PNf/3VTp7Vbw3Vqt/NCU/RrLzRlx7by6u1JCzYrzzJcw/RYEzQHnzVvi/Js169wa0T+1rVw
o/Y+s/Zb33NotyBpb210S/d0G+1o1wB1Y3d2azfMWvd2e/d3gzfHdnd4k3d5m3esjfd5q/d6s/cU
jLcTa/Lo3rJAQzZV+/Vmi/BEV+9X2/92URuBAAC4AOgAgA94gBd4EBB4AAS4gSu4gB9Bgjd4gUM4
hPsAhR84ECx4hu9Ahlu4Eiz4hROxX/P2Ejc3Udv1Y9+3UI9zidc356Y3LUtxQ7u05AY3W/fvKtM3
Z4v4Uusyjuu4P39xP+94gnN4DhC5gx+5kSP5kit5kz+4g0d4lCd5g394lEs4g/dAh284lDt5lnO4
loO4Nsd2QO+0RW+zjBtx9tKzbv/4VcdvlUE3DJ8wQ89tNct5JzP2ZG/14TbxVb8yF+c5TmM4k0v5
klf5lCM6of83lCd6lW95l2M5lXu5EHw5pQv4hFc6gfuwYhu1LIcuK7u0HiMvUKu4Xp//MSNH9osb
NA1HryNjMArTOE579UzntkqL9CeLtQdHNWdb9ZEfOqEnupMH+6L7OoNP+aNbuYd/OZczAYFbuKM7
umbLeh5L8JyjbxQ/cTBD9myjdhkf8ZHFefe+8bhL76gfr4/Xsp238xKncgLzeCCvsZ4jAbQzOpYX
e6MbO7P/wK9feZgLu6Ev+xIse6TzgLNz+bCHeGdr9TET90STsEnvsFuD9GGH8LkLObhftwVru7i7
MnzD+i5XMSQ/vJ+PMVf3OU+Lc5BHtsDrO7Ij/BMkOZh3OaS3vMwPvMwjeMAXupOHPCL395DFdzgD
9Ij/vGV/NBsfPSmEe5qrcSc89Hxn/zut0/QbqzaMn3ZfUzFmTwHCD7ylbznOV3i9X7mGN7vO57yX
Y3q873rbjrnWJ/PQD7XRT7wco/oTv/htL3Zpf7y7I70WT/xU8zSsu3GnC/q8F7m/DzvOg/2+iz2y
z7zitzyVR3vYLzo77/rGr72J67etC74tc/w64Hm5J30uK7zD13U3v/mNX7zHqzglC73eNzaQD7R8
e73jd73kH/vtJ7u/F7zOEzymV/qk277ZDzraH37C6/j95jCL2zcQ1zPrQ79gOzM0Y3us80DK5PXP
l/WfZ7b2c7zGu73mQzVhb37z737aOz7lz7zw9/7Zpz/7L/76oz+x+z6z43zQ3/Pvrv/6IWcuCEiB
KAajiZ7pWq5o2b7uHM9unZLuojC5BAy2hMIbEfgr2mRLpg3XjD6lqhcxCr1ZjzOB9ytIgcdNL2oM
Npm76HWg7Waf4ba2mE51wcPLbN8Jc+RXRQNoIjiY2CdoxPXXhMPjk0dZaXmJmam5ydnp+QkaKjpK
Wmp6KiWJusra6voKGys7S1tLqmqbq7vL2+v7CxwcgCtcbHyMnKy8fNvD/AwdLT1NDUssFZQzckW4
nX2YOeQ4pEU5uKXdXYW4sqeG9sZnmpYXd2f/jh9v1x6mL/evnrx3ZQYKzBSHXz55awLe+0JwIUQ2
bszAizenosF9F+vwucbuD5SRLMD/lTz0TV0NcY7QKVFXbh3KloXu9ItoMyM9jmQeWpyYZg/DhhDJ
7Izy0+jGORwxSjyqBw9TnDp7OqWicapWOVcPOrWHjyhVnku3LiGK55pJlkp0xEzXtlwMGHJT4ljp
JO8UkyrubuFmVuzNsQH1afyJMyvGpAMZF6QatOziogYRI62M2ezXjQ4HXwXrz45gShdBR306mHFk
rJkjqu1bci4jlYQCjYMbO503wHzvzja09vc5skA5U04tNWdT5YoRH3V8NnQ/ywCP2+xM3PTYzVEV
ek7Y0ePTiVw/h5862vzjy6ddOzs5FzjfbuTWysUtf7hu/TSQ6O0fEmsPBcYHduNp/6feZFYRt153
UPm04GSV/KNYTgY2aBpoFU7YmGTRVaiaTgS6o9UaPCiwwF9x9aZbbfDN15tdetFlzm/GiNahVRce
ViB59MAD3WZhCUUQdaetdqBkQg2FVo7nCdTkktwtx1prnCSFXEQXTtcjCgygWFMS2iDC30y8vbUX
mVmsRCYLjKhp5kvZkdeeFCQOSKWWxRUZWnN0kiZdYX1KV+eVe0bHpXcLbSced1LaOaiihuqJyY/y
fJkimpeMdCaMe0ES5iOe+IUNopBeImiTN4nF6qCJ/VmVn12tap1nBSnUaoOodgmejl3OasmWDvZE
omBD4srrpWBqGpJ+pLa4WzZ4Uf8x3LOQ2OhpgIUyumujjqkqYj6L9rpUhkNNGSuhtgLLFbm6cqsc
lQjulF6V65qqWYk+GpdluAFgGic3pDqrBZyfenqwigJTy/BJXsWb6JJPcrloow5SVK6VTNVLa5JG
4luex792S5iHHD8G3sPwOjTkvcoBTO1s2iqsCZs0/RfzzdGm9N/MEM/JypYsK1mWpNd5+HPI77p8
mdGFOo1echlNDfSwD+ar2Z3lwVxN115/DXbY0XAtdtlmn4122qSQrXbbbr8Nd9psx0133XbfLczc
eO/Nd99+r71stAjjDG3CMOU2U+GFv6mwf40j7NuKKs7Y6X4z7uf44SesCRPPirj/ia3DNeqs+Hyc
s1R6zz6nrjl8L30uKi1cDxwmYM6GHheNMiVOuIvZJuybpprzZq3D9eWl+/HbyGAbXc/WZzuoB7Ml
p/Cmx05C7tLzPnj38Qn+O4vGQz55964wMEn4JJFfquj2bS4+bPG/Ja31zb+ouB/KF5+E49+4Jb/d
yQ+A9nkeOuRTsOltr2Dr856Y4pO9hcVPf4f7nuXGFxy78AyBvTtf+sCnuwu67wm4K+AET1iI462O
gOIAh/8kSD/QbRCDLoJefkyIGwP+bobzQ94CrfAD0Z0OgQSMCfU+1UDahG9362tgEmeBvhh2Dmdl
cuBu1pG55KkOiE8UYRd9WJfM/1kieuLTYhnr17/OZTFOWwxii2A3xvwxgRxFQN0Ns8UmIRqxEf6D
0f9qFyoopo9xU4ScGH+InyIisYMAstG0mnczC6LEep3Aix3L6ELLVbGQcVReD3f2OgFS0Ydm9IYA
N5lJPy4OEM1inxpRGYooNoyGrAtY9WgEwFZ+EpSwpKQMK3et1dkSjnuEjQUVyUs/ilFNdOwZI6fg
yVI185Ss3CAzmXc5Z+5SeNFsXStkqT7QUa6XNXGe9FSYhy8ukHQj3FnsKkFMDJrzevwJYQedGM5G
hvJ9v/zjNNGJQsMxEVo6FCU/uWezXIAzme7E4ori2chUMtSUVCwhIlf5TCWiie1TLYGoG+FHn1cK
jAvxtKQv04Q4ac7RoW9c4ztDGghm7ZOhtwnYQWGxUP7V0p7tVKn5AvnTzVHwpZIkKvCAyroqIhOk
PX1pLefYpvYJFKlMpeo903lRQDbVmzz1YP+qt1VvDhOrY3VqgLLIUeKdaYXA9B0fXyec0G01rWBN
Klk54VFf5tV89cyqEeXKSHKCYqF/K6xhD4vYJRA2sYxtrGPrttjHSnaylPVaZCuL2cxqNm8f3Kxn
PwtaQYZ2tKQtbSnQh9rUqna1rG2ta18L29jKdra0ra1tb4vb3Op2t7ztrW9/C9zgCne4xP1tCAAA
Ow==

--=_NamoWEC-rk8v0jzu41
Content-Type: image/gif;
	name="201407220829448_7EUABGFC.gif"
Content-Transfer-Encoding: base64
Content-ID: <2LL5XOK0LK7C@namo.co.kr>

R0lGODlhCAKQAMQAAAAAAP///8k6OspMTNRiYtt0dOSOjumiovLExPfZ2fvt7f/+/uvr69TU1Lm5
uYyMjG9vb0dHRzMzMyoqKgICAv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEA
ABUALAAAAAAIApAAAAX/ICOOZGmeaKqubOu+cCzPdG3feK7vfO//uYBwSCwaj8ikcslsOp/QqHRK
rVqv2Kx2y+16v1YReEwum8/otHrNbhcX8Lh8Tq/b73al2M3v+/+AgYKDVniGh4h1egyEjY6PkJGS
k0OJlpd5SXsBDQ6engwNjFKilHoNSaVYqkisTK5CoUqdo02waLJMubGogg6Nt1S/a3IIeAoJmHAJ
CnTIipq1EBETFBERDRHDUdqmSQ8PSd1GENzbR+NN6UPgqRPYr+Hrae1MDhFE94MUfA3hRvOKlHPC
z8xAIXIG4EFQAJGBOQWMzWEIDckmIfqEBFR3zhuWgk82DhGJrmOAekcy/zJpR5IMSiUqA8T8A5LN
yyc1l+QEU9MSxUMKD/2cs6iIyggQKExAxSCCtVoBmlKgIC/pBEZSIzBw8I/ryWr/hDSYRjUpvq9U
ozpdGiBp2rZTyzUAO9BqLyHt3IZt22Cs03Jm0YbzS2HgA2sTfj0AixfxNqlsszLqtjgtuAfDMA+p
BlgpqgdJh82d8ACpZ7VPiUA4HNlp2tVKHVT7NbewWKUR9kpNy4Azvt6F8SGdIBg1W71C7CY/rTru
ycr/kiYlAm620+hxm4o9K5ax5Las+04gvTschL5kD8LFBmFCZ9twp8NlO6S21uJfE7dNygD6+kpx
NGTAAQMQkIwCBAxggP+AySTw0AEJPmTAAAU4SIABBiQDIYUKDCVHUflwd81JgJWomlz8UMMABCay
OFdyDzBAgXh3OTBjA1T1JsqNS5VG4lxbEVeaCEut1hQ+i/VHHDsPACkbEdrYuGNfFDggI41SXnml
jVbyiGWV7CDZYjnaXDmXP+CcNWOY/ly12En3xeLiiKDtZ+dISOLDIicpCucmPuTlFkBiMu61J47g
HZnoiFWK4KWPoDkppJuTKkmdVjomieiQ8uHl5o38DKkjW3Vu5gCOK5pIp1YuHpqiJzNeWV+VNjIi
ao+shkoplPLE6OWVbyLlKI04bpPQAgU0dICAByiQLLLGUDSAMQMkkMD/tAgMoICzCChQLbIHeBgH
iEMc9Ys+a8pIhBg2BiCoumsiqh8F/dUVVkYFaVPqaj6KIBsjvQCcGL0yCTcMfc8ByQmUnpzVTaj2
ZqTvQIntCw7F2/TLSLyvWgyOjEGG6O7BaBbB0rn4pFtTN/qw++pzBb8Y85KrrctIuwT7mHPKeNmr
8b8Lj7OU0HdFxUnF/7yMKJMFC1GQwA7sqV93GMmKKMtIhuPyyBKfw49KUHdzNckjDUYijKXKo5i9
AfQUh0IRLSBtM8tCK3dD3yazgEI/xd3ggOLCQS5GIqLc9lRTEWHfy2037jR4Lx6G+L1qasQV4jlS
E2N8TK01MOHuYp6x/3mFFR2lw7+EijlmqNej7+quP6b5xkN0DHuvNZdrsOU3ndw05isbvvjIMN9j
I+LanPXS8AWhC3pBkk8V4+ych474PaIPARnSj49TUzv4GpcYkDXFBNLL+rQz/OmWE/H1Wdsb3332
3QkaPVUvUba64wi9bbe0cKBI3CgCobjt7W5wiNuECECAcDWEDoNrWvucJxYiTO1l8MLK19xTjnoU
LXwj82BUQtGeqPiDXnsaGcH0MY6iqa8/BLNc1xonwq7FToSx0x4JiUMwdenrH58JB2jWpDviDYor
e4EZ1vhnOsNdkHjgS14stqK8vTyxeTz7HV6AOMKxECcUh2mKaIxYtP8U/rB7w/heOMJnxl9wUGQy
AVlU0Je1QSWNa6hznwTb6D0yKq5g/KpgPdQGs4XxLwDHGiDeAtgQRS6AGcs6wAH7hoBl0c2BFTnC
RSRIPBaucUlOs1WKOigcIZ5lPKgAmqBA57goXcVdoNEaVU4pv2KxSFH9QthlaDmShrVvg5NhneVe
VCxVYoY4xRpCzXxoSq69MjftkBEoQeejTSXRd56UyTSXmLOXRbFtnynHmkjjPlHCsi2lRKfjjLnM
WQqhYr/BVVQQJrYq1QNiJ1GjBJUGptAUgV4gs9/u0heObuKxfbWTYD250sFQxfMuhLqHwnLzoiex
7JkFxQgi/efIAkj/ckHgWsCyEkCAZgxokg+MyAEegiBMQjAaRilc03DklHO0xz30okY1UEFTIjpF
meOZJgi7cVNkIiZGQcWHjaiRG+BMY57UUM/HksqwGY5nRUFV6C+KutWstiWo26ApOXuKCqJm1XVJ
bNl4wNS7WQrPGmDqZdNuyh/KrBFJ71jTYsZjqPHwR6z4GM07+FdUPs2Oqr2JKlTdkw/EQPOOvckr
de76uKW+Y4072SuKnFJWwx0GNH7NqS+N+M7EnMWyTR3PTxPLWHYc9avjSc5sjFjYQV2FH4mMVkNI
ysCGZCtZAiJAAQy0AAZS0lvDxVDgFhDBJpzKCH0xSi22ApUidAIK/9eNxXMxcpfsnsRW3NluSoqm
BytxwiT5gIp342iErdyFutA1CcLGOwvylsu+0MVvfGsR3fyuq2i7sO5jxCtemXzQvutNCXbPUSrr
vte8reCpfjUJYbF05ML2ha+F84Ff71I3HIh4RhysVQyJLKBDzZgDig3RXI9MYTGHQa+Ln+CXGdsY
DIuR8Y2x0B+PiEAZQA6ykO/AJB0bYchITrIcFNAsJTs5yDvOgieiTGUt/BgTzLhElp9siS0X48R6
C7KXtZxiMSNgzGM2hIjn4OU1TyTMSXYzi1NRXezWeRBGhgkYaHNn66q3zyaUQp4DrQmeArrQTbgy
HB5yCAMmwtFcbv+0if13AEkKudJAxnSQfwtpSN/hIct19HIN0EAlg/qBiDiCP0grhZtoQTNLWJFO
qLATLYQqiSVhWBJm0oRaxxQmu3tCOXitSQYcS9KX8HSkM23pIGsaE89WRrQDNOk7BMUOyqZDtoF8
bUscwXeEaAkrk+BrJpT7CucuwjpIQmwstHvcUHhfoo29aAqJtECWJhBxC7DAZAyoQAcqAIfs1u9H
ChxDzoJDwkccoQSSesQLGoAkLYShBBQgxRlS1sQbfm9+N4jj1xJusx+ZoH0T6OKPLJBHi8FASTpr
4P82EG9XqiEKEcAYG5p4xCVEIQedWOASt9syJKTvBBT95SjHULX/Ir5Se9+bQxOqEEsFnvSij0sy
siGNaVqTGhY9JRtb7Q/pyDkfF1ZmbVWqTUOXovbupOUvZV9OpwqZNb7KvSDKGWJYq8GW3FhDI4ep
HPjsXh53WWUyilHKXlrmGsw00ysjeY7d10NFvnCiHE7VE3rgHrqnKtMasuE8a3RD75SfWebaIqnR
CYAsZT3kWXXD0AJkr9KLQ2j2BnBWQ4i7Ujk0sKV761YcstUsbWVrWxE5KUkPiOnfe9RbHZpWcZu1
8ptfa+SlrlvQq3/moMfh5seXPe2VdfGKR0T12Tp9t4xfLW9ZC1sCesjyRd1I8jurWeJ/fe6z9f5m
ydzk14IAFJF//60nUqhmJ7c0J2KCgGQCAWJkI76SMFfxJEPyJK7VCUJyH+QRKEg1PeEwPvSyGP6g
FRSYK5P1OEnSLpziUCHzJhbUTIXRFAXlgIJya0dUK4dCHCqyJ9pwJqhSRK7CQvyQOyg4gSyIFCxk
ODxoMFkyIyuoOLQSK/TigzE0QsfSe7NXaYwmSR2lW3vTIHDDEJZmINqCQLJ3cwzHSAfEcovmUrUn
Ug+hEJWGAKx3N1gIfnXIEMuXhUt2YtoHB5W2hye1DHnofin3PxoHLXdYSYwGOClFLQi0LXIThsPX
SF4YN3lDiT8RFH7zc5LEN3gDhog4LhyjRIajMlCUJlIEDkBTVv//oEsUUzIWmISziA2vZCXZNChg
xycnSEN3VE/npIs3gRU6k0opY4y+KDNWsjWr1DFsAzpbww/WsIsJdU/EsxVJ+DvgdVAj0w3qokc2
9IxWSGkDUI4SF21diEDXFoYGFBFBQRGq120/AUDF8EBz+IjFZTdyGC7mSCGaFhHZYo4RYY8jp2/P
EhT3CIjN5iHrOIqYplKWplL96IaQCI8JInBCh0Dp2JCOtIYKVCClBopreEAdyVznY4q/gzmdhBQw
JkSkcx7WMxWjwzuU1TRRgjlSVESuIZN9xDS+iEbzcz1t9Q5ZREHOw4rccTRwZUS2MzlFNDyJ4R7t
okfWmA7ZaJT/TIg6PZlQNrQ/U3SFlqYh+TaKjlSG3gItBnRzZfgTF8JoAZSHi1SPCklJ01eG+/gT
27KIeNkhBMlwyUCPCSlSC/lA69cMZ+lID1lJEamYy4BA+ohAaEiSJiZAl0gthqmJD8SJlYRymCaS
ZomZpKhBKElBQUMboAd6MANGQzNGPnlGtciN/nJalddCTNmLNtg4fUSby8MWWLlOPIOUVfNE3tgx
XFRETzQNuUEN/1RISuNL3AQ67NONv/CNXNk6xfmV/kNSzeBRy0eHZHmJklQ3b3gtuKd79VZt37Jy
3TaJyWAgdAkhjLaPXwiH1xJ91KIhcdgMpfaWCRSXnamfI6ct/+63cuLphYm5fAGoneBCl55JN5So
hulIoJbomJrZe8AnkhI6ioIjUKOZThZ1MDqYM2nyTlzxG1X4JtbkNK5IPHolTsOSPiZaL/lEHcN2
m/h0GHAyR2KXD0vCKOZRUD/6kwA1IwaFFDnagxhVRAYFYzaiHj9JQx0EAdnkI4LyVNGpLyYIjqgz
UWGhaMVVUqTGQIuWIMaQjvBIIenZLQxUagiiIIS5npPIQM2wnnTIQKeWQMZwfXAgnyf3LfqGhn1a
cy3ne3bKeggZniBZkHaacgKXDIjJhd0SpmgoqY4ZN8YVXBdSLfT3nYyaphSKp8jVll96po2qocxF
VvlUGm9VU/9G9FMlBDOIpVNSFVQu6SlX9VWXw1n5gSI06FeLVRM09VPWyFr80BS+ehNBVUKI8UrL
SjvtoFmwlRTZsFadBVtCpSehRSW+kkQ2ClUzog9LNSKClZXtIx05MR4zVFvYqXDClwCTJnyJsGJv
Boh0Y49uKQfuegd6WG2WsGJGBwfEdWLwCmZ1MLB1IGfLEGbyiggGm692sLAkFmQLewgLW7EG+1Ia
xgn4lbFOUGAF9hwfu2HlghUV1l/nxV35QGFLgGEwUQv0sg0vmwrdRV7olWCKM2FOwLGExgtLoBlL
oz0Vpjgd4aXLhgcQQiA4F5mXsFxAhiALUodFG7VSO7VAFgj/rlZly6lHWCsMs+SkUUC0VDsHcxhA
/IoI/+pkRtdkYbu2bNu2gTBlW4sE1xS3wnC1ULAJuxBgQgtdgIZEYJC3OGsEnxC0W6C3WsAKnTC4
h8azMPExXICNcFu4gdtegwYgIwZnbftIZXYMmMu5dUBiZbtpSztkz5Bmn7stnXuwqZsHm6ASxLZU
ACFj17AYXhsGHWQenNRr16CrWzBsSbkF6TAN1XANk/tuXwFai9uz2xCut6oJtUsOudsEItgKezEH
F5K5jwSpiDBtC4FqctCZTwandRAuIwlklEkH9wotTKtwDzJyLNa64fW7WwQFPjJPlduxSZluSAAS
DZYF+msF//NgvL9Gbr1AhFNglSKCa3A0awe8SkbwEvg6XNibmMu2XNy7ttu2tN47B+K7vo55CSNU
RNQEHaMxPdLDF150EAjzXP5BGEMUWGSBHWwBFhczjZjnFPfhd3HyONBZQtAha2qhlHKRHusxFkIM
eKlRH3y3efAReFMjwilceJmHGjvcNqNQCt8hFVGaGLJhG3vVCyrBEiWkHIyhHFpcxHLBGUhcxYOi
HW7XJJO3UQppABIRc+5qaZUUB/8omAnickD3UX8zc/wGcCSnIA7XQAdgccD1cwPXpiA1YirHhYV8
cS9HXCRlyODij3KKLFlIyC93jgxkcfVGXHZ8sBHCIJdcfv89R2oVV6dB53Ozd8mVtnGG7CAH9yHw
W0SagkLn4SpcA1AJVQQycipLISU4glSdkCMhuCsiCA7FpCcm8nZ7wb/itIxSeCZnw4FNSCW+xIFt
0ysWpBjacM1nwiUDXCupwotGMiJ7kkLJQVHKNCa9wRWvxIFzsTmcVIOKwcw9siu3BILd7IHfHIwY
UQ6vdESo4iKWW1xGx2iwVyGc2GyaJoclRZ6yR56KpADm53rTd3/Bx2TNIoAgRYADYp7ft36fGFIe
VTe953yf6H+vl9IPjXskR1LFJ1IldXszjb7UZ4krx53YIqAAKXHo94gQkrYd3UD8Z4iCk8sjjIJa
czOvMhP/mRUxleNMMEI0BNU46MJT0ji/tXMNO+U4FlMzFLUkxpNH7yMzOgPWFdQfOTkxJHrO8CPV
VpyjqEijp4GKK1QyyhhsMmENOsXDWh1sS9HXXG2LeJFFL1EzNaOMO2q5y4cgeAqZhanHliafBySJ
2eKQ2ssQ3mmAa6hpqjefZ1mGdUOIbUiSEyfaqAuXHolzMu2FnE2JD2ogJZkQ9YqWrY1SeBrajvjb
GreHK0WXTV0LrltHP7k+o1U70xXZwNlKo5UmorPV8naS0DPNnxDM9yNMRog8M/Q+GUFBLyE512BD
/xDAp3UWzPM8KtleewI8hwQ+OElasuEJd5Evw8A+O1kl/zkh3utN1lb0DowVExAcQBRSqog5IN47
0YK5p5MMmhQM2oTpn2OY2f24hkPxE+BLUivnLL8XkOUYl3EDvo6UyrYtdAPphXTwjpbo4ZldqQJI
kJREQC5F4ZV93Eqsy3fUDmQ31b+bDrFk1YQ93apaQdatjXMk4FqrtSJUKMSREbH5SwXzmtmtxMaI
3gglwhlxRc9TH+UCSqSJCs0ji3Vt3/Kr3ySajQtT5olt5W49F58gb3F04AuKACd14gpSkDHu4JEp
4Z8dEbB9qKIN4Y3p4pWokAf0l/yGuqS2l7H94KC5nymelqD9wcdGmYwehzL+E8GtvhoX2jiekSFc
O71gP/89XlDmFJ1hjhXjcxU6MlSwggryFOt1JG8ceuXBrLXG5C7NGE7h/TsrquvapBFx7QlGdWEB
ftc4WqUeOk1xVSeC8qGwdE/hhOZGAD2BJW/1K1rndN3D7tZE+DDDEk2o4D+q3ZECt7m919kOjtpw
E56JWJaOmtKCWZ8BIkneuXKPvKftmdI3x5cnddr4Gekm7oXw/ph1g9G0DWf8boloCEA13n7uyXre
MuOSXu90aQyl7ilMZSupHq2ixWvtcR2y5R6VJ91Zh/Ksxas+blqGtSbEfkg8bK2N0QuLwVlWBfN7
xaxubVvuAfPEw1V0ffJ/5Vgxfw42ElQAA1e0cVb/kPP/a9Iew8BrT7NWpumABJ7GsWVb6cP0TP5O
d1En0PpZ7QCI3qstHZnakJwsmq0QYToh0bfIBLIsBrqmc6qQBGKO3SdwebqmDb6mKX1yDXQtwxWe
wvUtminpoxj32vLoCoEgZOrZ+Ar4imhzknSpv72mjAb43TcgiC+nDMpcm+RetjC5FlY0NhtT6yVe
HlZhOksKOkYLFlGylRuy6YVdAEaz+PWxrl+zFYb7SPD7KCuyUWH7VGCyJosJg7hkoZuw+ApnEctm
z+8MZxYHCPtInSuvHRJm7rq5WgZn1z98q8tkKrb98DqxI/auZeawy/D8ktTxjSDAdFv/9n8EhkBq
4I+9//wPAos4kqV5oql4KKr7wqlyLAHDBLm+873/A4M5xkNoPCKTyiWz6XxCo9Kd65CIYbPaLbfr
/YJdNkZYlGiV0yTEtYSInU8JBLocV8feWb25ruKLAOJxCboUqtxxJZosdi3GCR6eFNo05DQ44EA5
TD01aB4xWOrcpB3QDJYZEKAuHLwNxBQUKgwUtH0l0MymjryexGYFr7Se/A6LIPcKwxxn8cYYlECT
/FJ7nVbTKMcqSKso1zhE2FBEjD5RdDo9FCGN75Quz2td84bvFZgWL1974ae4R2+gCH+pAE57Y3BL
NhP4EOgDZyIAPHhS1K3L6MPiEDK+BhC4oqCArRYGDv+AnIMKwaldKAu0eGkA14IEBAZ8K7DKFyp9
NkvWvPltxE9pKEOuSIkTaNESM0/d3IVzgYGUrqoiOAkSwc03I0G+IsBqJlWrUFk5ZSq04EtXKX8i
1XcWVVWkZatqW1DgZZ2jCZbC1Ot2ajWrXwNrJcB1wJvEixUS08tXcNnAcHWl1HfYpF8SM7/aTTq1
6q1VBsj69bs34kgSe20V3Fn3yoECYmlkW5pT72ird8NRJBeBAoQh5GyQazCBeI7j7XYQN4dDOYUJ
DR5wCoA9AITq6LR3d0C9OMUJE9x1t679QQRNED4Nb29jOYTjHYmGPECAqrTTevef9hdbubn0lwII
MEb/AisKoMVYX6jEspdkCywo4QgLVsiCCCOxMIBLFLJgYUEsEXDgfvrpApN+rgRWgD62zaCPfwIG
OIt+M5xYIoLVwKQTiAxuU+BeQLK4QCw37libiSx6gwyBE244pIcTxjLAGaHZpAuA/Unj4n8x6vVi
ibUZGdmUEh7ZozRoKSklf296SeYINso1lJFXJvAXAggqMBIb+ZU45CxIHWAnThwaSYeSKyJ54jYG
IHpkfjBxxSReJQSnnXo5qPdAcecxcF4AGD2nAwVFRFCEqOx5yul1EzDgwAQ7sIcDqKkGMIEDDlBA
RHuyrgdBEcpxVxwExhYXgX1j+PLNNlcIaGEsitUy/8M2xBQqgmL4BaKPMg1FSAO0+y0AEbflvgiI
QK5YQa65c7IEIbpQ5tfTG9mY22e5R+6SFSqKgeuaV392Wya7er0hEpn8JkNvArwIyJPBDY048bVW
1lSNs3fWFOG9NJjLC77emlkyLwcu0AKYAmEc7RvvjkimviO03PC7Nm7Myyz+bUvzFeYGYyHA8ub2
M8kh//twwsBVtOyxue46a6akupMD1TbYUKs6wArrqg7PARscsRQFgGuu12FHTqsUWMKAOr1qt6w8
B9NcNzRHniTXtew2RM27QJcQsE1oITiA4RHNO689sBBT+OECBxyyHjbae7C5P5F08CzQUN4wvCP8
Tf+y5vfe5CXDZZJkOGN35xUMxQhbXKZ+17w+jMeWp4t77K5fSztIXrJs98uIIzzSgtUQwPrN8QqM
cJbcFBz05MzLvjfgIau+uh5Mk8NRAMo1sPVx8Fxtag7PPVCdsme3OhwF72e3HkXvvx+B9+7D347b
ZXNC//uj5sB7c2vINlR2uzL95SQH4122KMSHSs3rW/IymgHeNbNyuSt3n+OdBf3QuTJJTlvUExnI
9NEzhm1OD0PzXMXmAEHAja4WRqtew6BxBdZJjHfN02EszlCbVhDQSAaE3ciIWMLdmSxhf5ohy4bI
C5gVTwEJ2AlRYnSt5QVRZ28ggH9IEAwYQmOFNPz/4tE0eMPtTaRpPJjA08JGvvNVDYDrAV+mjqUr
/l2CVkWwyA0skgn75fE5qYIbRr4nRwF6JCgYnBCZfCSnm5SMXQZCECAwhqbASWNH2wIabQx1w37t
0EydhJy8zEUmAfXtYxGMCQpZ4pPTOcko0rDk3rIxCwiajm5pStkAZmAUJ9WyGOsqWomo0gqbLFJC
jVRlCItISyRmq1C4zF24ivRE4u2MBrXAD2dAGJFZILNSWiyLIKakQNe9UpcL/FAsTKmZXkazG7jI
lPe4Q4HssK1sRcin2awGx7CtTzlSY085QFGqfK7tBmwjqNuIUIQHTOA4uAIWruoTj0RSpSsdI8kN
/8ViFznlJjJH6VkgQFJMZfzFRUeyxbZegjHQmbQF11jFjg7mUpp8sJ2a8ShuKlfEVXDRSiipDR14
qs4RMIij+xJLC3RIU9twcT+wTBlUpZFUSOYwMiOgKQ8zahuarCJBKbUkM3P3U7FccoEpSx7GPCob
xfTQFmRN3IhSipatJg8pYlleRhP01JeFg6Un3ZBRA5abvDa1Y5Cq6lpto9MR0HNZ8/uaeWDFHfP0
U47PqSwEpGYO45iHPHA8nzkQGlrknPY54XNH+IbDCYFG9KJuqMOB0HDLOigwBbrQFk1qIokNAaK2
SKUDI35brt4C1w95QC4iaJKnNTC3BMI1g3HZcP9cGFgXdISIbrkOQdzkeuG5LphuufyQ3ZR99wUH
Qu6ehqvcQNThvA30Isomwd3hFjcQNJGEEFqlA0zsoAHfAUImgiCeIMQKFALewYERXOAhDJhZsgDE
Kt5LgloYwDYE2TCHO+zhD4M4xK4gad1EPBEgQDR+GllxJ+b2Ag354r4bOoWFTWzjG+M4xzouQ3tN
wA8bG1jFLB4yFG7QA1HEI8JENoKQEaxkIHxiyQaWsg+Q/L0m88DKQ9ayk5fMCS4nAcwQ3ggUFkyK
J1P5yGhWsxKw/AQkRxkJYjaCkXVQHO/VM81AKGQQ7ixZIQBSzzzgM5X9PL8/2zlTRM7zRhC9DnX/
lGoJkdajDwg9BNFWuTiTnrSgG01nTcfRCJbehHCwjGkdMFoIdfZnqjsdhVG7egmwHjKfOT1oRQ+5
1Qx2dEZsfQRf+3rUuoaHr2P9BF3rWdfC5jUQVt0d+0WUOQ3QNH14ANE7jqc56UuVeXAwSG5b1jmo
2ra3kcMcTUnn2dM2t3yE5Z0dvGfawzk1RE/1vc4eqzuiqPa02diDb/vTnpvqjrSXI596x1He50a4
Pc/xHvOUygFVe7as5n2+5cSRAcNRj8alw530cZw+yal22TqLavPYWz5lA0XH2w1yWd3ze8tRj9oS
PnNLfHs66kv4zmV+boykxxIYF/h3MM6eoT+H/+AZtzi6h1WfUz373sPx1GfXzR0BP70466YOet73
qVOpluQ53wE53K2r5XDC7DD/cnxwECrilN0S6Uv3Zxk+DokHMNRVVvA9eWUJtpGvf+hw26ty9QCN
7/Pw/sbVqUKVrH2ONuWQP1aoMsHPB4RvV2VHVtnUtiz7+Z3wpGAb+HjlbQjYSvHY6RUoTIV6xmuK
CLOqVagagKtUEZ6OAWQb4d0mHutkfhwMOFb4tP3fvueT96TfVNzAU6znr4+gwtI4OW61zwfPD/PW
6drYcvC0p60vArAi6B0JCuk4lp8ckoea29BveVUdHvYQlb2mXkV/ykocVsBqh3JiJTXvo56u+P9e
6ZFe41mH361W7VkE6CkfJlSfePQK7VkHRKGN4SHeqIwbdHRe2YyfcAhHBz7f98VfqTWUPmVe7h3g
OWBEZv3AqgHQAmreqFjCd/iX9p2P+jUHJzzHCuog5MnP1bwNDhzYDMIe+cygOgDS/cQgHp0PeQgL
DMpcE6ZaPr1RoHGczI3DsDjfx6GaREmcE0IesamK5bWe+OSgf3XNDY6BDJYDHpEPDrDH2LwRg0nN
E87K05hK2yBhD2ZK25if/PxX1uDgHNVh1YyNsMghDlqhAzIh84mhP/GfZX0H3IgHGqZNwIHecfAg
DHLiOUhNgU2Hrojh2PwhIPoTIIFNqcmPEbb/IdwQFCBNh/yBITwIINyoWhkqWiZqSqCNVgCNzyCi
og8Go2b54A7KkZ1Vh6iYYSHtIa7xDxSSFv1cohv+4hT6IgDhzz11nHn8Hq7M3ftUDQyWijE+oqcQ
lAaKo/9UjcaByqj4DzUekv34zyB2YeTpntW84zASW/3g4KbxIzFaRKQF5OrRjyL6TwxmY/w8IgAl
HXFMIqWth0VsoibmYCdWpP3IzcaJYs350SBOWjOmIh6FpP+8zTUCUnooo3aoI7EJC7ORAi5a5Cew
yte4A3Z8IjDyIQ/+YOTxJEZU4sGFofq5XTMqITQCoiVAoRth5A/4pCJmhyXgof0gZQQIC2vt/9oZ
guEL1tz3EEeomSH/lMp33EC/HSPOccIc3t1xGBmhWUTX2NGt5ZE+euJUMqQhqscctsNA1mNEqiUO
NKMhwUOgfcdCnt/3EIEtHtJ1zCJFPiNj6mJjXqQfDR956GJe3iQxaqBciuQe0ePfmaTEAWVd5hE8
hE8a3iI6euE49B8XXsKsAMvlydEw6uQO4lwxQh4gpUqrhEpQ6lPzJeHnLSEvyoq3TWOgXZ5FxJnV
FEHXQJom2t5r3ZMAqma4haMX9l/taSUgLkfrZSf/rGY/dc3+TNSs/GZvWhRCFQdb8t5dnpsOjOdm
BgdA9WM4Ss36AKHQxVE+KaPcpWfzKaDnzf8HOhDmepzjHeWgCcLKf2LiEm7irPieRbIe2wBS8G0l
bJbPKfJhYGaocOwReS5nqelmSg6nPi0gJZ6mDnBjapZdRDHfZcXctVnWbAojH3ZWRNkmAMFWOYjf
06QoVw6HWTrjY/LiZZlHLmYHjMaKF0IHi/rlfOzoodkoRInfclbWVeJRjaJerujKVjbfGm3pgdbo
//moqLRWzJUnbKlNtHkmHYaWJuRTgJUWJ2gmZ81KYaJoaNXpaMFoHO3pLiafk/pbaYbKkx5fVUKi
4mFWgFUpkaKeRF7kgmqp+AVnDF7bnZmDjbqNoSIpZpqPZmpmmb5WZZWacuzop8BKmCraOc7/WkfE
A/b1wK5sBDoAmCes2SXET4KRAvbhahTMKpQ1WYNZTazE6n+pGCYomJvxQK/uKrzp3bKeWZPFymCi
GZcZaxCYWRQOqxAAK4Gt2bUG2HdUKw8A66xuq60aWIT16pVtAnf6wLWm67siqxRE65kdma4WWLp6
n961ILsaW792mlf6KxB0Fr8GLJOxYMEibMIqbJoNrJwR7MJCbK9FrHbU6sR+j75abMZq7MbSSsW+
JMeCbMiK7MiSbMmaLBO44Mmq7MqybMu67MvK68PC7MzSbM3a7M0qbMri7M7ybM/67M+irMwC7dAS
bdEarcrq7NEq7dIybdMWbNI6bdRK7dRS/+2bCW3VYm3Wam3U6qwE7IDXAgHYBoHXiq0EmO3X8oDZ
qq3YCkHZrq0OgO3anm0AsK0P1C3coi3czm0OxO3b8u3Xym3Y7q3bsu3dBu7fhm3b9oDh6q3a4i3d
+i3d8u3bxm3aPq7kjm3aRu7dQm7hNm7eJm7nDq4TRK7dYi7g+i3hgu7lli3qHu7klm4SOC7r7u3p
/gDnrqHlPu7rGu7ski3inq7n6m7jUu7wIi7n4u7k3i7otu7xsu7lQu/z2u7iZi7wzq71bu7iym3t
Tm/vXm/wAq/10m7g1m3zTm/wpq70gq/zii/1Gu/Ytm7ysu/yDq/50u/5Iu/2yu/+ou7qXv+U+4Zv
++Zt5VauAOPv/XYv7Bbw+w4w9ZrvAwtw4b5u/f6t/gaw5vqu+kIwA5evAgOw8IouBg9u7YJwBH/w
7hLvBmOuCvsv+m4v+/6u6a6w6GawCE+w/kpw7Oou4aavBa/vD2cZd8Zw5zKv+xKwCbsu966u5wrv
C58v5AIu2qpw8z6wElfvDFdw/wIwFv8wD3vvDdtuB0MvFVPwBZdwF39w+iLx+rJwCn8vF2PxEFsu
BOdwEYev/C7BAmfx58qwC1tx7rYv45qxB6tu9MquHQNxGDMBGSPxBuOwFV/vAtuv/0qyBhuy4hpw
345uAYtxIityEl/y9xYy9kayAk/yII//8e46Lu6Wbymjchc/Mg1PcANbMuwi8imzagDL8SfT8i5P
wRDrMRzzMhJ0cB2rsitHQSWbsSBPsfoegRj3rRHjbTDz7hxf8hZfcR+38TNvMQhzMv6+sDKDMzLf
cRPgcCOPLxrvXR638Dd7cSTHsjVf8O2esw3PcgszMPP6cBKf7Sg/sQw3synbsw4XLDALLh6Trgbv
Mz9zb+m6MzHz8TwbQT3L8h8bsiivsRfvqz2/LzPvMQJD9PyaMh6TNDdnMzbnczmH7kpntDOj9Ehz
dExrb+wyMumCcRl7Mj7rtC47L0JL9DwLMku/9E5rcy3/swsyc1AT70dT9D9T8jAbcEgT/7VTU3VT
Gy8uw+9M6zM5v3RQK7VSv3Ix260Tc7AbjzAyW/VQL/M093Fbwy9ZV/Q7W/QykzVGR/RRtx5Yp7QU
X3NfY3JYL7Ja/3RVK4E3F/ZgIzb/ovQpn/EB7/VP+/JFS/YV+/Qjk208y/Nj+7RjD3Zlx7NeTzXu
MkAL8PNf/3VTp7Vbw3Vqt/NCU/RrLzRlx7by6u1JCzYrzzJcw/RYEzQHnzVvi/Js169wa0T+1rVw
o/Y+s/Zb33NotyBpb210S/d0G+1o1wB1Y3d2azfMWvd2e/d3gzfHdnd4k3d5m3esjfd5q/d6s/cU
jLcTa/Lo3rJAQzZV+/Vmi/BEV+9X2/92URuBAAC4AOgAgA94gBd4EBB4AAS4gSu4gB9Bgjd4gUM4
hPsAhR84ECx4hu9Ahlu4Eiz4hROxX/P2Ejc3Udv1Y9+3UI9zidc356Y3LUtxQ7u05AY3W/fvKtM3
Z4v4Uusyjuu4P39xP+94gnN4DhC5gx+5kSP5kit5kz+4g0d4lCd5g394lEs4g/dAh284lDt5lnO4
loO4Nsd2QO+0RW+zjBtx9tKzbv/4VcdvlUE3DJ8wQ89tNct5JzP2ZG/14TbxVb8yF+c5TmM4k0v5
klf5lCM6of83lCd6lW95l2M5lXu5EHw5pQv4hFc6gfuwYhu1LIcuK7u0HiMvUKu4Xp//MSNH9osb
NA1HryNjMArTOE579UzntkqL9CeLtQdHNWdb9ZEfOqEnupMH+6L7OoNP+aNbuYd/OZczAYFbuKM7
umbLeh5L8JyjbxQ/cTBD9myjdhkf8ZHFefe+8bhL76gfr4/Xsp238xKncgLzeCCvsZ4jAbQzOpYX
e6MbO7P/wK9feZgLu6Ev+xIse6TzgLNz+bCHeGdr9TET90STsEnvsFuD9GGH8LkLObhftwVru7i7
MnzD+i5XMSQ/vJ+PMVf3OU+Lc5BHtsDrO7Ij/BMkOZh3OaS3vMwPvMwjeMAXupOHPCL395DFdzgD
9Ij/vGV/NBsfPSmEe5qrcSc89Hxn/zut0/QbqzaMn3ZfUzFmTwHCD7ylbznOV3i9X7mGN7vO57yX
Y3q873rbjrnWJ/PQD7XRT7wco/oTv/htL3Zpf7y7I70WT/xU8zSsu3GnC/q8F7m/DzvOg/2+iz2y
z7zitzyVR3vYLzo77/rGr72J67etC74tc/w64Hm5J30uK7zD13U3v/mNX7zHqzglC73eNzaQD7R8
e73jd73kH/vtJ7u/F7zOEzymV/qk277ZDzraH37C6/j95jCL2zcQ1zPrQ79gOzM0Y3us80DK5PXP
l/WfZ7b2c7zGu73mQzVhb37z737aOz7lz7zw9/7Zpz/7L/76oz+x+z6z43zQ3/Pvrv/6IWcuCEiB
KAajiZ7pWq5o2b7uHM9unZLuojC5BAy2hMIbEfgr2mRLpg3XjD6lqhcxCr1ZjzOB9ytIgcdNL2oM
Npm76HWg7Waf4ba2mE51wcPLbN8Jc+RXRQNoIjiY2CdoxPXXhMPjk0dZaXmJmam5ydnp+QkaKjpK
Wmp6KiWJusra6voKGys7S1tLqmqbq7vL2+v7CxwcgCtcbHyMnKy8fNvD/AwdLT1NDUssFZQzckW4
nX2YOeQ4pEU5uKXdXYW4sqeG9sZnmpYXd2f/jh9v1x6mL/evnrx3ZQYKzBSHXz55awLe+0JwIUQ2
bszAizenosF9F+vwucbuD5SRLMD/lTz0TV0NcY7QKVFXbh3KloXu9ItoMyM9jmQeWpyYZg/DhhDJ
7Izy0+jGORwxSjyqBw9TnDp7OqWicapWOVcPOrWHjyhVnku3LiGK55pJlkp0xEzXtlwMGHJT4ljp
JO8UkyrubuFmVuzNsQH1afyJMyvGpAMZF6QatOziogYRI62M2ezXjQ4HXwXrz45gShdBR306mHFk
rJkjqu1bci4jlYQCjYMbO503wHzvzja09vc5skA5U04tNWdT5YoRH3V8NnQ/ywCP2+xM3PTYzVEV
ek7Y0ePTiVw/h5862vzjy6ddOzs5FzjfbuTWysUtf7hu/TSQ6O0fEmsPBcYHduNp/6feZFYRt153
UPm04GSV/KNYTgY2aBpoFU7YmGTRVaiaTgS6o9UaPCiwwF9x9aZbbfDN15tdetFlzm/GiNahVRce
ViB59MAD3WZhCUUQdaetdqBkQg2FVo7nCdTkktwtx1prnCSFXEQXTtcjCgygWFMS2iDC30y8vbUX
mVmsRCYLjKhp5kvZkdeeFCQOSKWWxRUZWnN0kiZdYX1KV+eVe0bHpXcLbSced1LaOaiihuqJyY/y
fJkimpeMdCaMe0ES5iOe+IUNopBeImiTN4nF6qCJ/VmVn12tap1nBSnUaoOodgmejl3OasmWDvZE
omBD4srrpWBqGpJ+pLa4WzZ4Uf8x3LOQ2OhpgIUyumujjqkqYj6L9rpUhkNNGSuhtgLLFbm6cqsc
lQjulF6V65qqWYk+GpdluAFgGic3pDqrBZyfenqwigJTy/BJXsWb6JJPcrloow5SVK6VTNVLa5JG
4luex792S5iHHD8G3sPwOjTkvcoBTO1s2iqsCZs0/RfzzdGm9N/MEM/JypYsK1mWpNd5+HPI77p8
mdGFOo1echlNDfSwD+ar2Z3lwVxN115/DXbY0XAtdtlmn4122qSQrXbbbr8Nd9psx0133XbfLczc
eO/Nd99+r71stAjjDG3CMOU2U+GFv6mwf40j7NuKKs7Y6X4z7uf44SesCRPPirj/ia3DNeqs+Hyc
s1R6zz6nrjl8L30uKi1cDxwmYM6GHheNMiVOuIvZJuybpprzZq3D9eWl+/HbyGAbXc/WZzuoB7Ml
p/Cmx05C7tLzPnj38Qn+O4vGQz55964wMEn4JJFfquj2bS4+bPG/Ja31zb+ouB/KF5+E49+4Jb/d
yQ+A9nkeOuRTsOltr2Dr856Y4pO9hcVPf4f7nuXGFxy78AyBvTtf+sCnuwu67wm4K+AET1iI462O
gOIAh/8kSD/QbRCDLoJefkyIGwP+bobzQ94CrfAD0Z0OgQSMCfU+1UDahG9362tgEmeBvhh2Dmdl
cuBu1pG55KkOiE8UYRd9WJfM/1kieuLTYhnr17/OZTFOWwxii2A3xvwxgRxFQN0Ns8UmIRqxEf6D
0f9qFyoopo9xU4ScGH+InyIisYMAstG0mnczC6LEep3Aix3L6ELLVbGQcVReD3f2OgFS0Ydm9IYA
N5lJPy4OEM1inxpRGYooNoyGrAtY9WgEwFZ+EpSwpKQMK3et1dkSjnuEjQUVyUs/ilFNdOwZI6fg
yVI185Ss3CAzmXc5Z+5SeNFsXStkqT7QUa6XNXGe9FSYhy8ukHQj3FnsKkFMDJrzevwJYQedGM5G
hvJ9v/zjNNGJQsMxEVo6FCU/uWezXIAzme7E4ori2chUMtSUVCwhIlf5TCWiie1TLYGoG+FHn1cK
jAvxtKQv04Q4ac7RoW9c4ztDGghm7ZOhtwnYQWGxUP7V0p7tVKn5AvnTzVHwpZIkKvCAyroqIhOk
PX1pLefYpvYJFKlMpeo903lRQDbVmzz1YP+qt1VvDhOrY3VqgLLIUeKdaYXA9B0fXyec0G01rWBN
Klk54VFf5tV89cyqEeXKSHKCYqF/K6xhD4vYJRA2sYxtrGPrttjHSnaylPVaZCuL2cxqNm8f3Kxn
PwtaQYZ2tKQtbSnQh9rUqna1rG2ta18L29jKdra0ra1tb4vb3Op2t7ztrW9/C9zgCne4xP1tCAAA
Ow==

--=_NamoWEC-rk8v0jzu41
Content-Type: image/gif;
	name="201407220829457_T9SZN3WZ.gif"
Content-Transfer-Encoding: base64
Content-ID: 

R0lGODlhCAKQAMQAAAAAAP///8k6OspMTNRiYtt0dOSOjumiovLExPfZ2fvt7f/+/uvr69TU1Lm5
uYyMjG9vb0dHRzMzMyoqKgICAv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEA
ABUALAAAAAAIApAAAAX/ICOOZGmeaKqubOu+cCzPdG3feK7vfO//uYBwSCwaj8ikcslsOp/QqHRK
rVqv2Kx2y+16v1YReEwum8/otHrNbhcX8Lh8Tq/b73al2M3v+/+AgYKDVniGh4h1egyEjY6PkJGS
k0OJlpd5SXsBDQ6engwNjFKilHoNSaVYqkisTK5CoUqdo02waLJMubGogg6Nt1S/a3IIeAoJmHAJ
CnTIipq1EBETFBERDRHDUdqmSQ8PSd1GENzbR+NN6UPgqRPYr+Hrae1MDhFE94MUfA3hRvOKlHPC
z8xAIXIG4EFQAJGBOQWMzWEIDckmIfqEBFR3zhuWgk82DhGJrmOAekcy/zJpR5IMSiUqA8T8A5LN
yyc1l+QEU9MSxUMKD/2cs6iIyggQKExAxSCCtVoBmlKgIC/pBEZSIzBw8I/ryWr/hDSYRjUpvq9U
ozpdGiBp2rZTyzUAO9BqLyHt3IZt22Cs03Jm0YbzS2HgA2sTfj0AixfxNqlsszLqtjgtuAfDMA+p
BlgpqgdJh82d8ACpZ7VPiUA4HNlp2tVKHVT7NbewWKUR9kpNy4Azvt6F8SGdIBg1W71C7CY/rTru
ycr/kiYlAm620+hxm4o9K5ax5Las+04gvTschL5kD8LFBmFCZ9twp8NlO6S21uJfE7dNygD6+kpx
NGTAAQMQkIwCBAxggP+AySTw0AEJPmTAAAU4SIABBiQDIYUKDCVHUflwd81JgJWomlz8UMMABCay
OFdyDzBAgXh3OTBjA1T1JsqNS5VG4lxbEVeaCEut1hQ+i/VHHDsPACkbEdrYuGNfFDggI41SXnml
jVbyiGWV7CDZYjnaXDmXP+CcNWOY/ly12En3xeLiiKDtZ+dISOLDIicpCucmPuTlFkBiMu61J47g
HZnoiFWK4KWPoDkppJuTKkmdVjomieiQ8uHl5o38DKkjW3Vu5gCOK5pIp1YuHpqiJzNeWV+VNjIi
ao+shkoplPLE6OWVbyLlKI04bpPQAgU0dICAByiQLLLGUDSAMQMkkMD/tAgMoICzCChQLbIHeBgH
iEMc9Ys+a8pIhBg2BiCoumsiqh8F/dUVVkYFaVPqaj6KIBsjvQCcGL0yCTcMfc8ByQmUnpzVTaj2
ZqTvQIntCw7F2/TLSLyvWgyOjEGG6O7BaBbB0rn4pFtTN/qw++pzBb8Y85KrrctIuwT7mHPKeNmr
8b8Lj7OU0HdFxUnF/7yMKJMFC1GQwA7sqV93GMmKKMtIhuPyyBKfw49KUHdzNckjDUYijKXKo5i9
AfQUh0IRLSBtM8tCK3dD3yazgEI/xd3ggOLCQS5GIqLc9lRTEWHfy2037jR4Lx6G+L1qasQV4jlS
E2N8TK01MOHuYp6x/3mFFR2lw7+EijlmqNej7+quP6b5xkN0DHuvNZdrsOU3ndw05isbvvjIMN9j
I+LanPXS8AWhC3pBkk8V4+ych474PaIPARnSj49TUzv4GpcYkDXFBNLL+rQz/OmWE/H1Wdsb3332
3QkaPVUvUba64wi9bbe0cKBI3CgCobjt7W5wiNuECECAcDWEDoNrWvucJxYiTO1l8MLK19xTjnoU
LXwj82BUQtGeqPiDXnsaGcH0MY6iqa8/BLNc1xonwq7FToSx0x4JiUMwdenrH58JB2jWpDviDYor
e4EZ1vhnOsNdkHjgS14stqK8vTyxeTz7HV6AOMKxECcUh2mKaIxYtP8U/rB7w/heOMJnxl9wUGQy
AVlU0Je1QSWNa6hznwTb6D0yKq5g/KpgPdQGs4XxLwDHGiDeAtgQRS6AGcs6wAH7hoBl0c2BFTnC
RSRIPBaucUlOs1WKOigcIZ5lPKgAmqBA57goXcVdoNEaVU4pv2KxSFH9QthlaDmShrVvg5NhneVe
VCxVYoY4xRpCzXxoSq69MjftkBEoQeejTSXRd56UyTSXmLOXRbFtnynHmkjjPlHCsi2lRKfjjLnM
WQqhYr/BVVQQJrYq1QNiJ1GjBJUGptAUgV4gs9/u0heObuKxfbWTYD250sFQxfMuhLqHwnLzoiex
7JkFxQgi/efIAkj/ckHgWsCyEkCAZgxokg+MyAEegiBMQjAaRilc03DklHO0xz30okY1UEFTIjpF
meOZJgi7cVNkIiZGQcWHjaiRG+BMY57UUM/HksqwGY5nRUFV6C+KutWstiWo26ApOXuKCqJm1XVJ
bNl4wNS7WQrPGmDqZdNuyh/KrBFJ71jTYsZjqPHwR6z4GM07+FdUPs2Oqr2JKlTdkw/EQPOOvckr
de76uKW+Y4072SuKnFJWwx0GNH7NqS+N+M7EnMWyTR3PTxPLWHYc9avjSc5sjFjYQV2FH4mMVkNI
ysCGZCtZAiJAAQy0AAZS0lvDxVDgFhDBJpzKCH0xSi22ApUidAIK/9eNxXMxcpfsnsRW3NluSoqm
BytxwiT5gIp342iErdyFutA1CcLGOwvylsu+0MVvfGsR3fyuq2i7sO5jxCtemXzQvutNCXbPUSrr
vte8reCpfjUJYbF05ML2ha+F84Ff71I3HIh4RhysVQyJLKBDzZgDig3RXI9MYTGHQa+Ln+CXGdsY
DIuR8Y2x0B+PiEAZQA6ykO/AJB0bYchITrIcFNAsJTs5yDvOgieiTGUt/BgTzLhElp9siS0X48R6
C7KXtZxiMSNgzGM2hIjn4OU1TyTMSXYzi1NRXezWeRBGhgkYaHNn66q3zyaUQp4DrQmeArrQTbgy
HB5yCAMmwtFcbv+0if13AEkKudJAxnSQfwtpSN/hIct19HIN0EAlg/qBiDiCP0grhZtoQTNLWJFO
qLATLYQqiSVhWBJm0oRaxxQmu3tCOXitSQYcS9KX8HSkM23pIGsaE89WRrQDNOk7BMUOyqZDtoF8
bUscwXeEaAkrk+BrJpT7CucuwjpIQmwstHvcUHhfoo29aAqJtECWJhBxC7DAZAyoQAcqAIfs1u9H
ChxDzoJDwkccoQSSesQLGoAkLYShBBQgxRlS1sQbfm9+N4jj1xJusx+ZoH0T6OKPLJBHi8FASTpr
4P82EG9XqiEKEcAYG5p4xCVEIQedWOASt9syJKTvBBT95SjHULX/Ir5Se9+bQxOqEEsFnvSij0sy
siGNaVqTGhY9JRtb7Q/pyDkfF1ZmbVWqTUOXovbupOUvZV9OpwqZNb7KvSDKGWJYq8GW3FhDI4ep
HPjsXh53WWUyilHKXlrmGsw00ysjeY7d10NFvnCiHE7VE3rgHrqnKtMasuE8a3RD75SfWebaIqnR
CYAsZT3kWXXD0AJkr9KLQ2j2BnBWQ4i7Ujk0sKV761YcstUsbWVrWxE5KUkPiOnfe9RbHZpWcZu1
8ptfa+SlrlvQq3/moMfh5seXPe2VdfGKR0T12Tp9t4xfLW9ZC1sCesjyRd1I8jurWeJ/fe6z9f5m
ydzk14IAFJF//60nUqhmJ7c0J2KCgGQCAWJkI76SMFfxJEPyJK7VCUJyH+QRKEg1PeEwPvSyGP6g
FRSYK5P1OEnSLpziUCHzJhbUTIXRFAXlgIJya0dUK4dCHCqyJ9pwJqhSRK7CQvyQOyg4gSyIFCxk
ODxoMFkyIyuoOLQSK/TigzE0QsfSe7NXaYwmSR2lW3vTIHDDEJZmINqCQLJ3cwzHSAfEcovmUrUn
Ug+hEJWGAKx3N1gIfnXIEMuXhUt2YtoHB5W2hye1DHnofin3PxoHLXdYSYwGOClFLQi0LXIThsPX
SF4YN3lDiT8RFH7zc5LEN3gDhog4LhyjRIajMlCUJlIEDkBTVv//oEsUUzIWmISziA2vZCXZNChg
xycnSEN3VE/npIs3gRU6k0opY4y+KDNWsjWr1DFsAzpbww/WsIsJdU/EsxVJ+DvgdVAj0w3qokc2
9IxWSGkDUI4SF21diEDXFoYGFBFBQRGq120/AUDF8EBz+IjFZTdyGC7mSCGaFhHZYo4RYY8jp2/P
EhT3CIjN5iHrOIqYplKWplL96IaQCI8JInBCh0Dp2JCOtIYKVCClBopreEAdyVznY4q/gzmdhBQw
JkSkcx7WMxWjwzuU1TRRgjlSVESuIZN9xDS+iEbzcz1t9Q5ZREHOw4rccTRwZUS2MzlFNDyJ4R7t
okfWmA7ZaJT/TIg6PZlQNrQ/U3SFlqYh+TaKjlSG3gItBnRzZfgTF8JoAZSHi1SPCklJ01eG+/gT
27KIeNkhBMlwyUCPCSlSC/lA69cMZ+lID1lJEamYy4BA+ohAaEiSJiZAl0gthqmJD8SJlYRymCaS
ZomZpKhBKElBQUMboAd6MANGQzNGPnlGtciN/nJalddCTNmLNtg4fUSby8MWWLlOPIOUVfNE3tgx
XFRETzQNuUEN/1RISuNL3AQ67NONv/CNXNk6xfmV/kNSzeBRy0eHZHmJklQ3b3gtuKd79VZt37Jy
3TaJyWAgdAkhjLaPXwiH1xJ91KIhcdgMpfaWCRSXnamfI6ct/+63cuLphYm5fAGoneBCl55JN5So
hulIoJbomJrZe8AnkhI6ioIjUKOZThZ1MDqYM2nyTlzxG1X4JtbkNK5IPHolTsOSPiZaL/lEHcN2
m/h0GHAyR2KXD0vCKOZRUD/6kwA1IwaFFDnagxhVRAYFYzaiHj9JQx0EAdnkI4LyVNGpLyYIjqgz
UWGhaMVVUqTGQIuWIMaQjvBIIenZLQxUagiiIIS5npPIQM2wnnTIQKeWQMZwfXAgnyf3LfqGhn1a
cy3ne3bKeggZniBZkHaacgKXDIjJhd0SpmgoqY4ZN8YVXBdSLfT3nYyaphSKp8jVll96po2qocxF
VvlUGm9VU/9G9FMlBDOIpVNSFVQu6SlX9VWXw1n5gSI06FeLVRM09VPWyFr80BS+ehNBVUKI8UrL
SjvtoFmwlRTZsFadBVtCpSehRSW+kkQ2ClUzog9LNSKClZXtIx05MR4zVFvYqXDClwCTJnyJsGJv
Boh0Y49uKQfuegd6WG2WsGJGBwfEdWLwCmZ1MLB1IGfLEGbyiggGm692sLAkFmQLewgLW7EG+1Ia
xgn4lbFOUGAF9hwfu2HlghUV1l/nxV35QGFLgGEwUQv0sg0vmwrdRV7olWCKM2FOwLGExgtLoBlL
oz0Vpjgd4aXLhgcQQiA4F5mXsFxAhiALUodFG7VSO7VAFgj/rlZly6lHWCsMs+SkUUC0VDsHcxhA
/IoI/+pkRtdkYbu2bNu2gTBlW4sE1xS3wnC1ULAJuxBgQgtdgIZEYJC3OGsEnxC0W6C3WsAKnTC4
h8azMPExXICNcFu4gdtegwYgIwZnbftIZXYMmMu5dUBiZbtpSztkz5Bmn7stnXuwqZsHm6ASxLZU
ACFj17AYXhsGHWQenNRr16CrWzBsSbkF6TAN1XANk/tuXwFai9uz2xCut6oJtUsOudsEItgKezEH
F5K5jwSpiDBtC4FqctCZTwandRAuIwlklEkH9wotTKtwDzJyLNa64fW7WwQFPjJPlduxSZluSAAS
DZYF+msF//NgvL9Gbr1AhFNglSKCa3A0awe8SkbwEvg6XNibmMu2XNy7ttu2tN47B+K7vo55CSNU
RNQEHaMxPdLDF150EAjzXP5BGEMUWGSBHWwBFhczjZjnFPfhd3HyONBZQtAha2qhlHKRHusxFkIM
eKlRH3y3efAReFMjwilceJmHGjvcNqNQCt8hFVGaGLJhG3vVCyrBEiWkHIyhHFpcxHLBGUhcxYOi
HW7XJJO3UQppABIRc+5qaZUUB/8omAnickD3UX8zc/wGcCSnIA7XQAdgccD1cwPXpiA1YirHhYV8
cS9HXCRlyODij3KKLFlIyC93jgxkcfVGXHZ8sBHCIJdcfv89R2oVV6dB53Ozd8mVtnGG7CAH9yHw
W0SagkLn4SpcA1AJVQQycipLISU4glSdkCMhuCsiCA7FpCcm8nZ7wb/itIxSeCZnw4FNSCW+xIFt
0ysWpBjacM1nwiUDXCupwotGMiJ7kkLJQVHKNCa9wRWvxIFzsTmcVIOKwcw9siu3BILd7IHfHIwY
UQ6vdESo4iKWW1xGx2iwVyGc2GyaJoclRZ6yR56KpADm53rTd3/Bx2TNIoAgRYADYp7ft36fGFIe
VTe953yf6H+vl9IPjXskR1LFJ1IldXszjb7UZ4krx53YIqAAKXHo94gQkrYd3UD8Z4iCk8sjjIJa
czOvMhP/mRUxleNMMEI0BNU46MJT0ji/tXMNO+U4FlMzFLUkxpNH7yMzOgPWFdQfOTkxJHrO8CPV
VpyjqEijp4GKK1QyyhhsMmENOsXDWh1sS9HXXG2LeJFFL1EzNaOMO2q5y4cgeAqZhanHliafBySJ
2eKQ2ssQ3mmAa6hpqjefZ1mGdUOIbUiSEyfaqAuXHolzMu2FnE2JD2ogJZkQ9YqWrY1SeBrajvjb
GreHK0WXTV0LrltHP7k+o1U70xXZwNlKo5UmorPV8naS0DPNnxDM9yNMRog8M/Q+GUFBLyE512BD
/xDAp3UWzPM8KtleewI8hwQ+OElasuEJd5Evw8A+O1kl/zkh3utN1lb0DowVExAcQBRSqog5IN47
0YK5p5MMmhQM2oTpn2OY2f24hkPxE+BLUivnLL8XkOUYl3EDvo6UyrYtdAPphXTwjpbo4ZldqQJI
kJREQC5F4ZV93Eqsy3fUDmQ31b+bDrFk1YQ93apaQdatjXMk4FqrtSJUKMSREbH5SwXzmtmtxMaI
3gglwhlxRc9TH+UCSqSJCs0ji3Vt3/Kr3ySajQtT5olt5W49F58gb3F04AuKACd14gpSkDHu4JEp
4Z8dEbB9qKIN4Y3p4pWokAf0l/yGuqS2l7H94KC5nymelqD9wcdGmYwehzL+E8GtvhoX2jiekSFc
O71gP/89XlDmFJ1hjhXjcxU6MlSwggryFOt1JG8ceuXBrLXG5C7NGE7h/TsrquvapBFx7QlGdWEB
ftc4WqUeOk1xVSeC8qGwdE/hhOZGAD2BJW/1K1rndN3D7tZE+DDDEk2o4D+q3ZECt7m919kOjtpw
E56JWJaOmtKCWZ8BIkneuXKPvKftmdI3x5cnddr4Gekm7oXw/ph1g9G0DWf8boloCEA13n7uyXre
MuOSXu90aQyl7ilMZSupHq2ixWvtcR2y5R6VJ91Zh/Ksxas+blqGtSbEfkg8bK2N0QuLwVlWBfN7
xaxubVvuAfPEw1V0ffJ/5Vgxfw42ElQAA1e0cVb/kPP/a9Iew8BrT7NWpumABJ7GsWVb6cP0TP5O
d1En0PpZ7QCI3qstHZnakJwsmq0QYToh0bfIBLIsBrqmc6qQBGKO3SdwebqmDb6mKX1yDXQtwxWe
wvUtminpoxj32vLoCoEgZOrZ+Ar4imhzknSpv72mjAb43TcgiC+nDMpcm+RetjC5FlY0NhtT6yVe
HlZhOksKOkYLFlGylRuy6YVdAEaz+PWxrl+zFYb7SPD7KCuyUWH7VGCyJosJg7hkoZuw+ApnEctm
z+8MZxYHCPtInSuvHRJm7rq5WgZn1z98q8tkKrb98DqxI/auZeawy/D8ktTxjSDAdFv/9n8EhkBq
4I+9//wPAos4kqV5oql4KKr7wqlyLAHDBLm+873/A4M5xkNoPCKTyiWz6XxCo9Kd65CIYbPaLbfr
/YJdNkZYlGiV0yTEtYSInU8JBLocV8feWb25ruKLAOJxCboUqtxxJZosdi3GCR6eFNo05DQ44EA5
TD01aB4xWOrcpB3QDJYZEKAuHLwNxBQUKgwUtH0l0MymjryexGYFr7Se/A6LIPcKwxxn8cYYlECT
/FJ7nVbTKMcqSKso1zhE2FBEjD5RdDo9FCGN75Quz2td84bvFZgWL1974ae4R2+gCH+pAE57Y3BL
NhP4EOgDZyIAPHhS1K3L6MPiEDK+BhC4oqCArRYGDv+AnIMKwaldKAu0eGkA14IEBAZ8K7DKFyp9
NkvWvPltxE9pKEOuSIkTaNESM0/d3IVzgYGUrqoiOAkSwc03I0G+IsBqJlWrUFk5ZSq04EtXKX8i
1XcWVVWkZatqW1DgZZ2jCZbC1Ot2ajWrXwNrJcB1wJvEixUS08tXcNnAcHWl1HfYpF8SM7/aTTq1
6q1VBsj69bs34kgSe20V3Fn3yoECYmlkW5pT72ird8NRJBeBAoQh5GyQazCBeI7j7XYQN4dDOYUJ
DR5wCoA9AITq6LR3d0C9OMUJE9x1t679QQRNED4Nb29jOYTjHYmGPECAqrTTevef9hdbubn0lwII
MEb/AisKoMVYX6jEspdkCywo4QgLVsiCCCOxMIBLFLJgYUEsEXDgfvrpApN+rgRWgD62zaCPfwIG
OIt+M5xYIoLVwKQTiAxuU+BeQLK4QCw37libiSx6gwyBE244pIcTxjLAGaHZpAuA/Unj4n8x6vVi
ibUZGdmUEh7ZozRoKSklf296SeYINso1lJFXJvAXAggqMBIb+ZU45CxIHWAnThwaSYeSKyJ54jYG
IHpkfjBxxSReJQSnnXo5qPdAcecxcF4AGD2nAwVFRFCEqOx5yul1EzDgwAQ7sIcDqKkGMIEDDlBA
RHuyrgdBEcpxVxwExhYXgX1j+PLNNlcIaGEsitUy/8M2xBQqgmL4BaKPMg1FSAO0+y0AEbflvgiI
QK5YQa65c7IEIbpQ5tfTG9mY22e5R+6SFSqKgeuaV392Wya7er0hEpn8JkNvArwIyJPBDY048bVW
1lSNs3fWFOG9NJjLC77emlkyLwcu0AKYAmEc7RvvjkimviO03PC7Nm7Myyz+bUvzFeYGYyHA8ub2
M8kh//twwsBVtOyxue46a6akupMD1TbYUKs6wArrqg7PARscsRQFgGuu12FHTqsUWMKAOr1qt6w8
B9NcNzRHniTXtew2RM27QJcQsE1oITiA4RHNO689sBBT+OECBxyyHjbae7C5P5F08CzQUN4wvCP8
Tf+y5vfe5CXDZZJkOGN35xUMxQhbXKZ+17w+jMeWp4t77K5fSztIXrJs98uIIzzSgtUQwPrN8QqM
cJbcFBz05MzLvjfgIau+uh5Mk8NRAMo1sPVx8Fxtag7PPVCdsme3OhwF72e3HkXvvx+B9+7D347b
ZXNC//uj5sB7c2vINlR2uzL95SQH4122KMSHSs3rW/IymgHeNbNyuSt3n+OdBf3QuTJJTlvUExnI
9NEzhm1OD0PzXMXmAEHAja4WRqtew6BxBdZJjHfN02EszlCbVhDQSAaE3ciIWMLdmSxhf5ohy4bI
C5gVTwEJ2AlRYnSt5QVRZ28ggH9IEAwYQmOFNPz/4tE0eMPtTaRpPJjA08JGvvNVDYDrAV+mjqUr
/l2CVkWwyA0skgn75fE5qYIbRr4nRwF6JCgYnBCZfCSnm5SMXQZCECAwhqbASWNH2wIabQx1w37t
0EydhJy8zEUmAfXtYxGMCQpZ4pPTOcko0rDk3rIxCwiajm5pStkAZmAUJ9WyGOsqWomo0gqbLFJC
jVRlCItISyRmq1C4zF24ivRE4u2MBrXAD2dAGJFZILNSWiyLIKakQNe9UpcL/FAsTKmZXkazG7jI
lPe4Q4HssK1sRcin2awGx7CtTzlSY085QFGqfK7tBmwjqNuIUIQHTOA4uAIWruoTj0RSpSsdI8kN
/8ViFznlJjJH6VkgQFJMZfzFRUeyxbZegjHQmbQF11jFjg7mUpp8sJ2a8ShuKlfEVXDRSiipDR14
qs4RMIij+xJLC3RIU9twcT+wTBlUpZFUSOYwMiOgKQ8zahuarCJBKbUkM3P3U7FccoEpSx7GPCob
xfTQFmRN3IhSipatJg8pYlleRhP01JeFg6Un3ZBRA5abvDa1Y5Cq6lpto9MR0HNZ8/uaeWDFHfP0
U47PqSwEpGYO45iHPHA8nzkQGlrknPY54XNH+IbDCYFG9KJuqMOB0HDLOigwBbrQFk1qIokNAaK2
SKUDI35brt4C1w95QC4iaJKnNTC3BMI1g3HZcP9cGFgXdISIbrkOQdzkeuG5LphuufyQ3ZR99wUH
Qu6ehqvcQNThvA30Isomwd3hFjcQNJGEEFqlA0zsoAHfAUImgiCeIMQKFALewYERXOAhDJhZsgDE
Kt5LgloYwDYE2TCHO+zhD4M4xK4gad1EPBEgQDR+GllxJ+b2Ag354r4bOoWFTWzjG+M4xzouQ3tN
wA8bG1jFLB4yFG7QA1HEI8JENoKQEaxkIHxiyQaWsg+Q/L0m88DKQ9ayk5fMCS4nAcwQ3ggUFkyK
J1P5yGhWsxKw/AQkRxkJYjaCkXVQHO/VM81AKGQQ7ixZIQBSzzzgM5X9PL8/2zlTRM7zRhC9DnX/
lGoJkdajDwg9BNFWuTiTnrSgG01nTcfRCJbehHCwjGkdMFoIdfZnqjsdhVG7egmwHjKfOT1oRQ+5
1Qx2dEZsfQRf+3rUuoaHr2P9BF3rWdfC5jUQVt0d+0WUOQ3QNH14ANE7jqc56UuVeXAwSG5b1jmo
2ra3kcMcTUnn2dM2t3yE5Z0dvGfawzk1RE/1vc4eqzuiqPa02diDb/vTnpvqjrSXI596x1He50a4
Pc/xHvOUygFVe7as5n2+5cSRAcNRj8alw530cZw+yal22TqLavPYWz5lA0XH2w1yWd3ze8tRj9oS
PnNLfHs66kv4zmV+boykxxIYF/h3MM6eoT+H/+AZtzi6h1WfUz373sPx1GfXzR0BP70466YOet73
qVOpluQ53wE53K2r5XDC7DD/cnxwECrilN0S6Uv3Zxk+DokHMNRVVvA9eWUJtpGvf+hw26ty9QCN
7/Pw/sbVqUKVrH2ONuWQP1aoMsHPB4RvV2VHVtnUtiz7+Z3wpGAb+HjlbQjYSvHY6RUoTIV6xmuK
CLOqVagagKtUEZ6OAWQb4d0mHutkfhwMOFb4tP3fvueT96TfVNzAU6znr4+gwtI4OW61zwfPD/PW
6drYcvC0p60vArAi6B0JCuk4lp8ckoea29BveVUdHvYQlb2mXkV/ykocVsBqh3JiJTXvo56u+P9e
6ZFe41mH361W7VkE6CkfJlSfePQK7VkHRKGN4SHeqIwbdHRe2YyfcAhHBz7f98VfqTWUPmVe7h3g
OWBEZv3AqgHQAmreqFjCd/iX9p2P+jUHJzzHCuog5MnP1bwNDhzYDMIe+cygOgDS/cQgHp0PeQgL
DMpcE6ZaPr1RoHGczI3DsDjfx6GaREmcE0IesamK5bWe+OSgf3XNDY6BDJYDHpEPDrDH2LwRg0nN
E87K05hK2yBhD2ZK25if/PxX1uDgHNVh1YyNsMghDlqhAzIh84mhP/GfZX0H3IgHGqZNwIHecfAg
DHLiOUhNgU2Hrojh2PwhIPoTIIFNqcmPEbb/IdwQFCBNh/yBITwIINyoWhkqWiZqSqCNVgCNzyCi
og8Go2b54A7KkZ1Vh6iYYSHtIa7xDxSSFv1cohv+4hT6IgDhzz11nHn8Hq7M3ftUDQyWijE+oqcQ
lAaKo/9UjcaByqj4DzUekv34zyB2YeTpntW84zASW/3g4KbxIzFaRKQF5OrRjyL6TwxmY/w8IgAl
HXFMIqWth0VsoibmYCdWpP3IzcaJYs350SBOWjOmIh6FpP+8zTUCUnooo3aoI7EJC7ORAi5a5Cew
yte4A3Z8IjDyIQ/+YOTxJEZU4sGFofq5XTMqITQCoiVAoRth5A/4pCJmhyXgof0gZQQIC2vt/9oZ
guEL1tz3EEeomSH/lMp33EC/HSPOccIc3t1xGBmhWUTX2NGt5ZE+euJUMqQhqscctsNA1mNEqiUO
NKMhwUOgfcdCnt/3EIEtHtJ1zCJFPiNj6mJjXqQfDR956GJe3iQxaqBciuQe0ePfmaTEAWVd5hE8
hE8a3iI6euE49B8XXsKsAMvlydEw6uQO4lwxQh4gpUqrhEpQ6lPzJeHnLSEvyoq3TWOgXZ5FxJnV
FEHXQJom2t5r3ZMAqma4haMX9l/taSUgLkfrZSf/rGY/dc3+TNSs/GZvWhRCFQdb8t5dnpsOjOdm
BgdA9WM4Ss36AKHQxVE+KaPcpWfzKaDnzf8HOhDmepzjHeWgCcLKf2LiEm7irPieRbIe2wBS8G0l
bJbPKfJhYGaocOwReS5nqelmSg6nPi0gJZ6mDnBjapZdRDHfZcXctVnWbAojH3ZWRNkmAMFWOYjf
06QoVw6HWTrjY/LiZZlHLmYHjMaKF0IHi/rlfOzoodkoRInfclbWVeJRjaJerujKVjbfGm3pgdbo
//moqLRWzJUnbKlNtHkmHYaWJuRTgJUWJ2gmZ81KYaJoaNXpaMFoHO3pLiafk/pbaYbKkx5fVUKi
4mFWgFUpkaKeRF7kgmqp+AVnDF7bnZmDjbqNoSIpZpqPZmpmmb5WZZWacuzop8BKmCraOc7/WkfE
A/b1wK5sBDoAmCes2SXET4KRAvbhahTMKpQ1WYNZTazE6n+pGCYomJvxQK/uKrzp3bKeWZPFymCi
GZcZaxCYWRQOqxAAK4Gt2bUG2HdUKw8A66xuq60aWIT16pVtAnf6wLWm67siqxRE65kdma4WWLp6
n961ILsaW792mlf6KxB0Fr8GLJOxYMEibMIqbJoNrJwR7MJCbK9FrHbU6sR+j75abMZq7MbSSsW+
JMeCbMiK7MiSbMmaLBO44Mmq7MqybMu67MvK68PC7MzSbM3a7M0qbMri7M7ybM/67M+irMwC7dAS
bdEarcrq7NEq7dIybdMWbNI6bdRK7dRS/+2bCW3VYm3Wam3U6qwE7IDXAgHYBoHXiq0EmO3X8oDZ
qq3YCkHZrq0OgO3anm0AsK0P1C3coi3czm0OxO3b8u3Xym3Y7q3bsu3dBu7fhm3b9oDh6q3a4i3d
+i3d8u3bxm3aPq7kjm3aRu7dQm7hNm7eJm7nDq4TRK7dYi7g+i3hgu7lli3qHu7klm4SOC7r7u3p
/gDnrqHlPu7rGu7ski3inq7n6m7jUu7wIi7n4u7k3i7otu7xsu7lQu/z2u7iZi7wzq71bu7iym3t
Tm/vXm/wAq/10m7g1m3zTm/wpq70gq/zii/1Gu/Ytm7ysu/yDq/50u/5Iu/2yu/+ou7qXv+U+4Zv
++Zt5VauAOPv/XYv7Bbw+w4w9ZrvAwtw4b5u/f6t/gaw5vqu+kIwA5evAgOw8IouBg9u7YJwBH/w
7hLvBmOuCvsv+m4v+/6u6a6w6GawCE+w/kpw7Oou4aavBa/vD2cZd8Zw5zKv+xKwCbsu966u5wrv
C58v5AIu2qpw8z6wElfvDFdw/wIwFv8wD3vvDdtuB0MvFVPwBZdwF39w+iLx+rJwCn8vF2PxEFsu
BOdwEYev/C7BAmfx58qwC1tx7rYv45qxB6tu9MquHQNxGDMBGSPxBuOwFV/vAtuv/0qyBhuy4hpw
345uAYtxIityEl/y9xYy9kayAk/yII//8e46Lu6Wbymjchc/Mg1PcANbMuwi8imzagDL8SfT8i5P
wRDrMRzzMhJ0cB2rsitHQSWbsSBPsfoegRj3rRHjbTDz7hxf8hZfcR+38TNvMQhzMv6+sDKDMzLf
cRPgcCOPLxrvXR638Dd7cSTHsjVf8O2esw3PcgszMPP6cBKf7Sg/sQw3synbsw4XLDALLh6Trgbv
Mz9zb+m6MzHz8TwbQT3L8h8bsiivsRfvqz2/LzPvMQJD9PyaMh6TNDdnMzbnczmH7kpntDOj9Ehz
dExrb+wyMumCcRl7Mj7rtC47L0JL9DwLMku/9E5rcy3/swsyc1AT70dT9D9T8jAbcEgT/7VTU3VT
Gy8uw+9M6zM5v3RQK7VSv3Ix260Tc7AbjzAyW/VQL/M093Fbwy9ZV/Q7W/QykzVGR/RRtx5Yp7QU
X3NfY3JYL7Ja/3RVK4E3F/ZgIzb/ovQpn/EB7/VP+/JFS/YV+/Qjk208y/Nj+7RjD3Zlx7NeTzXu
MkAL8PNf/3VTp7Vbw3Vqt/NCU/RrLzRlx7by6u1JCzYrzzJcw/RYEzQHnzVvi/Js169wa0T+1rVw
o/Y+s/Zb33NotyBpb210S/d0G+1o1wB1Y3d2azfMWvd2e/d3gzfHdnd4k3d5m3esjfd5q/d6s/cU
jLcTa/Lo3rJAQzZV+/Vmi/BEV+9X2/92URuBAAC4AOgAgA94gBd4EBB4AAS4gSu4gB9Bgjd4gUM4
hPsAhR84ECx4hu9Ahlu4Eiz4hROxX/P2Ejc3Udv1Y9+3UI9zidc356Y3LUtxQ7u05AY3W/fvKtM3
Z4v4Uusyjuu4P39xP+94gnN4DhC5gx+5kSP5kit5kz+4g0d4lCd5g394lEs4g/dAh284lDt5lnO4
loO4Nsd2QO+0RW+zjBtx9tKzbv/4VcdvlUE3DJ8wQ89tNct5JzP2ZG/14TbxVb8yF+c5TmM4k0v5
klf5lCM6of83lCd6lW95l2M5lXu5EHw5pQv4hFc6gfuwYhu1LIcuK7u0HiMvUKu4Xp//MSNH9osb
NA1HryNjMArTOE579UzntkqL9CeLtQdHNWdb9ZEfOqEnupMH+6L7OoNP+aNbuYd/OZczAYFbuKM7
umbLeh5L8JyjbxQ/cTBD9myjdhkf8ZHFefe+8bhL76gfr4/Xsp238xKncgLzeCCvsZ4jAbQzOpYX
e6MbO7P/wK9feZgLu6Ev+xIse6TzgLNz+bCHeGdr9TET90STsEnvsFuD9GGH8LkLObhftwVru7i7
MnzD+i5XMSQ/vJ+PMVf3OU+Lc5BHtsDrO7Ij/BMkOZh3OaS3vMwPvMwjeMAXupOHPCL395DFdzgD
9Ij/vGV/NBsfPSmEe5qrcSc89Hxn/zut0/QbqzaMn3ZfUzFmTwHCD7ylbznOV3i9X7mGN7vO57yX
Y3q873rbjrnWJ/PQD7XRT7wco/oTv/htL3Zpf7y7I70WT/xU8zSsu3GnC/q8F7m/DzvOg/2+iz2y
z7zitzyVR3vYLzo77/rGr72J67etC74tc/w64Hm5J30uK7zD13U3v/mNX7zHqzglC73eNzaQD7R8
e73jd73kH/vtJ7u/F7zOEzymV/qk277ZDzraH37C6/j95jCL2zcQ1zPrQ79gOzM0Y3us80DK5PXP
l/WfZ7b2c7zGu73mQzVhb37z737aOz7lz7zw9/7Zpz/7L/76oz+x+z6z43zQ3/Pvrv/6IWcuCEiB
KAajiZ7pWq5o2b7uHM9unZLuojC5BAy2hMIbEfgr2mRLpg3XjD6lqhcxCr1ZjzOB9ytIgcdNL2oM
Npm76HWg7Waf4ba2mE51wcPLbN8Jc+RXRQNoIjiY2CdoxPXXhMPjk0dZaXmJmam5ydnp+QkaKjpK
Wmp6KiWJusra6voKGys7S1tLqmqbq7vL2+v7CxwcgCtcbHyMnKy8fNvD/AwdLT1NDUssFZQzckW4
nX2YOeQ4pEU5uKXdXYW4sqeG9sZnmpYXd2f/jh9v1x6mL/evnrx3ZQYKzBSHXz55awLe+0JwIUQ2
bszAizenosF9F+vwucbuD5SRLMD/lTz0TV0NcY7QKVFXbh3KloXu9ItoMyM9jmQeWpyYZg/DhhDJ
7Izy0+jGORwxSjyqBw9TnDp7OqWicapWOVcPOrWHjyhVnku3LiGK55pJlkp0xEzXtlwMGHJT4ljp
JO8UkyrubuFmVuzNsQH1afyJMyvGpAMZF6QatOziogYRI62M2ezXjQ4HXwXrz45gShdBR306mHFk
rJkjqu1bci4jlYQCjYMbO503wHzvzja09vc5skA5U04tNWdT5YoRH3V8NnQ/ywCP2+xM3PTYzVEV
ek7Y0ePTiVw/h5862vzjy6ddOzs5FzjfbuTWysUtf7hu/TSQ6O0fEmsPBcYHduNp/6feZFYRt153
UPm04GSV/KNYTgY2aBpoFU7YmGTRVaiaTgS6o9UaPCiwwF9x9aZbbfDN15tdetFlzm/GiNahVRce
ViB59MAD3WZhCUUQdaetdqBkQg2FVo7nCdTkktwtx1prnCSFXEQXTtcjCgygWFMS2iDC30y8vbUX
mVmsRCYLjKhp5kvZkdeeFCQOSKWWxRUZWnN0kiZdYX1KV+eVe0bHpXcLbSced1LaOaiihuqJyY/y
fJkimpeMdCaMe0ES5iOe+IUNopBeImiTN4nF6qCJ/VmVn12tap1nBSnUaoOodgmejl3OasmWDvZE
omBD4srrpWBqGpJ+pLa4WzZ4Uf8x3LOQ2OhpgIUyumujjqkqYj6L9rpUhkNNGSuhtgLLFbm6cqsc
lQjulF6V65qqWYk+GpdluAFgGic3pDqrBZyfenqwigJTy/BJXsWb6JJPcrloow5SVK6VTNVLa5JG
4luex792S5iHHD8G3sPwOjTkvcoBTO1s2iqsCZs0/RfzzdGm9N/MEM/JypYsK1mWpNd5+HPI77p8
mdGFOo1echlNDfSwD+ar2Z3lwVxN115/DXbY0XAtdtlmn4122qSQrXbbbr8Nd9psx0133XbfLczc
eO/Nd99+r71stAjjDG3CMOU2U+GFv6mwf40j7NuKKs7Y6X4z7uf44SesCRPPirj/ia3DNeqs+Hyc
s1R6zz6nrjl8L30uKi1cDxwmYM6GHheNMiVOuIvZJuybpprzZq3D9eWl+/HbyGAbXc/WZzuoB7Ml
p/Cmx05C7tLzPnj38Qn+O4vGQz55964wMEn4JJFfquj2bS4+bPG/Ja31zb+ouB/KF5+E49+4Jb/d
yQ+A9nkeOuRTsOltr2Dr856Y4pO9hcVPf4f7nuXGFxy78AyBvTtf+sCnuwu67wm4K+AET1iI462O
gOIAh/8kSD/QbRCDLoJefkyIGwP+bobzQ94CrfAD0Z0OgQSMCfU+1UDahG9362tgEmeBvhh2Dmdl
cuBu1pG55KkOiE8UYRd9WJfM/1kieuLTYhnr17/OZTFOWwxii2A3xvwxgRxFQN0Ns8UmIRqxEf6D
0f9qFyoopo9xU4ScGH+InyIisYMAstG0mnczC6LEep3Aix3L6ELLVbGQcVReD3f2OgFS0Ydm9IYA
N5lJPy4OEM1inxpRGYooNoyGrAtY9WgEwFZ+EpSwpKQMK3et1dkSjnuEjQUVyUs/ilFNdOwZI6fg
yVI185Ss3CAzmXc5Z+5SeNFsXStkqT7QUa6XNXGe9FSYhy8ukHQj3FnsKkFMDJrzevwJYQedGM5G
hvJ9v/zjNNGJQsMxEVo6FCU/uWezXIAzme7E4ori2chUMtSUVCwhIlf5TCWiie1TLYGoG+FHn1cK
jAvxtKQv04Q4ac7RoW9c4ztDGghm7ZOhtwnYQWGxUP7V0p7tVKn5AvnTzVHwpZIkKvCAyroqIhOk
PX1pLefYpvYJFKlMpeo903lRQDbVmzz1YP+qt1VvDhOrY3VqgLLIUeKdaYXA9B0fXyec0G01rWBN
Klk54VFf5tV89cyqEeXKSHKCYqF/K6xhD4vYJRA2sYxtrGPrttjHSnaylPVaZCuL2cxqNm8f3Kxn
PwtaQYZ2tKQtbSnQh9rUqna1rG2ta18L29jKdra0ra1tb4vb3Op2t7ztrW9/C9zgCne4xP1tCAAA
Ow==

--=_NamoWEC-rk8v0jzu41--



From nobody Mon Jul 21 20:19:42 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16871A03A7 for ; Mon, 21 Jul 2014 20:19:40 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -5.184
X-Spam-Level: 
X-Spam-Status: No, score=-5.184 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEwuTQTvr2Zh for ; Mon, 21 Jul 2014 20:19:38 -0700 (PDT)
Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B2A1A0393 for ; Mon, 21 Jul 2014 20:19:37 -0700 (PDT)
Received: from epcpsbgr4.samsung.com (u144.gpu120.samsung.co.kr [203.254.230.144]) by mailout3.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N9300CTOFWN3R00@mailout3.samsung.com> for rtcweb@ietf.org; Tue, 22 Jul 2014 12:19:35 +0900 (KST)
Received: from epcpsbgx1.samsung.com ( [172.20.52.122]) by epcpsbgr4.samsung.com (EPCPMTA) with SMTP id 54.7B.13369.748DDC35; Tue, 22 Jul 2014 12:19:35 +0900 (KST)
X-AuditID: cbfee690-b7fb56d000003439-55-53cdd847ad1e
Received: from epmailer02 ( [203.254.219.142]) by epcpsbgx1.samsung.com (EPCPMTA) with SMTP id 79.F9.03708.748DDC35; Tue, 22 Jul 2014 12:19:35 +0900 (KST)
Message-id: <89.F9.03708.748DDC35@epcpsbgx1.samsung.com>
Date: Tue, 22 Jul 2014 03:19:35 +0000 (GMT)
From: Kiran Kumar Guduru 
To: Justin Uberti , franklin blek 
MIME-version: 1.0
X-MTR: 20140722031815591@kiran.guduru
Msgkey: 20140722031815591@kiran.guduru
X-EPLocale: en_US.utf-8
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-EPTrName: 
X-MLAttribute: 
X-RootMTR: 20140722031815591@kiran.guduru
X-ParentMTR: 
X-ArchiveUser: 
X-CPGSPASS: N
MIME-version: 1.0
Content-type: multipart/related; boundary="=_NamoWEC-pmbgr7ernt"
X-Generator: Namo ActiveSquare 7 7.0.0.45
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOKsWRmVeSWpSXmKPExsWyRsSkStf9xtlggwXNJhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY9n8tawFNy8yVryctJutgbHlDGMXIyeHkIC6xIbV99hAbAkB E4l/p/ZD2WISF+6tB7K5gGqWMkr0rWtkgSk613YfKjGHUWLlqmVMIAleAQuJ+X82sILYLAKq Eq0zv4DF2YAafp1YA7ZNWCBZ4vuHyWBxEYFQiQULp4JtYxaIkLh/7gkLxEVKEmuv3mSFmCko cXLmE6jFqhInPlxhgYirSaw93QZ1qbjE34ZH7BA2r8SM9qdQ9XIS076uYYawpSXOz9rACPPZ 4u+PoeL8Esdu7wC6hwOs98n9YJgxuzd/gRovIDH1zEGoVi2JPU9aoGw+iTUL37LAjNl1ajkz TO/9LXOZ0J3PLOAk0TPpF9RMTYlHi1pZJjAqz0JShs6GaZkFdB0z0OrFszwhwooSU7ofskPY dhL/n+9mQRUHKVeVWNSkuICRYxWjaGpBckFxUnqRiV5xYm5xaV66XnJ+7iZGYOo5/e/ZhB2M 9w5YH2KsAkbaRGYp0eR8YOrKK4k3NDYzsjA1MTU2Mrc0o4qwkjiv2qOkICGB9MSS1OzU1ILU ovii0pzU4kOMTBycUg2M+veaniadlfbhT/m4b9NjptUfzopf5Iq92rpAO/7UHd7G78xnKnh+ XSrgy4uzvfomIW3ulxe9M3eWBh5/W+1UEREoa3ol3ypiV19fvOl9Xgnb/VySVtu0rkRc0Ui+ vTBm9effzvEmEwz2ZE4odjl/7f4ejTjtuCydr2wsEY/Db/rkZNoXdwgpsRRnJBpqMRcVJwIA Rb0BDmoDAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAJsWRmVeSWpSXmKPExsVy+t/tPl33G2eDDfrbNS3W/mtnd2D0WLLk J1MAY1SaTUZqYkpqkUJqXnJ+SmZeuq2Sd3C8c7ypmYGhrqGlhbmSQl5ibqqtkotPgK5bZg7Q VCWFssScUqBQQGJxsZK+nU1RfmlJqkJGfnGJrVK0obmRnpGBnqmRnqFprJWhgYGRKVBNQlrG svlrWQtuXmSseDlpN1sDY8sZxi5GTg4hAXWJDavvsYHYEgImEufa7kPZYhIX7q0HsrmAauYw SqxctYwJJMEioCrROvMLmM0G1PDrxBqwQcICyRLfP0wGi4sIhEosWDgVbBCzQITE/XNPWCCW KUmsvXqTFcTmFRCUODkTIi4BNPPEhyssEHE1ibWn26COEJf42/CIHcLmlZjR/hSqXk5i2tc1 zBC2tMT5WRsYYY5e/P0xVJxf4tjtHUD3cID1PrkfDDNm9+YvUOMFJKaeOQjVqiWx50kLlM0n sWbhWxaYMbtOLWeG6b2/ZS4TuvOZBZwkeib9gpqpKfFoUSvLBEbZWUjK0NkwLbOArmMGWr14 lidEWFFiSvdDdgjbTuL/890sqOIg5aoSi5oUFzByrGIUTS1ILihOSq8w1CtOzC0uzUvXS87P 3cQITnTPFu5g/HLe+hCjAAejEg+vhfzZYCHWxLLiytxDjCpAYx5tWH2BUYolLz8vVUmEt30P UJo3JbGyKrUoP76oNCe1+BDjREZgfE9klhJNzgem57ySeENjE3NTY1MLA0NzczNaCiuJ8969 mRQkJJCeWJKanZpakFoEcxQTB6dUA6OCv+WcFysdNdM813yvv6HW0z/N+KKMrIvu+0WrPX4r bfsbLyPleL1CeYXRvQUL5kQKb1BWu7FnSqOGfoHF+T0VJ+3TCh88PyWZ+r88gmebv13er8iz rc/clXXF9VQuvs5lSzZP93Lawb0nITU//+T0E0umMnr+OtZlt6Ll652jT67aeR7rj1diKc5I NNRiLipOBACOxFDT8wMAAA==
DLP-Filter: Pass
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XfIAA_MFnW5hqIq3leKLEcJg_XE
Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" 
Subject: Re: [rtcweb] New Version Notification for draft-guduru-rtcweb-codec-preferences-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: kiran.guduru@samsung.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: Tue, 22 Jul 2014 03:19:40 -0000

--=_NamoWEC-pmbgr7ernt
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6diA9ICJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6byA9
ICJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSAidXJu
OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bSA9ICJodHRwOi8vc2No
ZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiPjxoZWFkPjx0aXRsZT5TYW1z
dW5nIEVudGVycHJpc2UgUG9ydGFsIG15U2luZ2xlPC90aXRsZT4KPG1ldGEgY29udGVudD0idGV4
dC9odG1sOyBjaGFyc2V0PXV0Zi04IiBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiPgo8c3R5bGUg
aWQ9Im15c2luZ2xlX3N0eWxlIiB0eXBlPSJ0ZXh0L2NzcyI+UCB7CglNQVJHSU4tVE9QOiA1cHg7
IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJpYWw7IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpF
OiA5cHQKfQpURCB7CglNQVJHSU4tVE9QOiA1cHg7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJpYWw7
IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiA5cHQKfQpMSSB7CglNQVJHSU4tVE9QOiA1
cHg7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJpYWw7IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1T
SVpFOiA5cHQKfQpCT0RZIHsKCUxJTkUtSEVJR0hUOiAxLjQ7IE1BUkdJTjogMTBweDsgRk9OVC1G
QU1JTFk6IEFyaWFsLCBhcmlhbDsgRk9OVC1TSVpFOiA5cHQKfQo8L3N0eWxlPgoKPG1ldGEgbmFt
ZT0iR0VORVJBVE9SIiBjb250ZW50PSJBY3RpdmVTcXVhcmUiPgo8L2hlYWQ+PGJvZHk+CjxwPkRl
YXIgUmFqdSw8L3A+CjxwPlRoYW5rcyBmb3IgeW91ciBjb21tZW50cy48L3A+CjxwPlBsZWFzZSBz
ZWUgbXkgY29tbWVudHMgaW5saW5lLjwvcD4KPHA+Jm5ic3A7PC9wPgo8cD4tLS0tLS0tIDxiPk9y
aWdpbmFsIE1lc3NhZ2U8L2I+IC0tLS0tLS08L3A+CjxwPjxiPlNlbmRlcjwvYj4gOiBNYWthcmFq
dSwgTWFyaWRpIFJhanUgKFJhanUpJmx0O1JhanUuTWFrYXJhanVAYWxjYXRlbC1sdWNlbnQuY29t
Jmd0OzwvcD4KPHA+PGI+RGF0ZTwvYj4gOiBKdWwgMjIsIDIwMTQgMDM6NTYgKEdNVCswOTowMCk8
L3A+CjxwPjxiPlRpdGxlPC9iPiA6IFJFOiBbcnRjd2ViXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRp
b24gZm9yIGRyYWZ0LWd1ZHVydS1ydGN3ZWItY29kZWMtcHJlZmVyZW5jZXMtMDEudHh0PC9wPgo8
cD4mbmJzcDs8L3A+CjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iQWN0aXZlU3F1YXJl
Ij48eC1ib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4KPGRpdiBj
bGFzcz0iV29yZFNlY3Rpb24xIj4KPHAgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwcHQ7IiBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6ICJBcmlhbCIsInNhbnMtc2Vy
aWYiOyBmb250LXNpemU6IDlwdDsnPiZndDtUaGlzIHNlZW1zIGxpa2UgYSBwcmV0dHkgYmlnIGhh
bW1lciB0byBzb2x2ZSBhIGZhaXJseSBzbWFsbCBwcm9ibGVtLiBUaGlzIHByb3Bvc2FsIGFkZHMg
NiBuZXcgQVBJIHBvaW50cyBmb3IgdGhlIHB1cnBvc2Ugb2YgJmd0O2NoYW5naW5nIHRoZSBvcmRl
ciBvZiBjb2RlY3MgaW4gY3JlYXRlT2ZmZXIsIHdoaWNoIHNlZW1zIGxpa2UgYSBoaWdoIGNvc3Qt
YmVuZWZpdCByYXRpby4gQW5kIHdoaWxlIHRoZSB1c2UgY2FzZXMgbGlzdGVkIGhlcmUgYXJlICZn
dDtoZWxwZnVsLCB0aGV5IHNlZW0gc29tZXdoYXQgY29udHJpdmVkIHRvIG1lLCBzaW5jZSBpdCBz
ZWVtcyB1bmxpa2VseSB0aGF0IHRoZSBhcHBsaWNhdGlvbiBjYW4gbWFrZSBiZXR0ZXIgY2hvaWNl
cyBhYm91dCAmZ3Q7YmFuZHdpZHRoICZndDtvciBwb3dlciBjb25zdW1wdGlvbiB0aGFuIHRoZSBi
cm93c2VyLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHByZT48c3BhbiBzdHlsZT0nZm9udC1mYW1p
bHk6ICJBcmlhbCIsInNhbnMtc2VyaWYiOyBmb250LXNpemU6IDlwdDsnPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQXJpYWwiLCJz
YW5zLXNlcmlmIjsgZm9udC1zaXplOiA5cHQ7Jz5bUmFqdV0gUGVyIG15IHVuZGVyc3RhbmRpbmcs
IHRoZSBtYWluIG9iamVjdCBvZiB0aGlzIGRyYWZ0IGNhbiBiZSBhY2hpZXZlZCB3aXRoIG5vIGFk
ZGl0aW9uYWwgQVBJcyBhbmQgd2l0aCBqdXN0IHRoZSBwcm9wb3NlZCBpbnRyb2R1Y3Rpb24gb2Yg
cHJlZmVycmVkQXVkaW9Db2RlY3MgYW5kIHByZWZlcnJlZFZpZGVvQ29kZWNzIG9wdGlvbnMgdG8g
UlRDT2ZmZXJBbnN3ZXJPcHRpb25zIGNvbnN0cmFpbnQgb2YgY3JlYXRlT2ZmZXIoKS9jcmVhdGVB
bnN3ZXIoKS4gPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0nZm9udC1m
YW1pbHk6ICJBcmlhbCIsInNhbnMtc2VyaWYiOyBmb250LXNpemU6IDlwdDsnPlNvLCBJTU8gSSBk
b27igJl0IHRoaW5rIGdldENvZGVjUHJlZmVyZW5jZXMoKS9zZXRDb2RlY1ByZWZlcmVuY2VzKCkg
YWRkIG11Y2ggdmFsdWUsIHNvIGNhbiBiZSBkZWxheWVkIG9yIGRyb3BwZWQuPG86cD48L286cD48
L3NwYW4+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6ICJBcmlhbCIsInNhbnMt
c2VyaWYiOyBmb250LXNpemU6IDlwdDsnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPjxw
cmU+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQXJpYWwiLCJzYW5zLXNlcmlmIjsgZm9udC1z
aXplOiA5cHQ7Jz5UaGUgbmVlZCBmb3IgZ2V0U3VwcG9ydGVkQXVkaW9Db2RlY3MoKS9nZXRTdXBw
b3J0ZWRWaWRlb0NvZGVjcygpIGluIDEuMCBjYW4gYmUgcXVlc3Rpb25hYmxlIGFzIHRoZSBhcHBs
aWNhdGlvbiBjYW4gc3BlY2lmeSBjb2RlY3Mgb3JkZXIgcGVyIGtub3duIGNvZGVjcyAob3IgZ2V0
IHRoZSBsaXN0IHZpYSBhIGR1bW15IGNyZWF0ZU9mZmVyKCkgY2FsbCkuIDxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQXJpYWwiLCJzYW5zLXNl
cmlmIjsgZm9udC1zaXplOiA5cHQ7Jz48bzpwPiZuYnNwOzxzcGFuIHN0eWxlPSdmb250LWZhbWls
eTogIkFyaWFsIiwic2Fucy1zZXJpZiI7IGZvbnQtc2l6ZTogOXB0Oyc+PG86cD4gW0tJUkFOXSBO
ZXcgQVBJIGlzIGFkZGVkIGZvciB0aGlzIG9ubHkgYmVjYXVzZSwgaXQgY2FuIGJlIGNhbGxlZCBv
biBQZWVyY29ubmVjdGlvbiBpcnJlc3BlY3RpdmUgb2YgaXRzIHN0YXRlIGFuZCB0aGUgb3JkZXIg
b2YgcGFyc2luZyBpcyBhbHNvIGVhc3kgd2hlbiBjb21wYXJlZCB0byBwYXJzaW5nIG9mIHdob2xl
IFNEUCByZXR1cm5lZCB0aHJvdWdoIGNyZWF0ZU9mZmVyL0Fuc3dlci48L286cD48L3NwYW4+PC9v
OnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQXJpYWwiLCJz
YW5zLXNlcmlmIjsgZm9udC1zaXplOiA5cHQ7Jz5UaGUgZHJhZnQgdGFsa3MgYWJvdXQgZnVsZmls
bGluZyBBNSBpbiBbSS1ELmlldGYtcnRjd2ViLXVzZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRzXSwg
YnV0IEkgZG8gbm90IHNlZSBhbnkgZXhwbGljaXQgbWVudGlvbiBvZiBob3cgY29kZWNzIGNhbiBi
ZSByZW1vdmVkPyBwcmVmZXJyZWRBdWRpby9WaWRlb0NvZGVjcyBjb25zdHJhaW50IG9ubHkgc3Bl
Y2lmaWVzIHRoZSBvcmRlciBvZiBwcmVmZXJlbmNlLiBEb27igJl0IHlvdSBuZWVkIGFub3RoZXIg
Y29uc3RyYWludCB0byBleGNsdWRlIHNwZWNpZmllZCBjb2RlY3M/IEl04oCZcyBwcm9iYWJseSBh
IGJhZCBkZXNpZ24gdG8gaGF2ZSBjb2RlY3Mgbm90IGluIHRoZSBwcmVmZXJyZWQgbGlzdCBiZSBy
ZW1vdmVkIGF1dG9tYXRpY2FsbHkuPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBz
dHlsZT0nZm9udC1mYW1pbHk6ICJBcmlhbCIsInNhbnMtc2VyaWYiOyBmb250LXNpemU6IDlwdDsn
PjxvOnA+Jm5ic3A7PHByZT48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6ICJBcmlhbCIsInNhbnMt
c2VyaWYiOyBmb250LXNpemU6IDlwdDsnPjxvOnA+IFtLSVJBTl0gVGhlIHJlbW92YWwgb2YgY29k
ZWNzIGlzIGV4cGxhaW5lZCBpbiBzZWN0aW9uIDYuIDwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxz
cGFuIHN0eWxlPSdmb250LWZhbWlseTogIkFyaWFsIiwic2Fucy1zZXJpZiI7IGZvbnQtc2l6ZTog
OXB0Oyc+PG86cD4gICI8ZW0+VGhlIG9mZmVyIC8gYW5zd2VyCiAgIFNIT1VMRCBOT1QgY29udGFp
biBhdWRpbyBjb2RlY3Mgb3RoZXIgdGhhbiB0aG9zZSBzcGVjaWZpZWQgYnkKICAgSmF2YVNjcmlw
dCBhcHBsaWNhdGlvbiBhbmQgdGhlIG9yZGVyIG9mIHByZWZlcmVuY2UgU0hPVUxEIGJlIHdpdGgK
ICAgaGlnaCBwcmlvcml0eSBmb3IgdGhlIGNvZGVjcyBmaXJzdCBpbiB0aGUgc2VxdWVuY2UuIjwv
ZW0+PHByZSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7
IGxpbmUtaGVpZ2h0OiBub3JtYWw7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBu
b3JtYWw7IGZvbnQtc2l6ZTogMWVtOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDog
bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0
b206IDBweDsgd29yZC1zcGFjaW5nOiAwcHg7IHBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7IC13
ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSJuZXdwYWdlIj4gPC9wcmU+PHBy
ZSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IGxpbmUt
aGVpZ2h0OiBub3JtYWw7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7
IGZvbnQtc2l6ZTogMWVtOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFs
OyBmb250LXdlaWdodDogbm9ybWFsOyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBw
eDsgd29yZC1zcGFjaW5nOiAwcHg7IHBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7IC13ZWJraXQt
dGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSJuZXdwYWdlIj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6IEFyaWFsOyI+UGVyaGFwcyB0aGlzIGlzIGluIGluZGlyZWN0IHdheS4gSSB3aWxs
IG1vZGlmeSB0aGUgc3RhdGVtZW50IHRvIGRpcmVjdGx5IHBvaW50IHRoaXMuIEkgZG9uJ3Qgd2Fu
dCB0byBpbmNyZWFzZSB0aGUgY29uc3RyYWludHMganVzdCBmb3IgcmVtb3ZhbCwgd2hpY2ggY2Fu
IGJlIGFjaGlldmVkIHdpdGggdGhpcyBjb25zdHJhaW50LiBTbyBJIGZvbGxvd2VkIHRoaXMgZGVz
aWduLjwvc3Bhbj48L3ByZT48L286cD48L3NwYW4+PC9wcmU+PC9vOnA+PC9zcGFuPjwvcHJlPjxw
cmU+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQXJpYWwiLCJzYW5zLXNlcmlmIjsgZm9udC1z
aXplOiA5cHQ7Jz5CUjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9J2Zv
bnQtZmFtaWx5OiAiQXJpYWwiLCJzYW5zLXNlcmlmIjsgZm9udC1zaXplOiA5cHQ7Jz5SYWp1PG86
cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6ICJBcmlh
bCIsInNhbnMtc2VyaWYiOyBmb250LXNpemU6IDlwdDsnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPjwvZGl2PjwveC1ib2R5Pgo8cD4mbmJzcDs8L3A+PCEtLVNQOmtpcmFuLmd1
ZHVydS0tPjwhLS1raXJhbi5ndWR1cnU6RVAtLT4KPHA+Jm5ic3A7PC9wPgo8dGFibGUgaWQ9ImNv
bmZpZGVudGlhbHNpZ25pbWciPgo8dGJvZHk+Cjx0cj4KPHRkIE5BTU9fTE9DSz0iIj4KPHA+PGlt
ZyBib3JkZXI9IjAiIHNyYz0iY2lkOlo1SkU3RVVBQkdGQ0BuYW1vLmNvLmtyIj48L3A+PC90ZD48
L3RyPjwvdGJvZHk+PC90YWJsZT48L2JvZHk+PC9odG1sPjxpbWcgc3JjPSdodHRwOi8vZXh0LnNh
bXN1bmcubmV0L21haWxjaGVjay9TZWVuVGltZUNoZWNrZXI/ZG89ZjRmYjcwYmE4YjcyYzllYzU0
ZjQ1NWNmZTUyMjAwNWQzZWY5ODhhYTJkYWFhMzJkNTJjY2FhYTVlNzhkNzkxN2E1ODZhOGM5OWRm
YmZiYWIwZWRiZTY4M2M4NTNmZTcxZGI5ZmRkZGRhMzNlODJjYmU0YTM5MTQyNGU2MmZjZjZjZjg3
OGY5YTI2Y2UxNWEwJyBib3JkZXI9MCB3aWR0aD0wIGhlaWdodD0wIHN0eWxlPSdkaXNwbGF5Om5v
bmUnPg==


--=_NamoWEC-pmbgr7ernt
Content-Type: image/gif;
	name="201407220849882_BEI0XT4N.gif"
Content-Transfer-Encoding: base64
Content-ID: 

R0lGODlhCAKQAMQAAAAAAP///8k6OspMTNRiYtt0dOSOjumiovLExPfZ2fvt7f/+/uvr69TU1Lm5
uYyMjG9vb0dHRzMzMyoqKgICAv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEA
ABUALAAAAAAIApAAAAX/ICOOZGmeaKqubOu+cCzPdG3feK7vfO//uYBwSCwaj8ikcslsOp/QqHRK
rVqv2Kx2y+16v1YReEwum8/otHrNbhcX8Lh8Tq/b73al2M3v+/+AgYKDVniGh4h1egyEjY6PkJGS
k0OJlpd5SXsBDQ6engwNjFKilHoNSaVYqkisTK5CoUqdo02waLJMubGogg6Nt1S/a3IIeAoJmHAJ
CnTIipq1EBETFBERDRHDUdqmSQ8PSd1GENzbR+NN6UPgqRPYr+Hrae1MDhFE94MUfA3hRvOKlHPC
z8xAIXIG4EFQAJGBOQWMzWEIDckmIfqEBFR3zhuWgk82DhGJrmOAekcy/zJpR5IMSiUqA8T8A5LN
yyc1l+QEU9MSxUMKD/2cs6iIyggQKExAxSCCtVoBmlKgIC/pBEZSIzBw8I/ryWr/hDSYRjUpvq9U
ozpdGiBp2rZTyzUAO9BqLyHt3IZt22Cs03Jm0YbzS2HgA2sTfj0AixfxNqlsszLqtjgtuAfDMA+p
BlgpqgdJh82d8ACpZ7VPiUA4HNlp2tVKHVT7NbewWKUR9kpNy4Azvt6F8SGdIBg1W71C7CY/rTru
ycr/kiYlAm620+hxm4o9K5ax5Las+04gvTschL5kD8LFBmFCZ9twp8NlO6S21uJfE7dNygD6+kpx
NGTAAQMQkIwCBAxggP+AySTw0AEJPmTAAAU4SIABBiQDIYUKDCVHUflwd81JgJWomlz8UMMABCay
OFdyDzBAgXh3OTBjA1T1JsqNS5VG4lxbEVeaCEut1hQ+i/VHHDsPACkbEdrYuGNfFDggI41SXnml
jVbyiGWV7CDZYjnaXDmXP+CcNWOY/ly12En3xeLiiKDtZ+dISOLDIicpCucmPuTlFkBiMu61J47g
HZnoiFWK4KWPoDkppJuTKkmdVjomieiQ8uHl5o38DKkjW3Vu5gCOK5pIp1YuHpqiJzNeWV+VNjIi
ao+shkoplPLE6OWVbyLlKI04bpPQAgU0dICAByiQLLLGUDSAMQMkkMD/tAgMoICzCChQLbIHeBgH
iEMc9Ys+a8pIhBg2BiCoumsiqh8F/dUVVkYFaVPqaj6KIBsjvQCcGL0yCTcMfc8ByQmUnpzVTaj2
ZqTvQIntCw7F2/TLSLyvWgyOjEGG6O7BaBbB0rn4pFtTN/qw++pzBb8Y85KrrctIuwT7mHPKeNmr
8b8Lj7OU0HdFxUnF/7yMKJMFC1GQwA7sqV93GMmKKMtIhuPyyBKfw49KUHdzNckjDUYijKXKo5i9
AfQUh0IRLSBtM8tCK3dD3yazgEI/xd3ggOLCQS5GIqLc9lRTEWHfy2037jR4Lx6G+L1qasQV4jlS
E2N8TK01MOHuYp6x/3mFFR2lw7+EijlmqNej7+quP6b5xkN0DHuvNZdrsOU3ndw05isbvvjIMN9j
I+LanPXS8AWhC3pBkk8V4+ych474PaIPARnSj49TUzv4GpcYkDXFBNLL+rQz/OmWE/H1Wdsb3332
3QkaPVUvUba64wi9bbe0cKBI3CgCobjt7W5wiNuECECAcDWEDoNrWvucJxYiTO1l8MLK19xTjnoU
LXwj82BUQtGeqPiDXnsaGcH0MY6iqa8/BLNc1xonwq7FToSx0x4JiUMwdenrH58JB2jWpDviDYor
e4EZ1vhnOsNdkHjgS14stqK8vTyxeTz7HV6AOMKxECcUh2mKaIxYtP8U/rB7w/heOMJnxl9wUGQy
AVlU0Je1QSWNa6hznwTb6D0yKq5g/KpgPdQGs4XxLwDHGiDeAtgQRS6AGcs6wAH7hoBl0c2BFTnC
RSRIPBaucUlOs1WKOigcIZ5lPKgAmqBA57goXcVdoNEaVU4pv2KxSFH9QthlaDmShrVvg5NhneVe
VCxVYoY4xRpCzXxoSq69MjftkBEoQeejTSXRd56UyTSXmLOXRbFtnynHmkjjPlHCsi2lRKfjjLnM
WQqhYr/BVVQQJrYq1QNiJ1GjBJUGptAUgV4gs9/u0heObuKxfbWTYD250sFQxfMuhLqHwnLzoiex
7JkFxQgi/efIAkj/ckHgWsCyEkCAZgxokg+MyAEegiBMQjAaRilc03DklHO0xz30okY1UEFTIjpF
meOZJgi7cVNkIiZGQcWHjaiRG+BMY57UUM/HksqwGY5nRUFV6C+KutWstiWo26ApOXuKCqJm1XVJ
bNl4wNS7WQrPGmDqZdNuyh/KrBFJ71jTYsZjqPHwR6z4GM07+FdUPs2Oqr2JKlTdkw/EQPOOvckr
de76uKW+Y4072SuKnFJWwx0GNH7NqS+N+M7EnMWyTR3PTxPLWHYc9avjSc5sjFjYQV2FH4mMVkNI
ysCGZCtZAiJAAQy0AAZS0lvDxVDgFhDBJpzKCH0xSi22ApUidAIK/9eNxXMxcpfsnsRW3NluSoqm
BytxwiT5gIp342iErdyFutA1CcLGOwvylsu+0MVvfGsR3fyuq2i7sO5jxCtemXzQvutNCXbPUSrr
vte8reCpfjUJYbF05ML2ha+F84Ff71I3HIh4RhysVQyJLKBDzZgDig3RXI9MYTGHQa+Ln+CXGdsY
DIuR8Y2x0B+PiEAZQA6ykO/AJB0bYchITrIcFNAsJTs5yDvOgieiTGUt/BgTzLhElp9siS0X48R6
C7KXtZxiMSNgzGM2hIjn4OU1TyTMSXYzi1NRXezWeRBGhgkYaHNn66q3zyaUQp4DrQmeArrQTbgy
HB5yCAMmwtFcbv+0if13AEkKudJAxnSQfwtpSN/hIct19HIN0EAlg/qBiDiCP0grhZtoQTNLWJFO
qLATLYQqiSVhWBJm0oRaxxQmu3tCOXitSQYcS9KX8HSkM23pIGsaE89WRrQDNOk7BMUOyqZDtoF8
bUscwXeEaAkrk+BrJpT7CucuwjpIQmwstHvcUHhfoo29aAqJtECWJhBxC7DAZAyoQAcqAIfs1u9H
ChxDzoJDwkccoQSSesQLGoAkLYShBBQgxRlS1sQbfm9+N4jj1xJusx+ZoH0T6OKPLJBHi8FASTpr
4P82EG9XqiEKEcAYG5p4xCVEIQedWOASt9syJKTvBBT95SjHULX/Ir5Se9+bQxOqEEsFnvSij0sy
siGNaVqTGhY9JRtb7Q/pyDkfF1ZmbVWqTUOXovbupOUvZV9OpwqZNb7KvSDKGWJYq8GW3FhDI4ep
HPjsXh53WWUyilHKXlrmGsw00ysjeY7d10NFvnCiHE7VE3rgHrqnKtMasuE8a3RD75SfWebaIqnR
CYAsZT3kWXXD0AJkr9KLQ2j2BnBWQ4i7Ujk0sKV761YcstUsbWVrWxE5KUkPiOnfe9RbHZpWcZu1
8ptfa+SlrlvQq3/moMfh5seXPe2VdfGKR0T12Tp9t4xfLW9ZC1sCesjyRd1I8jurWeJ/fe6z9f5m
ydzk14IAFJF//60nUqhmJ7c0J2KCgGQCAWJkI76SMFfxJEPyJK7VCUJyH+QRKEg1PeEwPvSyGP6g
FRSYK5P1OEnSLpziUCHzJhbUTIXRFAXlgIJya0dUK4dCHCqyJ9pwJqhSRK7CQvyQOyg4gSyIFCxk
ODxoMFkyIyuoOLQSK/TigzE0QsfSe7NXaYwmSR2lW3vTIHDDEJZmINqCQLJ3cwzHSAfEcovmUrUn
Ug+hEJWGAKx3N1gIfnXIEMuXhUt2YtoHB5W2hye1DHnofin3PxoHLXdYSYwGOClFLQi0LXIThsPX
SF4YN3lDiT8RFH7zc5LEN3gDhog4LhyjRIajMlCUJlIEDkBTVv//oEsUUzIWmISziA2vZCXZNChg
xycnSEN3VE/npIs3gRU6k0opY4y+KDNWsjWr1DFsAzpbww/WsIsJdU/EsxVJ+DvgdVAj0w3qokc2
9IxWSGkDUI4SF21diEDXFoYGFBFBQRGq120/AUDF8EBz+IjFZTdyGC7mSCGaFhHZYo4RYY8jp2/P
EhT3CIjN5iHrOIqYplKWplL96IaQCI8JInBCh0Dp2JCOtIYKVCClBopreEAdyVznY4q/gzmdhBQw
JkSkcx7WMxWjwzuU1TRRgjlSVESuIZN9xDS+iEbzcz1t9Q5ZREHOw4rccTRwZUS2MzlFNDyJ4R7t
okfWmA7ZaJT/TIg6PZlQNrQ/U3SFlqYh+TaKjlSG3gItBnRzZfgTF8JoAZSHi1SPCklJ01eG+/gT
27KIeNkhBMlwyUCPCSlSC/lA69cMZ+lID1lJEamYy4BA+ohAaEiSJiZAl0gthqmJD8SJlYRymCaS
ZomZpKhBKElBQUMboAd6MANGQzNGPnlGtciN/nJalddCTNmLNtg4fUSby8MWWLlOPIOUVfNE3tgx
XFRETzQNuUEN/1RISuNL3AQ67NONv/CNXNk6xfmV/kNSzeBRy0eHZHmJklQ3b3gtuKd79VZt37Jy
3TaJyWAgdAkhjLaPXwiH1xJ91KIhcdgMpfaWCRSXnamfI6ct/+63cuLphYm5fAGoneBCl55JN5So
hulIoJbomJrZe8AnkhI6ioIjUKOZThZ1MDqYM2nyTlzxG1X4JtbkNK5IPHolTsOSPiZaL/lEHcN2
m/h0GHAyR2KXD0vCKOZRUD/6kwA1IwaFFDnagxhVRAYFYzaiHj9JQx0EAdnkI4LyVNGpLyYIjqgz
UWGhaMVVUqTGQIuWIMaQjvBIIenZLQxUagiiIIS5npPIQM2wnnTIQKeWQMZwfXAgnyf3LfqGhn1a
cy3ne3bKeggZniBZkHaacgKXDIjJhd0SpmgoqY4ZN8YVXBdSLfT3nYyaphSKp8jVll96po2qocxF
VvlUGm9VU/9G9FMlBDOIpVNSFVQu6SlX9VWXw1n5gSI06FeLVRM09VPWyFr80BS+ehNBVUKI8UrL
SjvtoFmwlRTZsFadBVtCpSehRSW+kkQ2ClUzog9LNSKClZXtIx05MR4zVFvYqXDClwCTJnyJsGJv
Boh0Y49uKQfuegd6WG2WsGJGBwfEdWLwCmZ1MLB1IGfLEGbyiggGm692sLAkFmQLewgLW7EG+1Ia
xgn4lbFOUGAF9hwfu2HlghUV1l/nxV35QGFLgGEwUQv0sg0vmwrdRV7olWCKM2FOwLGExgtLoBlL
oz0Vpjgd4aXLhgcQQiA4F5mXsFxAhiALUodFG7VSO7VAFgj/rlZly6lHWCsMs+SkUUC0VDsHcxhA
/IoI/+pkRtdkYbu2bNu2gTBlW4sE1xS3wnC1ULAJuxBgQgtdgIZEYJC3OGsEnxC0W6C3WsAKnTC4
h8azMPExXICNcFu4gdtegwYgIwZnbftIZXYMmMu5dUBiZbtpSztkz5Bmn7stnXuwqZsHm6ASxLZU
ACFj17AYXhsGHWQenNRr16CrWzBsSbkF6TAN1XANk/tuXwFai9uz2xCut6oJtUsOudsEItgKezEH
F5K5jwSpiDBtC4FqctCZTwandRAuIwlklEkH9wotTKtwDzJyLNa64fW7WwQFPjJPlduxSZluSAAS
DZYF+msF//NgvL9Gbr1AhFNglSKCa3A0awe8SkbwEvg6XNibmMu2XNy7ttu2tN47B+K7vo55CSNU
RNQEHaMxPdLDF150EAjzXP5BGEMUWGSBHWwBFhczjZjnFPfhd3HyONBZQtAha2qhlHKRHusxFkIM
eKlRH3y3efAReFMjwilceJmHGjvcNqNQCt8hFVGaGLJhG3vVCyrBEiWkHIyhHFpcxHLBGUhcxYOi
HW7XJJO3UQppABIRc+5qaZUUB/8omAnickD3UX8zc/wGcCSnIA7XQAdgccD1cwPXpiA1YirHhYV8
cS9HXCRlyODij3KKLFlIyC93jgxkcfVGXHZ8sBHCIJdcfv89R2oVV6dB53Ozd8mVtnGG7CAH9yHw
W0SagkLn4SpcA1AJVQQycipLISU4glSdkCMhuCsiCA7FpCcm8nZ7wb/itIxSeCZnw4FNSCW+xIFt
0ysWpBjacM1nwiUDXCupwotGMiJ7kkLJQVHKNCa9wRWvxIFzsTmcVIOKwcw9siu3BILd7IHfHIwY
UQ6vdESo4iKWW1xGx2iwVyGc2GyaJoclRZ6yR56KpADm53rTd3/Bx2TNIoAgRYADYp7ft36fGFIe
VTe953yf6H+vl9IPjXskR1LFJ1IldXszjb7UZ4krx53YIqAAKXHo94gQkrYd3UD8Z4iCk8sjjIJa
czOvMhP/mRUxleNMMEI0BNU46MJT0ji/tXMNO+U4FlMzFLUkxpNH7yMzOgPWFdQfOTkxJHrO8CPV
VpyjqEijp4GKK1QyyhhsMmENOsXDWh1sS9HXXG2LeJFFL1EzNaOMO2q5y4cgeAqZhanHliafBySJ
2eKQ2ssQ3mmAa6hpqjefZ1mGdUOIbUiSEyfaqAuXHolzMu2FnE2JD2ogJZkQ9YqWrY1SeBrajvjb
GreHK0WXTV0LrltHP7k+o1U70xXZwNlKo5UmorPV8naS0DPNnxDM9yNMRog8M/Q+GUFBLyE512BD
/xDAp3UWzPM8KtleewI8hwQ+OElasuEJd5Evw8A+O1kl/zkh3utN1lb0DowVExAcQBRSqog5IN47
0YK5p5MMmhQM2oTpn2OY2f24hkPxE+BLUivnLL8XkOUYl3EDvo6UyrYtdAPphXTwjpbo4ZldqQJI
kJREQC5F4ZV93Eqsy3fUDmQ31b+bDrFk1YQ93apaQdatjXMk4FqrtSJUKMSREbH5SwXzmtmtxMaI
3gglwhlxRc9TH+UCSqSJCs0ji3Vt3/Kr3ySajQtT5olt5W49F58gb3F04AuKACd14gpSkDHu4JEp
4Z8dEbB9qKIN4Y3p4pWokAf0l/yGuqS2l7H94KC5nymelqD9wcdGmYwehzL+E8GtvhoX2jiekSFc
O71gP/89XlDmFJ1hjhXjcxU6MlSwggryFOt1JG8ceuXBrLXG5C7NGE7h/TsrquvapBFx7QlGdWEB
ftc4WqUeOk1xVSeC8qGwdE/hhOZGAD2BJW/1K1rndN3D7tZE+DDDEk2o4D+q3ZECt7m919kOjtpw
E56JWJaOmtKCWZ8BIkneuXKPvKftmdI3x5cnddr4Gekm7oXw/ph1g9G0DWf8boloCEA13n7uyXre
MuOSXu90aQyl7ilMZSupHq2ixWvtcR2y5R6VJ91Zh/Ksxas+blqGtSbEfkg8bK2N0QuLwVlWBfN7
xaxubVvuAfPEw1V0ffJ/5Vgxfw42ElQAA1e0cVb/kPP/a9Iew8BrT7NWpumABJ7GsWVb6cP0TP5O
d1En0PpZ7QCI3qstHZnakJwsmq0QYToh0bfIBLIsBrqmc6qQBGKO3SdwebqmDb6mKX1yDXQtwxWe
wvUtminpoxj32vLoCoEgZOrZ+Ar4imhzknSpv72mjAb43TcgiC+nDMpcm+RetjC5FlY0NhtT6yVe
HlZhOksKOkYLFlGylRuy6YVdAEaz+PWxrl+zFYb7SPD7KCuyUWH7VGCyJosJg7hkoZuw+ApnEctm
z+8MZxYHCPtInSuvHRJm7rq5WgZn1z98q8tkKrb98DqxI/auZeawy/D8ktTxjSDAdFv/9n8EhkBq
4I+9//wPAos4kqV5oql4KKr7wqlyLAHDBLm+873/A4M5xkNoPCKTyiWz6XxCo9Kd65CIYbPaLbfr
/YJdNkZYlGiV0yTEtYSInU8JBLocV8feWb25ruKLAOJxCboUqtxxJZosdi3GCR6eFNo05DQ44EA5
TD01aB4xWOrcpB3QDJYZEKAuHLwNxBQUKgwUtH0l0MymjryexGYFr7Se/A6LIPcKwxxn8cYYlECT
/FJ7nVbTKMcqSKso1zhE2FBEjD5RdDo9FCGN75Quz2td84bvFZgWL1974ae4R2+gCH+pAE57Y3BL
NhP4EOgDZyIAPHhS1K3L6MPiEDK+BhC4oqCArRYGDv+AnIMKwaldKAu0eGkA14IEBAZ8K7DKFyp9
NkvWvPltxE9pKEOuSIkTaNESM0/d3IVzgYGUrqoiOAkSwc03I0G+IsBqJlWrUFk5ZSq04EtXKX8i
1XcWVVWkZatqW1DgZZ2jCZbC1Ot2ajWrXwNrJcB1wJvEixUS08tXcNnAcHWl1HfYpF8SM7/aTTq1
6q1VBsj69bs34kgSe20V3Fn3yoECYmlkW5pT72ird8NRJBeBAoQh5GyQazCBeI7j7XYQN4dDOYUJ
DR5wCoA9AITq6LR3d0C9OMUJE9x1t679QQRNED4Nb29jOYTjHYmGPECAqrTTevef9hdbubn0lwII
MEb/AisKoMVYX6jEspdkCywo4QgLVsiCCCOxMIBLFLJgYUEsEXDgfvrpApN+rgRWgD62zaCPfwIG
OIt+M5xYIoLVwKQTiAxuU+BeQLK4QCw37libiSx6gwyBE244pIcTxjLAGaHZpAuA/Unj4n8x6vVi
ibUZGdmUEh7ZozRoKSklf296SeYINso1lJFXJvAXAggqMBIb+ZU45CxIHWAnThwaSYeSKyJ54jYG
IHpkfjBxxSReJQSnnXo5qPdAcecxcF4AGD2nAwVFRFCEqOx5yul1EzDgwAQ7sIcDqKkGMIEDDlBA
RHuyrgdBEcpxVxwExhYXgX1j+PLNNlcIaGEsitUy/8M2xBQqgmL4BaKPMg1FSAO0+y0AEbflvgiI
QK5YQa65c7IEIbpQ5tfTG9mY22e5R+6SFSqKgeuaV392Wya7er0hEpn8JkNvArwIyJPBDY048bVW
1lSNs3fWFOG9NJjLC77emlkyLwcu0AKYAmEc7RvvjkimviO03PC7Nm7Myyz+bUvzFeYGYyHA8ub2
M8kh//twwsBVtOyxue46a6akupMD1TbYUKs6wArrqg7PARscsRQFgGuu12FHTqsUWMKAOr1qt6w8
B9NcNzRHniTXtew2RM27QJcQsE1oITiA4RHNO689sBBT+OECBxyyHjbae7C5P5F08CzQUN4wvCP8
Tf+y5vfe5CXDZZJkOGN35xUMxQhbXKZ+17w+jMeWp4t77K5fSztIXrJs98uIIzzSgtUQwPrN8QqM
cJbcFBz05MzLvjfgIau+uh5Mk8NRAMo1sPVx8Fxtag7PPVCdsme3OhwF72e3HkXvvx+B9+7D347b
ZXNC//uj5sB7c2vINlR2uzL95SQH4122KMSHSs3rW/IymgHeNbNyuSt3n+OdBf3QuTJJTlvUExnI
9NEzhm1OD0PzXMXmAEHAja4WRqtew6BxBdZJjHfN02EszlCbVhDQSAaE3ciIWMLdmSxhf5ohy4bI
C5gVTwEJ2AlRYnSt5QVRZ28ggH9IEAwYQmOFNPz/4tE0eMPtTaRpPJjA08JGvvNVDYDrAV+mjqUr
/l2CVkWwyA0skgn75fE5qYIbRr4nRwF6JCgYnBCZfCSnm5SMXQZCECAwhqbASWNH2wIabQx1w37t
0EydhJy8zEUmAfXtYxGMCQpZ4pPTOcko0rDk3rIxCwiajm5pStkAZmAUJ9WyGOsqWomo0gqbLFJC
jVRlCItISyRmq1C4zF24ivRE4u2MBrXAD2dAGJFZILNSWiyLIKakQNe9UpcL/FAsTKmZXkazG7jI
lPe4Q4HssK1sRcin2awGx7CtTzlSY085QFGqfK7tBmwjqNuIUIQHTOA4uAIWruoTj0RSpSsdI8kN
/8ViFznlJjJH6VkgQFJMZfzFRUeyxbZegjHQmbQF11jFjg7mUpp8sJ2a8ShuKlfEVXDRSiipDR14
qs4RMIij+xJLC3RIU9twcT+wTBlUpZFUSOYwMiOgKQ8zahuarCJBKbUkM3P3U7FccoEpSx7GPCob
xfTQFmRN3IhSipatJg8pYlleRhP01JeFg6Un3ZBRA5abvDa1Y5Cq6lpto9MR0HNZ8/uaeWDFHfP0
U47PqSwEpGYO45iHPHA8nzkQGlrknPY54XNH+IbDCYFG9KJuqMOB0HDLOigwBbrQFk1qIokNAaK2
SKUDI35brt4C1w95QC4iaJKnNTC3BMI1g3HZcP9cGFgXdISIbrkOQdzkeuG5LphuufyQ3ZR99wUH
Qu6ehqvcQNThvA30Isomwd3hFjcQNJGEEFqlA0zsoAHfAUImgiCeIMQKFALewYERXOAhDJhZsgDE
Kt5LgloYwDYE2TCHO+zhD4M4xK4gad1EPBEgQDR+GllxJ+b2Ag354r4bOoWFTWzjG+M4xzouQ3tN
wA8bG1jFLB4yFG7QA1HEI8JENoKQEaxkIHxiyQaWsg+Q/L0m88DKQ9ayk5fMCS4nAcwQ3ggUFkyK
J1P5yGhWsxKw/AQkRxkJYjaCkXVQHO/VM81AKGQQ7ixZIQBSzzzgM5X9PL8/2zlTRM7zRhC9DnX/
lGoJkdajDwg9BNFWuTiTnrSgG01nTcfRCJbehHCwjGkdMFoIdfZnqjsdhVG7egmwHjKfOT1oRQ+5
1Qx2dEZsfQRf+3rUuoaHr2P9BF3rWdfC5jUQVt0d+0WUOQ3QNH14ANE7jqc56UuVeXAwSG5b1jmo
2ra3kcMcTUnn2dM2t3yE5Z0dvGfawzk1RE/1vc4eqzuiqPa02diDb/vTnpvqjrSXI596x1He50a4
Pc/xHvOUygFVe7as5n2+5cSRAcNRj8alw530cZw+yal22TqLavPYWz5lA0XH2w1yWd3ze8tRj9oS
PnNLfHs66kv4zmV+boykxxIYF/h3MM6eoT+H/+AZtzi6h1WfUz373sPx1GfXzR0BP70466YOet73
qVOpluQ53wE53K2r5XDC7DD/cnxwECrilN0S6Uv3Zxk+DokHMNRVVvA9eWUJtpGvf+hw26ty9QCN
7/Pw/sbVqUKVrH2ONuWQP1aoMsHPB4RvV2VHVtnUtiz7+Z3wpGAb+HjlbQjYSvHY6RUoTIV6xmuK
CLOqVagagKtUEZ6OAWQb4d0mHutkfhwMOFb4tP3fvueT96TfVNzAU6znr4+gwtI4OW61zwfPD/PW
6drYcvC0p60vArAi6B0JCuk4lp8ckoea29BveVUdHvYQlb2mXkV/ykocVsBqh3JiJTXvo56u+P9e
6ZFe41mH361W7VkE6CkfJlSfePQK7VkHRKGN4SHeqIwbdHRe2YyfcAhHBz7f98VfqTWUPmVe7h3g
OWBEZv3AqgHQAmreqFjCd/iX9p2P+jUHJzzHCuog5MnP1bwNDhzYDMIe+cygOgDS/cQgHp0PeQgL
DMpcE6ZaPr1RoHGczI3DsDjfx6GaREmcE0IesamK5bWe+OSgf3XNDY6BDJYDHpEPDrDH2LwRg0nN
E87K05hK2yBhD2ZK25if/PxX1uDgHNVh1YyNsMghDlqhAzIh84mhP/GfZX0H3IgHGqZNwIHecfAg
DHLiOUhNgU2Hrojh2PwhIPoTIIFNqcmPEbb/IdwQFCBNh/yBITwIINyoWhkqWiZqSqCNVgCNzyCi
og8Go2b54A7KkZ1Vh6iYYSHtIa7xDxSSFv1cohv+4hT6IgDhzz11nHn8Hq7M3ftUDQyWijE+oqcQ
lAaKo/9UjcaByqj4DzUekv34zyB2YeTpntW84zASW/3g4KbxIzFaRKQF5OrRjyL6TwxmY/w8IgAl
HXFMIqWth0VsoibmYCdWpP3IzcaJYs350SBOWjOmIh6FpP+8zTUCUnooo3aoI7EJC7ORAi5a5Cew
yte4A3Z8IjDyIQ/+YOTxJEZU4sGFofq5XTMqITQCoiVAoRth5A/4pCJmhyXgof0gZQQIC2vt/9oZ
guEL1tz3EEeomSH/lMp33EC/HSPOccIc3t1xGBmhWUTX2NGt5ZE+euJUMqQhqscctsNA1mNEqiUO
NKMhwUOgfcdCnt/3EIEtHtJ1zCJFPiNj6mJjXqQfDR956GJe3iQxaqBciuQe0ePfmaTEAWVd5hE8
hE8a3iI6euE49B8XXsKsAMvlydEw6uQO4lwxQh4gpUqrhEpQ6lPzJeHnLSEvyoq3TWOgXZ5FxJnV
FEHXQJom2t5r3ZMAqma4haMX9l/taSUgLkfrZSf/rGY/dc3+TNSs/GZvWhRCFQdb8t5dnpsOjOdm
BgdA9WM4Ss36AKHQxVE+KaPcpWfzKaDnzf8HOhDmepzjHeWgCcLKf2LiEm7irPieRbIe2wBS8G0l
bJbPKfJhYGaocOwReS5nqelmSg6nPi0gJZ6mDnBjapZdRDHfZcXctVnWbAojH3ZWRNkmAMFWOYjf
06QoVw6HWTrjY/LiZZlHLmYHjMaKF0IHi/rlfOzoodkoRInfclbWVeJRjaJerujKVjbfGm3pgdbo
//moqLRWzJUnbKlNtHkmHYaWJuRTgJUWJ2gmZ81KYaJoaNXpaMFoHO3pLiafk/pbaYbKkx5fVUKi
4mFWgFUpkaKeRF7kgmqp+AVnDF7bnZmDjbqNoSIpZpqPZmpmmb5WZZWacuzop8BKmCraOc7/WkfE
A/b1wK5sBDoAmCes2SXET4KRAvbhahTMKpQ1WYNZTazE6n+pGCYomJvxQK/uKrzp3bKeWZPFymCi
GZcZaxCYWRQOqxAAK4Gt2bUG2HdUKw8A66xuq60aWIT16pVtAnf6wLWm67siqxRE65kdma4WWLp6
n961ILsaW792mlf6KxB0Fr8GLJOxYMEibMIqbJoNrJwR7MJCbK9FrHbU6sR+j75abMZq7MbSSsW+
JMeCbMiK7MiSbMmaLBO44Mmq7MqybMu67MvK68PC7MzSbM3a7M0qbMri7M7ybM/67M+irMwC7dAS
bdEarcrq7NEq7dIybdMWbNI6bdRK7dRS/+2bCW3VYm3Wam3U6qwE7IDXAgHYBoHXiq0EmO3X8oDZ
qq3YCkHZrq0OgO3anm0AsK0P1C3coi3czm0OxO3b8u3Xym3Y7q3bsu3dBu7fhm3b9oDh6q3a4i3d
+i3d8u3bxm3aPq7kjm3aRu7dQm7hNm7eJm7nDq4TRK7dYi7g+i3hgu7lli3qHu7klm4SOC7r7u3p
/gDnrqHlPu7rGu7ski3inq7n6m7jUu7wIi7n4u7k3i7otu7xsu7lQu/z2u7iZi7wzq71bu7iym3t
Tm/vXm/wAq/10m7g1m3zTm/wpq70gq/zii/1Gu/Ytm7ysu/yDq/50u/5Iu/2yu/+ou7qXv+U+4Zv
++Zt5VauAOPv/XYv7Bbw+w4w9ZrvAwtw4b5u/f6t/gaw5vqu+kIwA5evAgOw8IouBg9u7YJwBH/w
7hLvBmOuCvsv+m4v+/6u6a6w6GawCE+w/kpw7Oou4aavBa/vD2cZd8Zw5zKv+xKwCbsu966u5wrv
C58v5AIu2qpw8z6wElfvDFdw/wIwFv8wD3vvDdtuB0MvFVPwBZdwF39w+iLx+rJwCn8vF2PxEFsu
BOdwEYev/C7BAmfx58qwC1tx7rYv45qxB6tu9MquHQNxGDMBGSPxBuOwFV/vAtuv/0qyBhuy4hpw
345uAYtxIityEl/y9xYy9kayAk/yII//8e46Lu6Wbymjchc/Mg1PcANbMuwi8imzagDL8SfT8i5P
wRDrMRzzMhJ0cB2rsitHQSWbsSBPsfoegRj3rRHjbTDz7hxf8hZfcR+38TNvMQhzMv6+sDKDMzLf
cRPgcCOPLxrvXR638Dd7cSTHsjVf8O2esw3PcgszMPP6cBKf7Sg/sQw3synbsw4XLDALLh6Trgbv
Mz9zb+m6MzHz8TwbQT3L8h8bsiivsRfvqz2/LzPvMQJD9PyaMh6TNDdnMzbnczmH7kpntDOj9Ehz
dExrb+wyMumCcRl7Mj7rtC47L0JL9DwLMku/9E5rcy3/swsyc1AT70dT9D9T8jAbcEgT/7VTU3VT
Gy8uw+9M6zM5v3RQK7VSv3Ix260Tc7AbjzAyW/VQL/M093Fbwy9ZV/Q7W/QykzVGR/RRtx5Yp7QU
X3NfY3JYL7Ja/3RVK4E3F/ZgIzb/ovQpn/EB7/VP+/JFS/YV+/Qjk208y/Nj+7RjD3Zlx7NeTzXu
MkAL8PNf/3VTp7Vbw3Vqt/NCU/RrLzRlx7by6u1JCzYrzzJcw/RYEzQHnzVvi/Js169wa0T+1rVw
o/Y+s/Zb33NotyBpb210S/d0G+1o1wB1Y3d2azfMWvd2e/d3gzfHdnd4k3d5m3esjfd5q/d6s/cU
jLcTa/Lo3rJAQzZV+/Vmi/BEV+9X2/92URuBAAC4AOgAgA94gBd4EBB4AAS4gSu4gB9Bgjd4gUM4
hPsAhR84ECx4hu9Ahlu4Eiz4hROxX/P2Ejc3Udv1Y9+3UI9zidc356Y3LUtxQ7u05AY3W/fvKtM3
Z4v4Uusyjuu4P39xP+94gnN4DhC5gx+5kSP5kit5kz+4g0d4lCd5g394lEs4g/dAh284lDt5lnO4
loO4Nsd2QO+0RW+zjBtx9tKzbv/4VcdvlUE3DJ8wQ89tNct5JzP2ZG/14TbxVb8yF+c5TmM4k0v5
klf5lCM6of83lCd6lW95l2M5lXu5EHw5pQv4hFc6gfuwYhu1LIcuK7u0HiMvUKu4Xp//MSNH9osb
NA1HryNjMArTOE579UzntkqL9CeLtQdHNWdb9ZEfOqEnupMH+6L7OoNP+aNbuYd/OZczAYFbuKM7
umbLeh5L8JyjbxQ/cTBD9myjdhkf8ZHFefe+8bhL76gfr4/Xsp238xKncgLzeCCvsZ4jAbQzOpYX
e6MbO7P/wK9feZgLu6Ev+xIse6TzgLNz+bCHeGdr9TET90STsEnvsFuD9GGH8LkLObhftwVru7i7
MnzD+i5XMSQ/vJ+PMVf3OU+Lc5BHtsDrO7Ij/BMkOZh3OaS3vMwPvMwjeMAXupOHPCL395DFdzgD
9Ij/vGV/NBsfPSmEe5qrcSc89Hxn/zut0/QbqzaMn3ZfUzFmTwHCD7ylbznOV3i9X7mGN7vO57yX
Y3q873rbjrnWJ/PQD7XRT7wco/oTv/htL3Zpf7y7I70WT/xU8zSsu3GnC/q8F7m/DzvOg/2+iz2y
z7zitzyVR3vYLzo77/rGr72J67etC74tc/w64Hm5J30uK7zD13U3v/mNX7zHqzglC73eNzaQD7R8
e73jd73kH/vtJ7u/F7zOEzymV/qk277ZDzraH37C6/j95jCL2zcQ1zPrQ79gOzM0Y3us80DK5PXP
l/WfZ7b2c7zGu73mQzVhb37z737aOz7lz7zw9/7Zpz/7L/76oz+x+z6z43zQ3/Pvrv/6IWcuCEiB
KAajiZ7pWq5o2b7uHM9unZLuojC5BAy2hMIbEfgr2mRLpg3XjD6lqhcxCr1ZjzOB9ytIgcdNL2oM
Npm76HWg7Waf4ba2mE51wcPLbN8Jc+RXRQNoIjiY2CdoxPXXhMPjk0dZaXmJmam5ydnp+QkaKjpK
Wmp6KiWJusra6voKGys7S1tLqmqbq7vL2+v7CxwcgCtcbHyMnKy8fNvD/AwdLT1NDUssFZQzckW4
nX2YOeQ4pEU5uKXdXYW4sqeG9sZnmpYXd2f/jh9v1x6mL/evnrx3ZQYKzBSHXz55awLe+0JwIUQ2
bszAizenosF9F+vwucbuD5SRLMD/lTz0TV0NcY7QKVFXbh3KloXu9ItoMyM9jmQeWpyYZg/DhhDJ
7Izy0+jGORwxSjyqBw9TnDp7OqWicapWOVcPOrWHjyhVnku3LiGK55pJlkp0xEzXtlwMGHJT4ljp
JO8UkyrubuFmVuzNsQH1afyJMyvGpAMZF6QatOziogYRI62M2ezXjQ4HXwXrz45gShdBR306mHFk
rJkjqu1bci4jlYQCjYMbO503wHzvzja09vc5skA5U04tNWdT5YoRH3V8NnQ/ywCP2+xM3PTYzVEV
ek7Y0ePTiVw/h5862vzjy6ddOzs5FzjfbuTWysUtf7hu/TSQ6O0fEmsPBcYHduNp/6feZFYRt153
UPm04GSV/KNYTgY2aBpoFU7YmGTRVaiaTgS6o9UaPCiwwF9x9aZbbfDN15tdetFlzm/GiNahVRce
ViB59MAD3WZhCUUQdaetdqBkQg2FVo7nCdTkktwtx1prnCSFXEQXTtcjCgygWFMS2iDC30y8vbUX
mVmsRCYLjKhp5kvZkdeeFCQOSKWWxRUZWnN0kiZdYX1KV+eVe0bHpXcLbSced1LaOaiihuqJyY/y
fJkimpeMdCaMe0ES5iOe+IUNopBeImiTN4nF6qCJ/VmVn12tap1nBSnUaoOodgmejl3OasmWDvZE
omBD4srrpWBqGpJ+pLa4WzZ4Uf8x3LOQ2OhpgIUyumujjqkqYj6L9rpUhkNNGSuhtgLLFbm6cqsc
lQjulF6V65qqWYk+GpdluAFgGic3pDqrBZyfenqwigJTy/BJXsWb6JJPcrloow5SVK6VTNVLa5JG
4luex792S5iHHD8G3sPwOjTkvcoBTO1s2iqsCZs0/RfzzdGm9N/MEM/JypYsK1mWpNd5+HPI77p8
mdGFOo1echlNDfSwD+ar2Z3lwVxN115/DXbY0XAtdtlmn4122qSQrXbbbr8Nd9psx0133XbfLczc
eO/Nd99+r71stAjjDG3CMOU2U+GFv6mwf40j7NuKKs7Y6X4z7uf44SesCRPPirj/ia3DNeqs+Hyc
s1R6zz6nrjl8L30uKi1cDxwmYM6GHheNMiVOuIvZJuybpprzZq3D9eWl+/HbyGAbXc/WZzuoB7Ml
p/Cmx05C7tLzPnj38Qn+O4vGQz55964wMEn4JJFfquj2bS4+bPG/Ja31zb+ouB/KF5+E49+4Jb/d
yQ+A9nkeOuRTsOltr2Dr856Y4pO9hcVPf4f7nuXGFxy78AyBvTtf+sCnuwu67wm4K+AET1iI462O
gOIAh/8kSD/QbRCDLoJefkyIGwP+bobzQ94CrfAD0Z0OgQSMCfU+1UDahG9362tgEmeBvhh2Dmdl
cuBu1pG55KkOiE8UYRd9WJfM/1kieuLTYhnr17/OZTFOWwxii2A3xvwxgRxFQN0Ns8UmIRqxEf6D
0f9qFyoopo9xU4ScGH+InyIisYMAstG0mnczC6LEep3Aix3L6ELLVbGQcVReD3f2OgFS0Ydm9IYA
N5lJPy4OEM1inxpRGYooNoyGrAtY9WgEwFZ+EpSwpKQMK3et1dkSjnuEjQUVyUs/ilFNdOwZI6fg
yVI185Ss3CAzmXc5Z+5SeNFsXStkqT7QUa6XNXGe9FSYhy8ukHQj3FnsKkFMDJrzevwJYQedGM5G
hvJ9v/zjNNGJQsMxEVo6FCU/uWezXIAzme7E4ori2chUMtSUVCwhIlf5TCWiie1TLYGoG+FHn1cK
jAvxtKQv04Q4ac7RoW9c4ztDGghm7ZOhtwnYQWGxUP7V0p7tVKn5AvnTzVHwpZIkKvCAyroqIhOk
PX1pLefYpvYJFKlMpeo903lRQDbVmzz1YP+qt1VvDhOrY3VqgLLIUeKdaYXA9B0fXyec0G01rWBN
Klk54VFf5tV89cyqEeXKSHKCYqF/K6xhD4vYJRA2sYxtrGPrttjHSnaylPVaZCuL2cxqNm8f3Kxn
PwtaQYZ2tKQtbSnQh9rUqna1rG2ta18L29jKdra0ra1tb4vb3Op2t7ztrW9/C9zgCne4xP1tCAAA
Ow==

--=_NamoWEC-pmbgr7ernt--



From nobody Mon Jul 21 20:34:09 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB001A03D2 for ; Mon, 21 Jul 2014 20:34:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9v3iHEEWzwB3 for ; Mon, 21 Jul 2014 20:34:06 -0700 (PDT)
Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E7031A03BA for ; Mon, 21 Jul 2014 20:34:05 -0700 (PDT)
Received: by mail-we0-f181.google.com with SMTP id k48so7379406wev.12 for ; Mon, 21 Jul 2014 20:34:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to:cc:content-type;  bh=e5B5GNw6EsadRWFV1ZyOz5oTvQDwGBXrZos6LWhG/Gg=; b=pm/JTYmlRzhldKYF2wNsKTRZSSWXUofD6uID+lChn1hPmHeQ4AQKtzqtI3og6FsW6m cl+myRjK4qN+SS0B2C5BtmVICni57qWfB+HgKudKf6Hv9OYacipPfk1LK1k68p6jMy+Y f2sErsvSh6kG5BTMq31jos2XHDDs0oIewXKWGYR/pkLAeoUF/XA4ZkfPrPCVkQNG5rZV K225rb8tyZNDs8V4oN+9kBjsVO+/M3rQRIaCQkMytMIJrGHbEfS0STbf9UBVglVQ0nvj q3vta+hds6xDO9s4vEKxDbRnH8L4sPR/wr1LMRYy8JppIgk7D3p6Kaicwzg7t+Pc3s0F pc0w==
X-Received: by 10.194.123.105 with SMTP id lz9mr29630061wjb.122.1406000044721;  Mon, 21 Jul 2014 20:34:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.217.122.65 with HTTP; Mon, 21 Jul 2014 20:33:44 -0700 (PDT)
From: Bernard Aboba 
Date: Mon, 21 Jul 2014 23:33:44 -0400
Message-ID: 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=089e01177699384b2904febfe5e2
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/k5cGySZk1zDXf9HgGni7s1VV4rc
Subject: [rtcweb] security-arch: RTP and RTCP Key Management (mux and non-mux)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 22 Jul 2014 03:34:08 -0000

--089e01177699384b2904febfe5e2
Content-Type: text/plain; charset=UTF-8

I have had some questions about DTLS/SRTP key derivation in the multiplexed
and non-multiplexed cases.  The questions arise from the following sentence
in RFC 5764 Section 3:

   There MUST be a separate DTLS-SRTP session for each
   distinct pair of source and destination ports used by a media session
   (though the sessions can share a single DTLS session and hence
   amortize the initial public key handshake!).

[BA] My question is whether WebRTC permits DTLS-SRTP sessions to share a
single DTLS session or not.

The description in security-arch Section 4.3 seems to indicate that where
symmetric RTP and RTCP is not multiplexed it is expected to have two
separate DTLS sessions, and for RTP/RTCP multiplexed there will be a single
DTLS session:

   Specifically, Alice and Bob perform a DTLS
   handshake on every channel which has been established by ICE.  The
   total number of channels depends on the amount of muxing; in the most
   likely case we are using both RTP/RTCP mux and muxing multiple media
   streams on the same channel, in which case there is only one DTLS
   handshake.  Once the DTLS handshake has completed, the keys are
   exported [RFC5705 ] and used to key
SRTP for the media channels.

[BA] However, I didn't see any normative language indicating that this is
the only permitted configuration (although my understanding is that every
existing implementations operates this way).

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


I have had some questions about=C2=A0DTLS/SRTP key de=
rivation=C2=A0in the multiplexed and non-multiplexed cases.=C2=A0 The quest=
ions arise from the following sentence in RFC 5764 Section 3: =C2=A0
<=
div>


=C2=A0=C2=A0 There MUST be a separate DTLS-SRTP session for each
=C2=A0=
=C2=A0 distinct pair of source and destination ports used by a media sessio=
n
=C2=A0=C2=A0 (though the sessions can share a single DTLS session and =
hence
=C2=A0=C2=A0 amortize the initial public key handshake!).




[BA] My question is whether WebRTC permits DTLS-SRTP se=
ssions to share a single DTLS session or not. =C2=A0

The description in security-arch Section 4.3 seems to indicate that wher=
e symmetric RTP and RTCP is not multiplexed it is expected to have two sepa=
rate DTLS sessions, and for RTP/RTCP multiplexed there will be a single DTL=
S session: 



=C2=A0=C2=A0 Specifically, Alice and Bob perform a DTLS=

=C2=A0=C2=A0 handshake on every channel which has been established by I=
CE.=C2=A0 The
=C2=A0=C2=A0 total number of channels depends on the amoun=
t of muxing; in the most
=C2=A0=C2=A0 likely case we are using both RTP/=
RTCP mux and muxing multiple media


=C2=A0=C2=A0 streams on the same channel, in which case there is only one D=
TLS
=C2=A0=C2=A0 handshake.=C2=A0 Once the DTLS handshake has completed,=
 the keys are
=C2=A0=C2=A0 exported [RFC5705] and us=
ed to key SRTP for the media channels.




[BA] However, I didn't see any normative language i=
ndicating that this is the only permitted configuration (although my unders=
tanding is that every existing implementations operates this way).=C2=A0 




--089e01177699384b2904febfe5e2--


From nobody Tue Jul 22 08:51:01 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B861B285A for ; Tue, 22 Jul 2014 08:50:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LI3htjkPSqND for ; Tue, 22 Jul 2014 08:50:58 -0700 (PDT)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D2721A036E for ; Tue, 22 Jul 2014 08:50:58 -0700 (PDT)
Received: by mail-wi0-f172.google.com with SMTP id n3so6241565wiv.5 for ; Tue, 22 Jul 2014 08:50:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tQ6FV0osVz8x9eR/4bH6BMDatV/oMJcyQ1laWRcDrCY=; b=lciAOWJil2XaIrf8B8XYG5DaebqZPCZ6qbNr7LsRpSGItAs/43tt31SJ/d3yJx2jNq dW9siHRasMOXCFNkoMtFgWy4Gbz3RcBpJv3kqkp0RXJiP/QF93DUqjADO6alIoulItIx CdIOXd7KXQtm7fobWNoL/ccL+tbDaUtx3/MbudQLVbgLu4zN0fhxADUCHoPYBI5K6ZSF wZvWY/nvLi40C7gMGrYrvKBt8ONXXy1UBDIyUu+OBl2wm87f+t1ZCDwzC06o09DVd+l/ gQ0xPiXfaURkyhe3CwLlEq9R23lwLf6VahoNokB0/82lAEl++dzHhu3oI1MrZ6Qmndpe RqtQ==
MIME-Version: 1.0
X-Received: by 10.194.185.238 with SMTP id ff14mr35704452wjc.9.1406044256975;  Tue, 22 Jul 2014 08:50:56 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Tue, 22 Jul 2014 08:50:56 -0700 (PDT)
In-Reply-To: 
References: 
Date: Tue, 22 Jul 2014 08:50:56 -0700
Message-ID: 
From: Martin Thomson 
To: Michael Procter 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uOnyoWjnrJVwfPhQGhtDcqoyqSc
Cc: "" 
Subject: Re: [rtcweb] security-arch: 5.6.5.3.3: Managing User Login
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 22 Jul 2014 15:50:59 -0000

On 21 July 2014 16:21, Michael Procter  wrote:
>    Once any user
>    interactions are complete, the IFRAME MUST send a postMessage
>    [WebMessaging] to its containing window indicating completion, as
>    described in section 8.2.1 of [webrtc-api].

Sounds like a good idea to me.


From nobody Tue Jul 22 08:59:51 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8539D1A00A8 for ; Tue, 22 Jul 2014 08:59:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtPGcXQ9ZaHK for ; Tue, 22 Jul 2014 08:59:46 -0700 (PDT)
Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 917A81A0022 for ; Tue, 22 Jul 2014 08:59:46 -0700 (PDT)
Received: by mail-wg0-f42.google.com with SMTP id l18so8033310wgh.13 for ; Tue, 22 Jul 2014 08:59:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=v01b95pmqxegNM25dMO480VGNEMhPSSkIIQDns7L31A=; b=0LH1vWSVB0mHbonbZqYBH0KlYZMbxmT7p3MQL4lDpIp0BEvMbSs/U0gDT/f6jcXxvX iJuWs1Rncs5GK1Dt7zwVDArjst+D4p+c1PUpsh0g8Enn6asKJGL2tvbC81z9yMDoWaiM YbY0H9kur3fzLkP4QNPaxrmgZzWM7pXV+Svj1HSWvI3lKxgmy6OXxuDzX+KNXK+UOoHr Rf/c/cv5O7gouAZYQgnzwue1YRTO5nYLBF1EWPISSTVl+ieRQNcqTnaKkDD+0gamGIB/ ELX0n/O4Sy9FAVBfc4NXdo/gJlZZXiMw1kNYQQQE1rVjkrI6Aj5vqfqbnzlVdIQAB5ZG qVog==
MIME-Version: 1.0
X-Received: by 10.180.92.38 with SMTP id cj6mr16173129wib.64.1406044782956; Tue, 22 Jul 2014 08:59:42 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Tue, 22 Jul 2014 08:59:42 -0700 (PDT)
In-Reply-To: 
References: 
Date: Tue, 22 Jul 2014 08:59:42 -0700
Message-ID: 
From: Martin Thomson 
To: Bernard Aboba 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6dV71Q6--PFS-j_7f1kuYygb_qc
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] security-arch: RTP and RTCP Key Management (mux and non-mux)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 22 Jul 2014 15:59:48 -0000

On 21 July 2014 20:33, Bernard Aboba  wrote:
> [BA] My question is whether WebRTC permits DTLS-SRTP sessions to share a
> single DTLS session or not.

Yeah, keying multiple SRTP sessions from a single DTLS session could
(would) lead to key reuse if the different sessions use the same SSRC
values.  That's why 5764 says what it says.

Writing this down makes sense, though we need only lean on what 5764 says.


From nobody Tue Jul 22 09:02:03 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7AC1A0039 for ; Tue, 22 Jul 2014 09:02:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-s0RZF9QiOU for ; Tue, 22 Jul 2014 09:01:57 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05F8F1A000A for ; Tue, 22 Jul 2014 09:01:56 -0700 (PDT)
Received: by mail-wi0-f169.google.com with SMTP id n3so6145781wiv.2 for ; Tue, 22 Jul 2014 09:01:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dzC2iOA+WxiDAJl3p5ije6587z8OBoj+QfFlGmn2orA=; b=DC7GbGPMvFxqsS9aJakqQGaFgLGWGawIigMov6kg7m2//5CFx5T2zfqwdSjHlhhaVk 4kusux1aPux3Z1l67TvIoOziyRP7T+XXcLtBZLumbQZlmg3ot23aoFbRW6Npcm0ygQUm C+Hq91LCmTIo04nGWVWVD3++3vXhWBqrfHSuMWV5ET3/zwnu3IMuP2RsGiwlg3vuCpAl 7ulbluWOao6tE9kZe+dLbi2v9OC3IMZKtRPhiDBKeMtg93sba0wvEIR/KjkWJ3kH+ZKH Pp8SlyAA5Idyw54DIIGglJfDgeV9nuzXRVFrvpiYgN0Ob02fY2lTkPdm6alS4dVi09Sn grLQ==
MIME-Version: 1.0
X-Received: by 10.180.92.38 with SMTP id cj6mr16192362wib.64.1406044913918; Tue, 22 Jul 2014 09:01:53 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Tue, 22 Jul 2014 09:01:53 -0700 (PDT)
In-Reply-To: 
References: 
Date: Tue, 22 Jul 2014 09:01:53 -0700
Message-ID: 
From: Martin Thomson 
To: Michael Procter 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VUmyYRqLjZCivTcM0fjCE9C5B8Y
Cc: "" 
Subject: Re: [rtcweb] security-arch: 6.4.1 PeerConnection Origin Check
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 22 Jul 2014 16:02:02 -0000

On 21 July 2014 16:51, Michael Procter  wrote:
>
>    Fundamentally, the IdP proxy is just a piece of JS loaded by
>    the browser, so nothing stops a Web attacker from creating their
>    own IFRAME, loading the IdP proxy JS, and requesting a
>    signature.  In order to prevent this attack, we require that communication
>    with the IdP proxy be via a MessageChannel in a way that cannot
>    be emulated by hostile JS.  This is discussed in section 8.2.1 of
> [webrtc-api].


I'm having a hard time finding a fault with your suggestions Michael.
This is great, thanks.


From nobody Tue Jul 22 10:19:00 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768681B29AD for ; Tue, 22 Jul 2014 10:18:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8Xj8mW1FMpw for ; Tue, 22 Jul 2014 10:18:57 -0700 (PDT)
Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E03381A0180 for ; Tue, 22 Jul 2014 10:18:56 -0700 (PDT)
Received: by mail-we0-f177.google.com with SMTP id w62so9524346wes.22 for ; Tue, 22 Jul 2014 10:18:55 -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:content-type; bh=awSfcUHbqFg+RotIWqRF5bpg8mRrizeRydK8I6Ak06E=; b=cbW4ej95gp2ncbP0rgdHd2NNhCSLuASow7W8TUKJoZcnuBou438WF0wPe3p5xUewo3 WV4voDBV6waLBHfIfmbG332+heQdbAi+Sx9I59ImqvJGYY/ncP+0s9GVONkTwi38VjC4 kLK5CY/bPqhDL522cdYOjxmSBeMot/GCp5p79fO45A1pJ497ZcjNAr96Ey/kxaOqN58g 1rE3yJ1ff2qPZuGCUMJeAPNZtGqsY8gReSVDaRXQBjN/e1kuBQCMBHqlGR8Tr8QhwJBB WL4sCRICxE8vEF9XTq9g0ctFyM2RnJtYvqN59QukH+H6bVhO2EQcumQIvWQs1WbUcApy ZUfQ==
X-Received: by 10.180.93.8 with SMTP id cq8mr16538169wib.17.1406049535454; Tue, 22 Jul 2014 10:18:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.217.122.65 with HTTP; Tue, 22 Jul 2014 10:18:35 -0700 (PDT)
In-Reply-To: 
References:  
From: Bernard Aboba 
Date: Tue, 22 Jul 2014 13:18:35 -0400
Message-ID: 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=f46d043892b118f4e704fecb6b18
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NArWM1YdyBqrNnFivu1cBO6NrpQ
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] security-arch: RTP and RTCP Key Management (mux and non-mux)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 22 Jul 2014 17:18:58 -0000

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

Martin said:

"Yeah, keying multiple SRTP sessions from a single DTLS session could
(would) lead to key reuse if the different sessions use the same SSRC
values.  That's why 5764 says what it says."

[BA] Yes - but the question was about deriving SRTCP and SRTP keys from a
single DTLS session when RTP and RTCP are not multiplexed.   That wouldn't
result in key reuse.


On Tue, Jul 22, 2014 at 11:59 AM, Martin Thomson 
wrote:

> On 21 July 2014 20:33, Bernard Aboba  wrote:
> > [BA] My question is whether WebRTC permits DTLS-SRTP sessions to share a
> > single DTLS session or not.
>
> Yeah, keying multiple SRTP sessions from a single DTLS session could
> (would) lead to key reuse if the different sessions use the same SSRC
> values.  That's why 5764 says what it says.
>
> Writing this down makes sense, though we need only lean on what 5764 says.
>

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


Martin said:=C2=A0

"Yeah, keying multiple SRTP se=
ssions from a single DTLS session could
(would) lead to key reuse if the diffe=
rent sessions use the same SSRC



values. =
=C2=A0That's why 5764 says what it says."

[BA] Yes - but the question was about deriving SRTCP and SRTP keys =
from a single DTLS session when RTP and RTCP are not multiplexed. =C2=A0 Th=
at wouldn't result in key reuse.





On Tue,=
 Jul 22, 2014 at 11:59 AM, Martin Thomson <martin.thomson@gmail.com=
> wrote:



On 21 July 2014 20:33, Berna=
rd Aboba <bernard.aboba@gmail=
.com> wrote:



> [BA] My question is whether WebRTC permits DTLS-SRTP sessions to share=
 a

> single DTLS session or not.




Yeah, keying multiple SRTP sessions from a single DTLS session could<=
br>
(would) lead to key reuse if the different sessions use the same SSRC

values. =C2=A0That's why 5764 says what it says.



Writing this down makes sense, though we need only lean on what 5764 says.<=
br>




--f46d043892b118f4e704fecb6b18--


From nobody Tue Jul 22 15:57:39 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15491A07A1 for ; Tue, 22 Jul 2014 15:57:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.129
X-Spam-Level: 
X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77] autolearn=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 Y-6wWckYysj0 for ; Tue, 22 Jul 2014 15:57:37 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDED81A0290 for ; Tue, 22 Jul 2014 15:57:36 -0700 (PDT)
Received: from [207.236.147.203] (port=54058 helo=[10.255.253.157]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1X9j01-00006d-1f; Tue, 22 Jul 2014 23:57:34 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_E6400AD8-8B00-4D7E-98CA-7C71999EE127"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Colin Perkins 
In-Reply-To: 
Date: Tue, 22 Jul 2014 18:57:26 -0400
Message-Id: <63E133BB-328F-4313-8760-597B11B45650@csperkins.org>
References: <20140528112153.7351.96214.idtracker@ietfa.amsl.com> <5385C8AB.8080606@ericsson.com> 
To: Justin Uberti 
X-Mailer: Apple Mail (2.1878.6)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold =  On = 
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/waDJGxGruab26zUJXHpFz7JwF0w
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-15.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 22 Jul 2014 22:57:38 -0000

--Apple-Mail=_E6400AD8-8B00-4D7E-98CA-7C71999EE127
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

The rtp-usage draft doesn=92t mandate any payload formats, and instead =
defers to the rtcweb-audio draft. If RFC 3389 is to be mandated, it =
should probably be done in rtcweb-audio.

Colin


On 16 Jul 2014, at 23:20, Justin Uberti  wrote:

> One thing that has come up while discussing JSEP is the need to =
specify handling of DTX in the RTP usage document. JSEP allows =
applications to ask for DTX, so this needs to be supported in all =
implementations to give deterministic behavior.
>=20
> While Opus has the ability to support DTX internally, we also need to =
make sure this works with other codecs, including G.711. As a result, I =
think the RTP usage draft needs to specify RFC 3389 support as =
mandatory-to-implement, so that applications can deterministically =
enable DTX in all cases.
>=20
>=20
> On Wed, May 28, 2014 at 7:29 AM, Magnus Westerlund =
 wrote:
> WG,
>=20
> This version contains some changes as result of last weeks discussion.
> Especially you who wasn't there should review this to see that you =
agree
> with the changes proposed.
>=20
> The changes are:
>=20
> - Multi-stream optimization are now a MAY support, MUST signal to use.
>=20
> - The T_rr_interval =3D 4 is now explained in
> draft-ietf-avtcore-rtp-multi-stream, so a reference has been added =
here.
>=20
> - Signalling of extensions has been clarified to be a MUST
>=20
> - The DoS potential from RTCP configuration that Martin Thomson =
noticed
> is now discussed and the general consideration that an WebRTC
> implementation needs safe guards among this is present. WG needs to
> consider if it needs more or are sufficient.
>=20
> Cheers
>=20
> Magnus
>=20
> On 2014-05-28 13:21, internet-drafts@ietf.org wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> >  This draft is a work item of the Real-Time Communication in =
WEB-browsers Working Group of the IETF.
> >
> >         Title           : Web Real-Time Communication (WebRTC): =
Media Transport and Use of RTP
> >         Authors         : Colin Perkins
> >                           Magnus Westerlund
> >                           Joerg Ott
> >       Filename        : draft-ietf-rtcweb-rtp-usage-15.txt
> >       Pages           : 44
> >       Date            : 2014-05-28
> >
> > Abstract:
> >    The Web Real-Time Communication (WebRTC) framework provides =
support
> >    for direct interactive rich communication using audio, video, =
text,
> >    collaboration, games, etc. between two peers' web-browsers.  This
> >    memo describes the media transport aspects of the WebRTC =
framework.
> >    It specifies how the Real-time Transport Protocol (RTP) is used =
in
> >    the WebRTC context, and gives requirements for which RTP =
features,
> >    profiles, and extensions need to be supported.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-15
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-15
> >
> >
> > Please note that it may take a couple of minutes from the time of =
submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
>=20
>=20
> --
>=20
> Magnus Westerlund
>=20
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> F=E4r=F6gatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb



--=20
Colin Perkins
http://csperkins.org/




--Apple-Mail=_E6400AD8-8B00-4D7E-98CA-7C71999EE127
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

The =
rtp-usage draft doesn=92t mandate any payload formats, and instead =
defers to the rtcweb-audio =
draft. If RFC 3389 is to be mandated, it should probably be done in =
rtcweb-audio.

Colin


On 16 Jul 2014, at 23:20, Justin Uberti <juberti@google.com> =
wrote:

One thing that has come up while =
discussing JSEP is the need to specify handling of DTX in the RTP usage =
document. JSEP allows applications to ask for DTX, so this needs to be =
supported in all implementations to give deterministic behavior.



While Opus has the ability to support DTX internally, we =
also need to make sure this works with other codecs, including G.711. As =
a result, I think the RTP usage draft needs to specify RFC 3389 support =
as mandatory-to-implement, so that applications can deterministically =
enable DTX in all cases.





On =
Wed, May 28, 2014 at 7:29 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> =
wrote:



WG,



This version contains some changes as result of last weeks =
discussion.

Especially you who wasn't there should review this to see that you =
agree

with the changes proposed.



The changes are:



- Multi-stream optimization are now a MAY support, MUST signal to =
use.



- The T_rr_interval =3D 4 is now explained in

draft-ietf-avtcore-rtp-multi-stream, so a reference has been added =
here.



- Signalling of extensions has been clarified to be a MUST



- The DoS potential from RTCP configuration that Martin Thomson =
noticed

is now discussed and the general consideration that an WebRTC

implementation needs safe guards among this is present. WG needs to

consider if it needs more or are sufficient.



Cheers



Magnus




On 2014-05-28 13:21, internet-drafts@ietf.org =
wrote:

>

> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.

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

>

>         Title         =
  : Web Real-Time Communication (WebRTC): Media Transport and Use =
of RTP

>         Authors         : =
Colin Perkins

>                   =
        Magnus Westerlund

>                   =
        Joerg Ott

>       Filename        : =
draft-ietf-rtcweb-rtp-usage-15.txt

>       Pages           : =
44

>       Date           =
 : 2014-05-28

>

> Abstract:

>    The Web Real-Time Communication (WebRTC) framework =
provides support

>    for direct interactive rich communication using audio, =
video, text,

>    collaboration, games, etc. between two peers' =
web-browsers.  This

>    memo describes the media transport aspects of the =
WebRTC framework.

>    It specifies how the Real-time Transport Protocol =
(RTP) is used in

>    the WebRTC context, and gives requirements for which =
RTP features,

>    profiles, and extensions need to be supported.

>

>

> The IETF datatracker status page for this draft is:

> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-u=
sage/

>

> There's also a htmlized version available at:

> http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-1=
5

>

> A diff from the previous version is available at:

> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp=
-usage-15

>

>

> Please note that it may take a couple of minutes from the time of =
submission

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

>

> Internet-Drafts are also available by anonymous FTP at:

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

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

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

>

>






--



Magnus Westerlund



=
----------------------------------------------------------------------
=

Services, Media and Network features, Ericsson Research EAB/TXM

=
----------------------------------------------------------------------
=

Ericsson AB                 | =
Phone  +46 10 7148287

F=E4r=F6gatan 6                 =
| Mobile +46 =
73 0949079

SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com

=
----------------------------------------------------------------------
=




_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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




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





-- 
Colin Perkins







=

--Apple-Mail=_E6400AD8-8B00-4D7E-98CA-7C71999EE127--


From nobody Tue Jul 22 16:13:24 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6729C1A010E for ; Tue, 22 Jul 2014 16:13:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.13
X-Spam-Level: 
X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77] autolearn=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 ZnxgsDqYZ9kF for ; Tue, 22 Jul 2014 16:13:22 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 736111A0004 for ; Tue, 22 Jul 2014 16:13:22 -0700 (PDT)
Received: from [207.236.147.203] (port=54563 helo=[10.255.253.157]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1X9jFH-0001zS-Uu; Wed, 23 Jul 2014 00:13:20 +0100
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Colin Perkins 
In-Reply-To: <53C88EC8.1010605@alum.mit.edu>
Date: Tue, 22 Jul 2014 19:13:14 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <9B99EBA9-AD5E-42A7-86ED-ED6CA4AE2FB9@csperkins.org>
References: <53C88EC8.1010605@alum.mit.edu>
To: Paul Kyzivat 
X-Mailer: Apple Mail (2.1878.6)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold =  On = 
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jp5tz0hKA7PyoqWgq14_2mSaVLI
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Questions on draft-ietf-rtcweb-rtp-usage-15
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 22 Jul 2014 23:13:23 -0000

On 17 Jul 2014, at 23:04, Paul Kyzivat  wrote:
> I have a couple of questions after reading this draft:
>=20
> Section 4.9 says:
>=20
>   Taking the discussion in Section 11 into account, a WebRTC end-point
>   MUST NOT use more than one RTCP CNAME in the RTP sessions belonging
>   to single RTCPeerConnection (that is, an RTCPeerConnection forms a
>   synchronisation context).
>=20
> and then Section 11 says:
>=20
>   ... This is motivating the
>   strong recommendation in Section 4.9 to only use a single CNAME.
>=20
>      The requirement on using the same CNAME for all SSRCs that
>      originate from the same end-point, does not require a middlebox
>      that forwards traffic from multiple end-points to only use a
>      single CNAME.
>=20
> So one is MUST strength, and the other seems to be SHOULD strength. =
Which is it?
>=20
> And isn't this "middlebox" a WebRTC end-point? If so then that is =
another conflict.

End Point is used in the sense of =
draft-ietf-avtext-rtp-grouping-taxonomy-02, and I assumed that excluded =
middleboxes. This is maybe something that should be clarified in the =
taxonomy.

> Is it really that WebRTC *browsers* must use one CNAME, while other =
WebRTC *devices* have more freedom? That seems to make sense since an =
RTCPeerConnection is only a browser thing.

I think that=92s essentially what=92s meant. Middleboxes can send data =
with multiple CNAMEs (and have to, in many cases).=20

Browsers, and other end systems, ought to use only a single CNAME. =
Whether that=92s SHOULD or MUST use only a single CNAME I don=92t have a =
strong opinion on.

--=20
Colin Perkins
http://csperkins.org/




From nobody Tue Jul 22 16:56:43 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325581A0AAF for ; Tue, 22 Jul 2014 16:56:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlPLjKBR2NP5 for ; Tue, 22 Jul 2014 16:56:39 -0700 (PDT)
Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE8241A0944 for ; Tue, 22 Jul 2014 16:56:38 -0700 (PDT)
Received: from ppp118-209-11-99.lns20.mel4.internode.on.net ([118.209.11.99]:52907 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X9juu-0006at-5z for rtcweb@ietf.org; Wed, 23 Jul 2014 09:56:20 +1000
Message-ID: <53CEFA2C.8040407@nteczone.com>
Date: Wed, 23 Jul 2014 09:56:28 +1000
From: Christian Groves 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EJS3PwPMHx527DTqTZuy8QRIB8E
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-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, 22 Jul 2014 23:56:42 -0000

The browser would delay the establishment of media that are part of the 
"a=group:clue" group until a CLUE exchange has taken place and those 
media have been selected via a CLUE configure message. I'm not sure if 
that fits your criteria for acting differently?

Christian

On 21/07/2014 6:34 PM, Kevin Dempsey wrote:
> Would the browser be expected to act differently with "a=group:clue"? 
> If not, then that is really part of the signalling and not part of the 
> createXxx/setXxxDescription interface.
>
> The SDP passed to setXxxDescription and the SDP sent as part of the 
> signalling (if SDP is used) do not need to be identical.
>
>
> On 21 July 2014 03:35, Kiran Kumar Guduru  > wrote:
>
>     It seems there is a small mis-understanding here. I agree there is
>     a need for parsing and editing SDP by JS application for now.
>
>     I am not saying that constraints will do everything.
>
>     My intention is, to find the possibilities to extend the API of
>     existing RTCPeerConnection and proposed RTCRTPSender/Receiver to
>     add the attributes required by JS application.
>
>     For now, I proposed solution for one such kind of problem, i.e.,
>     prioritizing codecs.
>
>     setSdPAttribute (key, value) is just an example on top of my head,
>     which might solve this. But we can really figure out this after
>     getting the proposed API (RTCRTPSender/Receiver ) in draft.
>
>     Regards,
>
>     Kiran
>
>     ------- *Original Message* -------
>
>     *Sender* : Paul Kyzivat     >
>
>     *Date* : Jul 19, 2014 22:35 (GMT+09:00)
>
>     *Title* : Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
>
>     Kiran,
>
>
>     My need won't be satisfied by plausible constraints.
>     For instance, to interwork with CLUE it will be necessary to add an
>     "a=group:clue" and include in it those m-lines that are to be "clue
>     controlled". And that is needed in both offer and answer processing.
>
>     Thanks,
>     Paul
>
>
>     On 7/18/14 10:41 PM, Kiran Kumar Guduru wrote:
>     > Dear Paul,
>     >
>     > My comment is only regarding the comments on section 6 of the
>     JSEP draft.
>     >
>     > The sdp mangling described in section 6 may result in various error
>     > scenarios.
>     >
>     > In that section, it is described like most of the parameters can be
>     > modified thorugh constraints.
>     >
>     > The required modification, I found, which cannot not be done by the
>     > constraints is "Remove or reorder of codecs (m=)"
>     >
>     > In order to avoid the SDP mangling at Java Script application
>     level, I
>     > submitted a draft for changing the codec preferences
>     > http://tools.ietf.org/html/draft-guduru-rtcweb-codec-preferences-01.
>     > (Please review it).
>     >
>     > If this proposal is acceptable to the group, I hope we can remove
>     > section 6 from JSEP draft.
>     >
>     > (Expecting that we can find alternatives for adding extra attributes
>     > like CLUE as identified by you, for example by extending the
>     > proposed RTCRTPSender/Receiver by adding a generic
>     setSdPAttribute (key,
>     > value) method).
>     >
>     > Thanks,
>     >
>     > Kiran.
>     >
>     >
>     >
>     > -------Original Message--------
>     > Sent: Paul Kyzivat
>     > Date: Fri, 18 Jul 2014 14:32:24 -0400
>     > Subject: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
>     >
>     > I just did my first thorough read-through of JSEP in quite some
>     time. I
>     > came away with a number of concerns:
>     >
>     > Section 1.1:
>     >
>     > When describing offers, modification by the application is
>     mentioned:
>     >
>     >      JSEP's handling of session descriptions is simple and
>     >      straightforward.  Whenever an offer/answer exchange is
>     needed, the
>     >      initiating side creates an offer by calling a createOffer()
>     API.  The
>     >      application *optionally modifies that offer*, and then uses
>     it to set
>     >      up its local config via the setLocalDescription() API.
>     >
>     > but when describing answers it is not:
>     >
>     >      When the call is accepted, the callee uses the
>     createAnswer() API to
>     >      generate an appropriate answer, applies it using
>     >      setLocalDescription(), and sends the answer back to the
>     initiator
>     >      over the signaling channel.  When the offerer gets that
>     answer, it
>     >      installs it using setRemoteDescription(), and initial setup is
>     >      complete.
>     >
>     > And Section 6 only talks about changing offers, not answers. It is
>     > equally important to be able to modify answers. (More on this in
>     later
>     > comment on section 6.)
>     >
>     > Section 4.1.4:
>     >
>     >      The only difference between a provisional and final answer
>     is that
>     >      the final answer results in the freeing of any unused
>     resources that
>     >      were allocated as a result of the offer.  As such, the
>     application
>     >      can use some discretion on whether an answer should be
>     applied as
>     >      provisional or final, and can change the type of the session
>     >      description as needed.  For example, in a serial forking
>     scenario, an
>     >      application may receive multiple "final" answers, one from each
>     >      remote endpoint.  The application could choose to accept
>     the initial
>     >      answers as provisional answers, and only apply an answer as
>     final
>     >      when it receives one that meets its criteria (e.g. a live user
>     >      instead of voicemail).
>     >
>     > Issue: in this forking case, until the final selection is made it is
>     > unclear which one will need ICE completed. Only when a setlocal
>     is done
>     > on one of the answers will ICE begin to be performed. Then, if
>     another
>     > answer is provisionally set, won't that stop ICE for the prior
>     one? And
>     > won't it require new candidates? What if one of the earlier ones is
>     > eventually chosen as final?
>     >
>     > And what if ICE completes for one of the candidates? Can't media
>     start
>     > to flow? Then what if a different candidate is set as the final
>     answer?
>     >
>     > Section 4.1.4.1 :
>     >
>     > I question the following:
>     >
>     >      ...  While it is good practice to send an immediate
>     >      response to an "offer", in order to warm up the session
>     transport and
>     >      prevent media clipping, the preferred handling for a web
>     application
>     >      would be to create and send an "inactive" final answer
>     immediately
>     >      after receiving the offer.  Later, when the called user
>     actually
>     >      accepts the call, the application can create a new
>     "sendrecv" offer
>     >      to update the previous offer/answer pair and start the
>     media flow.
>     >
>     > This is very unfriendly when receiving calls that might be
>     forked. By
>     > immediately "answering" a call before knowing if the user will
>     accept
>     > it, you preempt the possibility that it will be answered on some
>     other fork.
>     >
>     > For instance, if a call could come to your browser, or be sent to an
>     > answering service, and your broswer is on but you aren't present to
>     > accept the call, then the call will be accepted and then dropped
>     rather
>     > than sent to the answering machine.
>     >
>     > So this technique should not be used if there is any possibility
>     that
>     > the request could be coming from a source that might try other
>     > possibilities.
>     >
>     > Section 5.2.1:
>     >
>     >      When createOffer is called for the first time, the result
>     is known as
>     >      the initial offer.
>     >
>     > By this definition, if a peer connection initially *received* an
>     offer
>     > and sent an answer, and then it later sends an offer then that offer
>     > would be considered an initial offer.
>     >
>     > I think perhaps what is intended is:
>     >
>     >      When createOffer is called before setLocal has been called with
>     >      an offer,  the result is known as the initial offer.
>     >
>     > The following doesn't support the "balanced" BUNDLE policy:
>     >
>     >      Once all m= sections have been generated, a session-level
>     "a=group"
>     >      attribute MUST be added as specified in [RFC5888].  This
>     attribute
>     >      MUST have semantics "BUNDLE", and MUST include the mid
>     identifiers of
>     >      each m= section.  The effect of this is that the browser
>     offers all
>     >      m= sections as one BUNDLE group.  However, whether the m=
>     sections
>     >      are bundle-only or not depends on the BUNDLE policy.
>     >
>     > Section 5.2.2 says:
>     >
>     >      o  If any MediaStreamTracks have been added, and there
>     exist recvonly
>     >         m= sections of the appropriate media type with no associated
>     >         MediaStreamTracks, or rejected m= sections of any media
>     type,
>     >         those m= sections MUST be recycled, and a local
>     MediaStreamTrack
>     >         associated with these recycled m= sections until all
>     such existing
>     >         m= sections have been used.  This includes any recvonly or
>     >         rejected m= sections created by the preceding paragraph.
>     >
>     > This fails to say anything about codec compatibility. SDP O/A
>     requires
>     > the answer to be a subset of the offer in terms of PT/codec
>     > configuration. You should not use the same m-line unless there is a
>     > desire to use the same settings for the new track as are
>     currently in
>     > use in the other direction.
>     >
>     > Section 5.3.1:
>     >
>     >      When createAnswer is called for the first time after a remote
>     >      description has been provided, the result is known as the
>     initial
>     >      answer.
>     >
>     > By this definition, if a peer connection initially sent an offer and
>     > received an answer, and then it later receives an offer then the
>     answer
>     > to that first *received* offer would be considered an Initial
>     Answer.
>     >
>     > I think perhaps what is intended is:
>     >
>     >      When createAnswer is called before setLocal has been called
>     with
>     >      an offer,  the result is known as the initial answer.
>     >
>     > When specifying the mapping of local tracks to m-lines in a received
>     > offer, there is again no discussion of codec compatibility. It
>     is quite
>     > possible that the m-line chosen by the algorithm in this section
>     won't
>     > have compatible codec attributes, but some other m-line will.
>     >
>     > Sections 5.3.2, 5.3.3, and 5.4-5.7:
>     >
>     > Are these empty because the content is yet to be written?
>     >
>     > Section 6:
>     >
>     > Other likely changes are addition of extra attributes and maybe
>     other
>     > parameters. For instance, CLUE will want to add another grouping
>     construct.
>     >
>     > 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


From nobody Tue Jul 22 18:43:09 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAD41A0164 for ; Tue, 22 Jul 2014 18:43:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.579
X-Spam-Level: 
X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4mikW28nU8s for ; Tue, 22 Jul 2014 18:43:07 -0700 (PDT)
Received: from mail-wg0-f41.google.com (na3sys009aog127.obsmtp.com [74.125.149.107]) by ietfa.amsl.com (Postfix) with SMTP id B04441A0151 for ; Tue, 22 Jul 2014 18:43:06 -0700 (PDT)
Received: from mail-wg0-f41.google.com ([74.125.82.41]) (using TLSv1) by na3sys009aob127.postini.com ([74.125.148.12]) with SMTP ID DSNKU88TKnwM4sw1ozxEbQIToK4n2mDOVgyF@postini.com; Tue, 22 Jul 2014 18:43:06 PDT
Received: by mail-wg0-f41.google.com with SMTP id z12so451621wgg.24 for ; Tue, 22 Jul 2014 18:43:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xAaHMljovEWqSoCcQ3RMtp8kWeSYBHzVkq944fPG3Eo=; b=XWAnQ1CGE02hGejBdywgxqzvnY5g//GV7kFxVAwcz2wiSdMqBbi1qsowWnANBiHDVW maP8t+hPpv2pR4ZI247Q+3/0wXfN6DKoEdfhq9CqkFGqFKJX8vZzscu1E+JKy0lJc6fC Z66vVluj3Jr/xnmUEPL7Wu7AqdWscUyGfDJ9A8Gk2HzhyXbRiuaVvlNPynI4B/LKUS9I kh1aDyk67UnOwZYd2GqrVI/N/GxIGJU9sqhjKCo4p0rEOsQlL9CzwfwEJ5U8zPCm8J4U 8XPEpAwBzvqvR1RPAi5VhiS8YOYJrC9ThkrKKAAVjp2U9nVTI5nMzVpoRUCZOJmAUPlv bntw==
X-Gm-Message-State: ALoCoQl3XyFLr48Y3SSzkZ63TsKyTe2B7V1+FM88DAwbxEFJ02d5jQlEyy0jCtEoU6UuMHUMk62CetO9dFYstwFgzeWycvx7sVa4ylFMBJEjB47ByCo9H3uJOvmhzam2UdltrfkYWqG3
X-Received: by 10.180.19.200 with SMTP id h8mr20449482wie.32.1406079784632; Tue, 22 Jul 2014 18:43:04 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.19.200 with SMTP id h8mr20449474wie.32.1406079784530; Tue, 22 Jul 2014 18:43:04 -0700 (PDT)
Received: by 10.194.60.178 with HTTP; Tue, 22 Jul 2014 18:43:04 -0700 (PDT)
In-Reply-To: 
References:  
Date: Tue, 22 Jul 2014 21:43:04 -0400
Message-ID: 
From: Michael Procter 
To: Martin Thomson 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nJeEVvaEI-dleoE6G8wtJQdLTtc
Cc: "" 
Subject: Re: [rtcweb] security-arch: 6.4.1 PeerConnection Origin Check
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 01:43:08 -0000

Pull request on github, issue 15.

On 22 July 2014 12:01, Martin Thomson  wrote:
> On 21 July 2014 16:51, Michael Procter  wrote:
>>
>>    Fundamentally, the IdP proxy is just a piece of JS loaded by
>>    the browser, so nothing stops a Web attacker from creating their
>>    own IFRAME, loading the IdP proxy JS, and requesting a
>>    signature.  In order to prevent this attack, we require that communication
>>    with the IdP proxy be via a MessageChannel in a way that cannot
>>    be emulated by hostile JS.  This is discussed in section 8.2.1 of
>> [webrtc-api].
>
>
> I'm having a hard time finding a fault with your suggestions Michael.
> This is great, thanks.


From nobody Tue Jul 22 18:43:42 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EB51A0164 for ; Tue, 22 Jul 2014 18:43:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.579
X-Spam-Level: 
X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T16hCX6yhkOR for ; Tue, 22 Jul 2014 18:43:40 -0700 (PDT)
Received: from mail-wi0-f180.google.com (na3sys009aog135.obsmtp.com [74.125.149.84]) by ietfa.amsl.com (Postfix) with SMTP id 17EB01A0151 for ; Tue, 22 Jul 2014 18:43:40 -0700 (PDT)
Received: from mail-wi0-f180.google.com ([209.85.212.180]) (using TLSv1) by na3sys009aob135.postini.com ([74.125.148.12]) with SMTP ID DSNKU88TS8ZF9BQ7xHaLvcsGWZ2pxoAefanT@postini.com; Tue, 22 Jul 2014 18:43:40 PDT
Received: by mail-wi0-f180.google.com with SMTP id n3so1395791wiv.1 for ; Tue, 22 Jul 2014 18:43:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UqDurv3Ewblrs08v8rzfi65hQVqtZeqGxoMptU+oIFo=; b=IdMr5ONGzCBAxnnLlJ5pauzj3NQDLsa/3pOH4wYxMYgG/KD3CkvWmxCgSQG4iT0i/N VFpLpVgZWznrNRA9HBpTqL2sqMZYQp+tKp/INVOikLnhLI/oQQfDli8NqYwl6u+KM0kw MnHaIgKb0nzKbc7JE8pbB860A854eHVUOYl/WQtRpFOByWfYboMx9LnUJsRY+AIHbLp3 YTfQYihhkIjUFFvwIY4W18nG/LfbWL2Y68w9uFVw/uAAAwimqckaAKSgBW/SYF2LC8I+ BZx8iQ9W5l1bp8oLeItj2PObeUMgn0rGXZqfrBWJ7j1ZhxgYzWKjiwLRgm6tCGOIUnFX dYXg==
X-Gm-Message-State: ALoCoQneoUof1/OaX7StGvHERQaEOwLmaa8KD8ysiPVTj4PMVVquuB5G11vzebj/++EjWCRIgyyyM+ecycrtrQoTH2J0XMtgj9kanY1TzdVmji83mWkSRbZIXY0QmF6V6GtcPrE6BKJ8
X-Received: by 10.180.210.239 with SMTP id mx15mr16548142wic.65.1406079818727;  Tue, 22 Jul 2014 18:43:38 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.210.239 with SMTP id mx15mr16548136wic.65.1406079818664;  Tue, 22 Jul 2014 18:43:38 -0700 (PDT)
Received: by 10.194.60.178 with HTTP; Tue, 22 Jul 2014 18:43:38 -0700 (PDT)
In-Reply-To: 
References:  
Date: Tue, 22 Jul 2014 21:43:38 -0400
Message-ID: 
From: Michael Procter 
To: Martin Thomson 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/A8o3AHhfi8x5oc3yEZf4Bhf5dWU
Cc: "" 
Subject: Re: [rtcweb] security-arch: 5.6.5.3.3: Managing User Login
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 01:43:41 -0000

Pull request on github, issue 14

On 22 July 2014 11:50, Martin Thomson  wrote:
> On 21 July 2014 16:21, Michael Procter  wrote:
>>    Once any user
>>    interactions are complete, the IFRAME MUST send a postMessage
>>    [WebMessaging] to its containing window indicating completion, as
>>    described in section 8.2.1 of [webrtc-api].
>
> Sounds like a good idea to me.


From nobody Tue Jul 22 20:18:42 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00C91A0304 for ; Tue, 22 Jul 2014 20:18:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 QoHTpJss9LiR for ; Tue, 22 Jul 2014 20:18:37 -0700 (PDT)
Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7A9D1A02FF for ; Tue, 22 Jul 2014 20:18:36 -0700 (PDT)
Received: by mail-vc0-f169.google.com with SMTP id hu12so1073876vcb.14 for ; Tue, 22 Jul 2014 20:18:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8VIiHODRAP0ESOMQT8l1p6/CyTDk4VLurAxpIzuSEbw=; b=KN8i1UUKzYfU/kJzBEKMv4o8vuN/ic9lb7o1dcsORT7A15RDVoVkMLCVC5RyZYAtyt 0hEJDkXFW+Amx/O9KvH5TECfJ4VUB+EVpiuyU2TS4fCJXO/G4UgXGEEh2NmNPAGwAJOo DoD1sINs85vZbW4JTuFgZ0bRxPmIMG0bChW+jG04Y+L6PyRHU0GNoo2KO5/jwsNC1SwU 0L5aNQBE0RYD+6p7xj9PFDlOxzuGsprxV7wRcT9Mf7vU61oiK2XKS+kK7zIV/eL1YraU kIuJt4nGV1hJ7a5bKZ3CRcwD0qkFvP3x+zgSI4gklQKxXk6HZotLQVvPvIcCu9jWlouS Pxkg==
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:content-type; bh=8VIiHODRAP0ESOMQT8l1p6/CyTDk4VLurAxpIzuSEbw=; b=QzzPq8D1KXxqrf6W+3yCZChSTDj8O+nte5xcWXLqqQa26EUVZL84X3hul7gnXMd8V8 WpnjtxVPH6wla/gZeTpj7rTEb2vXfncmvIhZVhGx/gnmPwC7Rn5haBiPaN9lsjTFqTmv ox8lzmq4NQIUjuAyAZjUgVPiPxY+9yddUpY1QtOMsZY4oTpmQgWHX236nhppjKODvf0K 6YSOgMJuEDJz5hIkDu+RcIPqOasdZWMRjVnhhUP4+/LIe+hQO691Df4tbH7Fdw2MAwg7 6Xr1FhwBAq3RobIh53rfYNLbT6MP44kF3Aa/hob0JGOBgddPl2enfYMmboerEPce8TNk hYuw==
X-Gm-Message-State: ALoCoQmUYJFiIi8FkOlkKYPSCV29WTqstwH99NXLcywX5g5ahXyFDxhMA9F7PK435nFX3Zf3f3K4
X-Received: by 10.52.228.40 with SMTP id sf8mr17660690vdc.78.1406085515846; Tue, 22 Jul 2014 20:18:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.66.242 with HTTP; Tue, 22 Jul 2014 20:18:15 -0700 (PDT)
In-Reply-To: <53CEFA2C.8040407@nteczone.com>
References:   <53CEFA2C.8040407@nteczone.com>
From: Justin Uberti 
Date: Tue, 22 Jul 2014 23:18:15 -0400
Message-ID: 
To: Christian Groves 
Content-Type: multipart/alternative; boundary=089e011602ceb2445e04fed3cb10
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fqSPmGpU8RcQsmVAiSCDkmIP9PI
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 03:18:40 -0000

--089e011602ceb2445e04fed3cb10
Content-Type: text/plain; charset=UTF-8

On Tue, Jul 22, 2014 at 7:56 PM, Christian Groves <
Christian.Groves@nteczone.com> wrote:

> The browser would delay the establishment of media that are part of the
> "a=group:clue" group until a CLUE exchange has taken place and those media
> have been selected via a CLUE configure message. I'm not sure if that fits
> your criteria for acting differently?
>
> The browser doesn't understand a=group:clue. How could it know that it
needs to wait for CLUE messaging to complete?



> On 21/07/2014 6:34 PM, Kevin Dempsey wrote:
>
>> Would the browser be expected to act differently with "a=group:clue"? If
>> not, then that is really part of the signalling and not part of the
>> createXxx/setXxxDescription interface.
>>
>> The SDP passed to setXxxDescription and the SDP sent as part of the
>> signalling (if SDP is used) do not need to be identical.
>>
>>
>> On 21 July 2014 03:35, Kiran Kumar Guduru > > wrote:
>>
>>     It seems there is a small mis-understanding here. I agree there is
>>     a need for parsing and editing SDP by JS application for now.
>>
>>     I am not saying that constraints will do everything.
>>
>>     My intention is, to find the possibilities to extend the API of
>>     existing RTCPeerConnection and proposed RTCRTPSender/Receiver to
>>     add the attributes required by JS application.
>>
>>     For now, I proposed solution for one such kind of problem, i.e.,
>>     prioritizing codecs.
>>
>>     setSdPAttribute (key, value) is just an example on top of my head,
>>     which might solve this. But we can really figure out this after
>>     getting the proposed API (RTCRTPSender/Receiver ) in draft.
>>
>>     Regards,
>>
>>     Kiran
>>
>>     ------- *Original Message* -------
>>
>>     *Sender* : Paul Kyzivat>     >
>>
>>     *Date* : Jul 19, 2014 22:35 (GMT+09:00)
>>
>>     *Title* : Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
>>
>>
>>     Kiran,
>>
>>
>>     My need won't be satisfied by plausible constraints.
>>     For instance, to interwork with CLUE it will be necessary to add an
>>     "a=group:clue" and include in it those m-lines that are to be "clue
>>     controlled". And that is needed in both offer and answer processing.
>>
>>     Thanks,
>>     Paul
>>
>>
>>     On 7/18/14 10:41 PM, Kiran Kumar Guduru wrote:
>>     > Dear Paul,
>>     >
>>     > My comment is only regarding the comments on section 6 of the
>>     JSEP draft.
>>     >
>>     > The sdp mangling described in section 6 may result in various error
>>     > scenarios.
>>     >
>>     > In that section, it is described like most of the parameters can be
>>     > modified thorugh constraints.
>>     >
>>     > The required modification, I found, which cannot not be done by the
>>     > constraints is "Remove or reorder of codecs (m=)"
>>     >
>>     > In order to avoid the SDP mangling at Java Script application
>>     level, I
>>     > submitted a draft for changing the codec preferences
>>     > http://tools.ietf.org/html/draft-guduru-rtcweb-codec-preferences-01
>> .
>>     > (Please review it).
>>     >
>>     > If this proposal is acceptable to the group, I hope we can remove
>>     > section 6 from JSEP draft.
>>     >
>>     > (Expecting that we can find alternatives for adding extra attributes
>>     > like CLUE as identified by you, for example by extending the
>>     > proposed RTCRTPSender/Receiver by adding a generic
>>     setSdPAttribute (key,
>>     > value) method).
>>     >
>>     > Thanks,
>>     >
>>     > Kiran.
>>     >
>>     >
>>     >
>>     > -------Original Message--------
>>     > Sent: Paul Kyzivat
>>     > Date: Fri, 18 Jul 2014 14:32:24 -0400
>>     > Subject: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
>>     >
>>     > I just did my first thorough read-through of JSEP in quite some
>>     time. I
>>     > came away with a number of concerns:
>>     >
>>     > Section 1.1:
>>     >
>>     > When describing offers, modification by the application is
>>     mentioned:
>>     >
>>     >      JSEP's handling of session descriptions is simple and
>>     >      straightforward.  Whenever an offer/answer exchange is
>>     needed, the
>>     >      initiating side creates an offer by calling a createOffer()
>>     API.  The
>>     >      application *optionally modifies that offer*, and then uses
>>     it to set
>>     >      up its local config via the setLocalDescription() API.
>>     >
>>     > but when describing answers it is not:
>>     >
>>     >      When the call is accepted, the callee uses the
>>     createAnswer() API to
>>     >      generate an appropriate answer, applies it using
>>     >      setLocalDescription(), and sends the answer back to the
>>     initiator
>>     >      over the signaling channel.  When the offerer gets that
>>     answer, it
>>     >      installs it using setRemoteDescription(), and initial setup is
>>     >      complete.
>>     >
>>     > And Section 6 only talks about changing offers, not answers. It is
>>     > equally important to be able to modify answers. (More on this in
>>     later
>>     > comment on section 6.)
>>     >
>>     > Section 4.1.4:
>>     >
>>     >      The only difference between a provisional and final answer
>>     is that
>>     >      the final answer results in the freeing of any unused
>>     resources that
>>     >      were allocated as a result of the offer.  As such, the
>>     application
>>     >      can use some discretion on whether an answer should be
>>     applied as
>>     >      provisional or final, and can change the type of the session
>>     >      description as needed.  For example, in a serial forking
>>     scenario, an
>>     >      application may receive multiple "final" answers, one from each
>>     >      remote endpoint.  The application could choose to accept
>>     the initial
>>     >      answers as provisional answers, and only apply an answer as
>>     final
>>     >      when it receives one that meets its criteria (e.g. a live user
>>     >      instead of voicemail).
>>     >
>>     > Issue: in this forking case, until the final selection is made it is
>>     > unclear which one will need ICE completed. Only when a setlocal
>>     is done
>>     > on one of the answers will ICE begin to be performed. Then, if
>>     another
>>     > answer is provisionally set, won't that stop ICE for the prior
>>     one? And
>>     > won't it require new candidates? What if one of the earlier ones is
>>     > eventually chosen as final?
>>     >
>>     > And what if ICE completes for one of the candidates? Can't media
>>     start
>>     > to flow? Then what if a different candidate is set as the final
>>     answer?
>>     >
>>     > Section 4.1.4.1 :
>>
>>     >
>>     > I question the following:
>>     >
>>     >      ...  While it is good practice to send an immediate
>>     >      response to an "offer", in order to warm up the session
>>     transport and
>>     >      prevent media clipping, the preferred handling for a web
>>     application
>>     >      would be to create and send an "inactive" final answer
>>     immediately
>>     >      after receiving the offer.  Later, when the called user
>>     actually
>>     >      accepts the call, the application can create a new
>>     "sendrecv" offer
>>     >      to update the previous offer/answer pair and start the
>>     media flow.
>>     >
>>     > This is very unfriendly when receiving calls that might be
>>     forked. By
>>     > immediately "answering" a call before knowing if the user will
>>     accept
>>     > it, you preempt the possibility that it will be answered on some
>>     other fork.
>>     >
>>     > For instance, if a call could come to your browser, or be sent to an
>>     > answering service, and your broswer is on but you aren't present to
>>     > accept the call, then the call will be accepted and then dropped
>>     rather
>>     > than sent to the answering machine.
>>     >
>>     > So this technique should not be used if there is any possibility
>>     that
>>     > the request could be coming from a source that might try other
>>     > possibilities.
>>     >
>>     > Section 5.2.1:
>>     >
>>     >      When createOffer is called for the first time, the result
>>     is known as
>>     >      the initial offer.
>>     >
>>     > By this definition, if a peer connection initially *received* an
>>     offer
>>     > and sent an answer, and then it later sends an offer then that offer
>>     > would be considered an initial offer.
>>     >
>>     > I think perhaps what is intended is:
>>     >
>>     >      When createOffer is called before setLocal has been called with
>>     >      an offer,  the result is known as the initial offer.
>>     >
>>     > The following doesn't support the "balanced" BUNDLE policy:
>>     >
>>     >      Once all m= sections have been generated, a session-level
>>     "a=group"
>>     >      attribute MUST be added as specified in [RFC5888].  This
>>     attribute
>>     >      MUST have semantics "BUNDLE", and MUST include the mid
>>     identifiers of
>>     >      each m= section.  The effect of this is that the browser
>>     offers all
>>     >      m= sections as one BUNDLE group.  However, whether the m=
>>     sections
>>     >      are bundle-only or not depends on the BUNDLE policy.
>>     >
>>     > Section 5.2.2 says:
>>     >
>>     >      o  If any MediaStreamTracks have been added, and there
>>     exist recvonly
>>     >         m= sections of the appropriate media type with no associated
>>     >         MediaStreamTracks, or rejected m= sections of any media
>>     type,
>>     >         those m= sections MUST be recycled, and a local
>>     MediaStreamTrack
>>     >         associated with these recycled m= sections until all
>>     such existing
>>     >         m= sections have been used.  This includes any recvonly or
>>     >         rejected m= sections created by the preceding paragraph.
>>     >
>>     > This fails to say anything about codec compatibility. SDP O/A
>>     requires
>>     > the answer to be a subset of the offer in terms of PT/codec
>>     > configuration. You should not use the same m-line unless there is a
>>     > desire to use the same settings for the new track as are
>>     currently in
>>     > use in the other direction.
>>     >
>>     > Section 5.3.1:
>>     >
>>     >      When createAnswer is called for the first time after a remote
>>     >      description has been provided, the result is known as the
>>     initial
>>     >      answer.
>>     >
>>     > By this definition, if a peer connection initially sent an offer and
>>     > received an answer, and then it later receives an offer then the
>>     answer
>>     > to that first *received* offer would be considered an Initial
>>     Answer.
>>     >
>>     > I think perhaps what is intended is:
>>     >
>>     >      When createAnswer is called before setLocal has been called
>>     with
>>     >      an offer,  the result is known as the initial answer.
>>     >
>>     > When specifying the mapping of local tracks to m-lines in a received
>>     > offer, there is again no discussion of codec compatibility. It
>>     is quite
>>     > possible that the m-line chosen by the algorithm in this section
>>     won't
>>     > have compatible codec attributes, but some other m-line will.
>>     >
>>     > Sections 5.3.2, 5.3.3, and 5.4-5.7:
>>     >
>>     > Are these empty because the content is yet to be written?
>>     >
>>     > Section 6:
>>     >
>>     > Other likely changes are addition of extra attributes and maybe
>>     other
>>     > parameters. For instance, CLUE will want to add another grouping
>>     construct.
>>     >
>>     > 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
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

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




On Tue, Jul 22, 2014 at 7:56 PM, Christian Groves <=
;Christi=
an.Groves@nteczone.com> wrote:



The browser would delay the establishment of=
 media that are part of the "a=3Dgroup:clue" group until a CLUE e=
xchange has taken place and those media have been selected via a CLUE confi=
gure message. I'm not sure if that fits your criteria for acting differ=
ently?




The browser doesn't understand a=3Dgroup:clue. Ho=
w could it know that it needs to wait for CLUE messaging to complete?
=








On 21/07/2014 6:34 PM, Kevin Dempsey wrote:



Would the browser be expected to act differently with "a=3Dgroup:clue&=
quot;? If not, then that is really part of the signalling and not part of t=
he createXxx/setXxxDescription interface.



The SDP passed to setXxxDescription and the SDP sent as part of the signall=
ing (if SDP is used) do not need to be identical.





On 21 July 2014 03:35, Kiran Kumar Guduru <kiran.guduru@samsung.com <mailto:kiran.guduru@sa=
msung.com>> wrote:





=C2=A0 =C2=A0 It seems there is a small mis-understanding here. I agree the=
re is

=C2=A0 =C2=A0 a need for parsing and editing SDP by JS application for now.=




=C2=A0 =C2=A0 I am not saying that constraints will do everything.



=C2=A0 =C2=A0 My intention is, to find the possibilities to extend the API =
of

=C2=A0 =C2=A0 existing RTCPeerConnection and proposed RTCRTPSender/Receiver=
 to

=C2=A0 =C2=A0 add the attributes required by JS application.



=C2=A0 =C2=A0 For now, I proposed solution for one such kind of problem, i.=
e.,

=C2=A0 =C2=A0 prioritizing codecs.



=C2=A0 =C2=A0 setSdPAttribute (key, value) is just an example on top of my =
head,

=C2=A0 =C2=A0 which might solve this. But we can really figure out this aft=
er

=C2=A0 =C2=A0 getting the proposed API (RTCRTPSender/Receiver ) in draft.


=C2=A0 =C2=A0 Regards,



=C2=A0 =C2=A0 Kiran



=C2=A0 =C2=A0 ------- *Original Message* -------



=C2=A0 =C2=A0 *Sender* : Paul Kyzivat<pkyzivat@alum.mit.edu

=C2=A0 =C2=A0 <mailto:pkyzivat@alum.mit.edu>>



=C2=A0 =C2=A0 *Date* : Jul 19, 2014 22:35 (GMT+09:00)



=C2=A0 =C2=A0 *Title* : Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07




=C2=A0 =C2=A0 Kiran,





=C2=A0 =C2=A0 My need won't be satisfied by plausible constraints.

=C2=A0 =C2=A0 For instance, to interwork with CLUE it will be necessary to =
add an

=C2=A0 =C2=A0 "a=3Dgroup:clue" and include in it those m-lines th=
at are to be "clue

=C2=A0 =C2=A0 controlled". And that is needed in both offer and answer=
 processing.



=C2=A0 =C2=A0 Thanks,

=C2=A0 =C2=A0 Paul





=C2=A0 =C2=A0 On 7/18/14 10:41 PM, Kiran Kumar Guduru wrote:

=C2=A0 =C2=A0 > Dear Paul,

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > My comment is only regarding the comments on section 6 o=
f the

=C2=A0 =C2=A0 JSEP draft.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > The sdp mangling described in section 6 may result in va=
rious error

=C2=A0 =C2=A0 > scenarios.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > In that section, it is described like most of the parame=
ters can be

=C2=A0 =C2=A0 > modified thorugh constraints.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > The required modification, I found, which cannot not be =
done by the

=C2=A0 =C2=A0 > constraints is "Remove or reorder of codecs (m=3D)&=
quot;

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > In order to avoid the SDP mangling at Java Script applic=
ation

=C2=A0 =C2=A0 level, I

=C2=A0 =C2=A0 > submitted a draft for changing the codec preferences

=C2=A0 =C2=A0 > http://tools.ietf.org/html/draft-guduru-rtcweb-codec-preferences-01.

=C2=A0 =C2=A0 > (Please review it).

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > If this proposal is acceptable to the group, I hope we c=
an remove

=C2=A0 =C2=A0 > section 6 from JSEP draft.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > (Expecting that we can find alternatives for adding extr=
a attributes

=C2=A0 =C2=A0 > like CLUE as identified by you, for example by extending=
 the

=C2=A0 =C2=A0 > proposed RTCRTPSender/Receiver by adding a generic

=C2=A0 =C2=A0 setSdPAttribute (key,

=C2=A0 =C2=A0 > value) method).

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > Thanks,

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > Kiran.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > -------Original Message--------

=C2=A0 =C2=A0 > Sent: Paul Kyzivat

=C2=A0 =C2=A0 > Date: Fri, 18 Jul 2014 14:32:24 -0400

=C2=A0 =C2=A0 > Subject: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > I just did my first thorough read-through of JSEP in qui=
te some

=C2=A0 =C2=A0 time. I

=C2=A0 =C2=A0 > came away with a number of concerns:

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > Section 1.1:

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > When describing offers, modification by the application =
is

=C2=A0 =C2=A0 mentioned:

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0JSEP's handling of session descr=
iptions is simple and

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0straightforward. =C2=A0Whenever an o=
ffer/answer exchange is

=C2=A0 =C2=A0 needed, the

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0initiating side creates an offer by =
calling a createOffer()

=C2=A0 =C2=A0 API. =C2=A0The

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0application *optionally modifies tha=
t offer*, and then uses

=C2=A0 =C2=A0 it to set

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0up its local config via the setLocal=
Description() API.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > but when describing answers it is not:

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0When the call is accepted, the calle=
e uses the

=C2=A0 =C2=A0 createAnswer() API to

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0generate an appropriate answer, appl=
ies it using

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0setLocalDescription(), and sends the=
 answer back to the

=C2=A0 =C2=A0 initiator

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0over the signaling channel. =C2=A0Wh=
en the offerer gets that

=C2=A0 =C2=A0 answer, it

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0installs it using setRemoteDescripti=
on(), and initial setup is

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0complete.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > And Section 6 only talks about changing offers, not answ=
ers. It is

=C2=A0 =C2=A0 > equally important to be able to modify answers. (More on=
 this in

=C2=A0 =C2=A0 later

=C2=A0 =C2=A0 > comment on section 6.)

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > Section 4.1.4:

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0The only difference between a provis=
ional and final answer

=C2=A0 =C2=A0 is that

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0the final answer results in the free=
ing of any unused

=C2=A0 =C2=A0 resources that

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0were allocated as a result of the of=
fer. =C2=A0As such, the

=C2=A0 =C2=A0 application

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0can use some discretion on whether a=
n answer should be

=C2=A0 =C2=A0 applied as

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0provisional or final, and can change=
 the type of the session

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0description as needed. =C2=A0For exa=
mple, in a serial forking

=C2=A0 =C2=A0 scenario, an

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0application may receive multiple &qu=
ot;final" answers, one from each

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0remote endpoint. =C2=A0The applicati=
on could choose to accept

=C2=A0 =C2=A0 the initial

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0answers as provisional answers, and =
only apply an answer as

=C2=A0 =C2=A0 final

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0when it receives one that meets its =
criteria (e.g. a live user

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0instead of voicemail).

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > Issue: in this forking case, until the final selection i=
s made it is

=C2=A0 =C2=A0 > unclear which one will need ICE completed. Only when a s=
etlocal

=C2=A0 =C2=A0 is done

=C2=A0 =C2=A0 > on one of the answers will ICE begin to be performed. Th=
en, if

=C2=A0 =C2=A0 another

=C2=A0 =C2=A0 > answer is provisionally set, won't that stop ICE for=
 the prior

=C2=A0 =C2=A0 one? And

=C2=A0 =C2=A0 > won't it require new candidates? What if one of the =
earlier ones is

=C2=A0 =C2=A0 > eventually chosen as final?

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > And what if ICE completes for one of the candidates? Can=
't media

=C2=A0 =C2=A0 start

=C2=A0 =C2=A0 > to flow? Then what if a different candidate is set as th=
e final

=C2=A0 =C2=A0 answer?

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > Section 4.1.4.1 <http://4.1.4.1>:


=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > I question the following:

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0... =C2=A0While it is good practice =
to send an immediate

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0response to an "offer", in=
 order to warm up the session

=C2=A0 =C2=A0 transport and

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0prevent media clipping, the preferre=
d handling for a web

=C2=A0 =C2=A0 application

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0would be to create and send an "=
;inactive" final answer

=C2=A0 =C2=A0 immediately

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0after receiving the offer. =C2=A0Lat=
er, when the called user

=C2=A0 =C2=A0 actually

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0accepts the call, the application ca=
n create a new

=C2=A0 =C2=A0 "sendrecv" offer

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0to update the previous offer/answer =
pair and start the

=C2=A0 =C2=A0 media flow.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > This is very unfriendly when receiving calls that might =
be

=C2=A0 =C2=A0 forked. By

=C2=A0 =C2=A0 > immediately "answering" a call before knowing =
if the user will

=C2=A0 =C2=A0 accept

=C2=A0 =C2=A0 > it, you preempt the possibility that it will be answered=
 on some

=C2=A0 =C2=A0 other fork.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > For instance, if a call could come to your browser, or b=
e sent to an

=C2=A0 =C2=A0 > answering service, and your broswer is on but you aren&#=
39;t present to

=C2=A0 =C2=A0 > accept the call, then the call will be accepted and then=
 dropped

=C2=A0 =C2=A0 rather

=C2=A0 =C2=A0 > than sent to the answering machine.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > So this technique should not be used if there is any pos=
sibility

=C2=A0 =C2=A0 that

=C2=A0 =C2=A0 > the request could be coming from a source that might try=
 other

=C2=A0 =C2=A0 > possibilities.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > Section 5.2.1:

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0When createOffer is called for the f=
irst time, the result

=C2=A0 =C2=A0 is known as

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0the initial offer.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > By this definition, if a peer connection initially *rece=
ived* an

=C2=A0 =C2=A0 offer

=C2=A0 =C2=A0 > and sent an answer, and then it later sends an offer the=
n that offer

=C2=A0 =C2=A0 > would be considered an initial offer.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > I think perhaps what is intended is:

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0When createOffer is called before se=
tLocal has been called with

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0an offer, =C2=A0the result is known =
as the initial offer.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > The following doesn't support the "balanced&quo=
t; BUNDLE policy:

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0Once all m=3D sections have been gen=
erated, a session-level

=C2=A0 =C2=A0 "a=3Dgroup"

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0attribute MUST be added as specified=
 in [RFC5888]. =C2=A0This

=C2=A0 =C2=A0 attribute

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0MUST have semantics "BUNDLE&quo=
t;, and MUST include the mid

=C2=A0 =C2=A0 identifiers of

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0each m=3D section. =C2=A0The effect =
of this is that the browser

=C2=A0 =C2=A0 offers all

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0m=3D sections as one BUNDLE group. =
=C2=A0However, whether the m=3D

=C2=A0 =C2=A0 sections

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0are bundle-only or not depends on th=
e BUNDLE policy.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > Section 5.2.2 says:

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0o =C2=A0If any MediaStreamTracks hav=
e been added, and there

=C2=A0 =C2=A0 exist recvonly

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 m=3D sections of the appropr=
iate media type with no associated

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 MediaStreamTracks, or reject=
ed m=3D sections of any media

=C2=A0 =C2=A0 type,

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 those m=3D sections MUST be =
recycled, and a local

=C2=A0 =C2=A0 MediaStreamTrack

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 associated with these recycl=
ed m=3D sections until all

=C2=A0 =C2=A0 such existing

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 m=3D sections have been used=
. =C2=A0This includes any recvonly or

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 rejected m=3D sections creat=
ed by the preceding paragraph.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > This fails to say anything about codec compatibility. SD=
P O/A

=C2=A0 =C2=A0 requires

=C2=A0 =C2=A0 > the answer to be a subset of the offer in terms of PT/co=
dec

=C2=A0 =C2=A0 > configuration. You should not use the same m-line unless=
 there is a

=C2=A0 =C2=A0 > desire to use the same settings for the new track as are=


=C2=A0 =C2=A0 currently in

=C2=A0 =C2=A0 > use in the other direction.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > Section 5.3.1:

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0When createAnswer is called for the =
first time after a remote

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0description has been provided, the r=
esult is known as the

=C2=A0 =C2=A0 initial

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0answer.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > By this definition, if a peer connection initially sent =
an offer and

=C2=A0 =C2=A0 > received an answer, and then it later receives an offer =
then the

=C2=A0 =C2=A0 answer

=C2=A0 =C2=A0 > to that first *received* offer would be considered an In=
itial

=C2=A0 =C2=A0 Answer.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > I think perhaps what is intended is:

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0When createAnswer is called before s=
etLocal has been called

=C2=A0 =C2=A0 with

=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0an offer, =C2=A0the result is known =
as the initial answer.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > When specifying the mapping of local tracks to m-lines i=
n a received

=C2=A0 =C2=A0 > offer, there is again no discussion of codec compatibili=
ty. It

=C2=A0 =C2=A0 is quite

=C2=A0 =C2=A0 > possible that the m-line chosen by the algorithm in this=
 section

=C2=A0 =C2=A0 won't

=C2=A0 =C2=A0 > have compatible codec attributes, but some other m-line =
will.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > Sections 5.3.2, 5.3.3, and 5.4-5.7:

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > Are these empty because the content is yet to be written=
?

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > Section 6:

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > Other likely changes are addition of extra attributes an=
d maybe

=C2=A0 =C2=A0 other

=C2=A0 =C2=A0 > parameters. For instance, CLUE will want to add another =
grouping

=C2=A0 =C2=A0 construct.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > Thanks,

=C2=A0 =C2=A0 > Paul

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >





=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 rtcweb mailing list

=C2=A0 =C2=A0 rtcweb@i=
etf.org <mailto:rtcweb@ietf.org>

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










_______________________________________________

rtcweb mailing list

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





_______________________________________________

rtcweb mailing list

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





--089e011602ceb2445e04fed3cb10--


From nobody Tue Jul 22 20:42:56 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7509E1A0316 for ; Tue, 22 Jul 2014 20:42:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 3FG8OHxe6S_d for ; Tue, 22 Jul 2014 20:42:53 -0700 (PDT)
Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 988341A0202 for ; Tue, 22 Jul 2014 20:42:53 -0700 (PDT)
Received: by mail-vc0-f181.google.com with SMTP id lf12so1055675vcb.40 for ; Tue, 22 Jul 2014 20:42:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=w8zyzHX9odwNzDBO2JDDh/uDSmpsPlzx/Bx+o51IKTM=; b=Ul7+/gkWGweVU5BVILMsEcReZAOBMUCdTi72o9NoiOasT8ER+gg/UgTBbISUC5ZZKI u9nLe/eJjrlBWy/l+OICbde+Kc0LMWDc5RnGOWAZkxeIrdQ86FGwtKLoKb/GDXkabHNw AjnTDsPFpnFcJ+bR0UBygj/2BAHF6dpfQ/Eih0KUmSOiNfs1ASXb3XtypucCfcrlGqsU gNF/7OJUKqQTfv08vR214yuZfeNdmLLIE/tKsmBiEzZpXpgMIxYhB8QD1t8pcYQgRcHc 1L/8CiLuTOmeLPXrmlBGUik9c7Tf4Kmjp5CMAsHwkDDl/TGcQi57cjdWOhOJ5PfX/BeJ UdYA==
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:content-type; bh=w8zyzHX9odwNzDBO2JDDh/uDSmpsPlzx/Bx+o51IKTM=; b=NazHfPl561X1JwWC1g3GbseyxFr97ktdxuXSP4EtdtS1oUwD6J/sPhZkCqxVmRX89+ u6w1Wi482Sy7qb747yNUfqAKlg2crOXsvQAMQdBurgn75/tKBCAfjhtWgnjfvLy4D1JP Jahg16d7NcJsVFbp9bQqoDFm70H2AhEQN2ct3lTCUfWgNk9Pcc1CeeJ8hjyO2j2bHVKG /bNVr5UGkdtygG/397cLbE7HPBmUnGM+oNhuCKnoTYIVzVR+7FHjfpMFqZK0/63oOuoK n0G4VjRVBsHnTILdX0/82jiV7Y1BHBNGjpYLMkjcX67YZc0CuxHVwPl2SWT/cik3GmHh BxRw==
X-Gm-Message-State: ALoCoQl0zTmTAiAHfO53a0ow+qSHuCFoNYJZG0jNzhGzw76WhM9noVB4go07e2rSca4d5ORjTqKC
X-Received: by 10.220.252.198 with SMTP id mx6mr45832672vcb.15.1406086972560;  Tue, 22 Jul 2014 20:42:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.66.242 with HTTP; Tue, 22 Jul 2014 20:42:32 -0700 (PDT)
In-Reply-To: 
References: 
From: Justin Uberti 
Date: Tue, 22 Jul 2014 23:42:32 -0400
Message-ID: 
To: Kiran Kumar Guduru 
Content-Type: multipart/alternative; boundary=089e013a044a86004204fed4227d
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fC22QmxnNLKeB7OBHP91ubrsVsY
Cc: franklin blek , "rtcweb@ietf.org" , "public-webrtc@w3.org" 
Subject: Re: [rtcweb] New Version Notification for draft-guduru-rtcweb-codec-preferences-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 03:42:54 -0000

--089e013a044a86004204fed4227d
Content-Type: text/plain; charset=UTF-8

>
>
>
> This is a useful example, thanks for explaining this. But I think this is
> the wrong solution. Quoth RFC3264, S. 7:
>
> *   When the offerer receives the answer, it MAY send media on the*
> *   accepted stream(s) (assuming it is listed as sendrecv or recvonly in*
> *   the answer).  It MUST send using a media format listed in the answer,*
> *   and it SHOULD use the first media format listed in the answer when it*
> *   does send.*
>
>  Note the use of SHOULD vs MUST.
>  [KIRAN] section 7 explains about "offerer processing of the Answer". But
> I think the correct section for my explanation is section 6, " Generating
> the Answer", which recommonds to use the same order of preference as that
> in the offer.
>
>
>    "Although the answerer MAY list the formats in their desired order of
>    preference, it is RECOMMENDED that unless there is a specific reason,
>    the answerer list formats in the same relative order they were
>    present in the offer."
>
>
The text says "unless there is a specific reason". You have a specific
reason. Just do it.

It is far more sensible to change the order of codecs in the answer, than
to send a reoffer with changed codecs immediately afterwards.

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











This is a useful example, thanks for explaining this. But I think this=
 is the wrong solution. Quoth RFC3264, S. 7:





=C2=A0 =C2=A0When the offerer receives the answer, it MAY send medi=
a on the


=C2=A0 =C2=A0accepted stream(s) (assuming it is listed as sendrecv =
or recvonly in


=C2=A0 =C2=A0the answer). =C2=A0It MUST send using a media format l=
isted in the answer,


=C2=A0 =C2=A0and it SHOULD use the first media format listed in the=
 answer when it


=C2=A0 =C2=A0does send.





Note the use of SHOULD vs MUST.




[KIRAN] section 7 explains about "offerer processing of the Answe=
r". But I think the correct section for my explanation is section 6, &=
quot; Generating the Answer", which recommonds to use the same order o=
f preference as that in the offer.









   "Although the answerer MAY list the formats in their desired order =
of
   preference, it is RECOMMENDED that unless there is a specific reason,
   the answerer list formats in the same relative order they were
   present in the offer."

The text says "unless there is a specifi=
c reason". You have a specific reason. Just do it.=C2=A0



It is far more sensible to change the order of codecs in the ans=
wer, than to send a reoffer with changed codecs immediately afterwards.






--089e013a044a86004204fed4227d--


From nobody Tue Jul 22 20:58:28 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07EA1A0316 for ; Tue, 22 Jul 2014 20:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 bCOKE2KJzVxT for ; Tue, 22 Jul 2014 20:58:24 -0700 (PDT)
Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 123191A0352 for ; Tue, 22 Jul 2014 20:58:22 -0700 (PDT)
Received: by mail-vc0-f178.google.com with SMTP id la4so1124457vcb.9 for ; Tue, 22 Jul 2014 20:58:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=iQft21lxIN05xrOvJD2q24pCOhH8LonIZXhN+AI1l80=; b=DSvC4Fnl6q8H2MQuHiJLCIBRFygIq0VX+R4rAaV9SsLgumMNIHlmrFrojmQlIZ6INm KlATAA8eaU2mPdBlvy6WM6b6EpPT+zTeqF0hg+s3kHuQ0kU0aH6EzjPb9G/FVevU0lXt 8iZOXARaHU7yjViHu3bVXr0S2r0u0ePnRxlyminoC0oRf1baEDzxCIppK+RJRLDCV2mb 2QdIK+ixu2ocDwB4WigoM91fC0BoN7ZK+RW/ju4gRsCsnimCBA5+oCxXknTm+lmrwFL6 vPx6GLxrpLXGnQ12LdrLI8pKVpP3NV6UV+BIHjs+MkCrMc0a4A8qzY8fFE6MwkiFoMGW dpJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=iQft21lxIN05xrOvJD2q24pCOhH8LonIZXhN+AI1l80=; b=RzqOK8YIuri4XNnVSIPTh5EAf/c2Zj55B1eWVRj95wDbnfBsSwewFN5cxHuCoeqn/m VVL3Ymosl8l2/fB7tNJgWX/hhMn0Gw6fOSJxUOn4OxOM3EcMf2rKNyk6sVV/gmxpT30g nJtANHfsQXKqiwamRKpcTs/7glEtq1wpuHaLjxX1uZt3tvX+Hv2LZegsiJs65Sd6Av0P rVbkG4Oc8jJvzJr2B8JUct70lmO+82zbRIluERsi6LK9bD3dVTk41dsDARkNGD8HcpAd tl7wMiHe/xUB6yS7zz+8REP4YAwrttQIVCD7pTtclPdsHQlRhzIjFshMQ+JJB2sUzdau c55Q==
X-Gm-Message-State: ALoCoQkV6DUphOXJn8Ys3ZG1/4MJa3aaBQAI0QZy9kxTV06VmU+CA6FM72J0EXTXOzUweOnAIopv
X-Received: by 10.52.0.177 with SMTP id 17mr39305265vdf.12.1406087902145; Tue, 22 Jul 2014 20:58:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.66.242 with HTTP; Tue, 22 Jul 2014 20:58:01 -0700 (PDT)
From: Justin Uberti 
Date: Tue, 22 Jul 2014 23:58:01 -0400
Message-ID: 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7b86e4f2ee50fd04fed45923
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/llUjOAydSb3aiX4VSExlEXx3AAU
Subject: [rtcweb] Sending of zero-length messages over data channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 03:58:26 -0000

--047d7b86e4f2ee50fd04fed45923
Content-Type: text/plain; charset=UTF-8

In the existing data channel protocol, it's not possible to send
zero-length messages, because SCTP prohibits it.

While this may seem to be an academic point, it does represent a divergence
from WebSockets, and this difference could be meaningful to applications
who use empty messages for keepalives. Or maybe the Yo app.

Since we can't send a zero-length SCTP message, I propose we add a
PPID_EMPTY value or something similar to indicate a message with empty
content.

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


In the existing data channel protocol, it's not possib=
le to send zero-length messages, because SCTP prohibits it.

<=
div>While this may seem to be an academic point, it does represent a diverg=
ence from WebSockets, and this difference could be meaningful to applicatio=
ns who use empty messages for keepalives. Or maybe the Yo app.




Since we can't send a zero-length SCTP message, I p=
ropose we add a PPID_EMPTY value or something similar to indicate a message=
 with empty content.


--047d7b86e4f2ee50fd04fed45923--


From nobody Wed Jul 23 04:12:15 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C471A02EC for ; Wed, 23 Jul 2014 04:12:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.552
X-Spam-Level: 
X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=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 CSlIpLOz83Ry for ; Wed, 23 Jul 2014 04:12:11 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73F9C1A02DD for ; Wed, 23 Jul 2014 04:12:11 -0700 (PDT)
Received: from dhcp-9132.meeting.ietf.org (dhcp-9132.meeting.ietf.org [31.133.145.50]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 0A38C1C104DEA; Wed, 23 Jul 2014 13:12:07 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Michael Tuexen 
In-Reply-To: 
Date: Wed, 23 Jul 2014 07:12:06 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <2CB7681C-815F-48BD-8BC0-A1F13ED6A9F5@lurchi.franken.de>
References: 
To: Justin Uberti 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/COu7m7Ep5fC3y6bh3tv2MrgDJP0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Sending of zero-length messages over data channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 11:12:13 -0000

On 22 Jul 2014, at 23:58, Justin Uberti  wrote:

> In the existing data channel protocol, it's not possible to send =
zero-length messages, because SCTP prohibits it.
>=20
> While this may seem to be an academic point, it does represent a =
divergence from WebSockets, and this difference could be meaningful to =
applications who use empty messages for keepalives. Or maybe the Yo app.
>=20
> Since we can't send a zero-length SCTP message, I propose we add a =
PPID_EMPTY value or something similar to indicate a message with empty =
content.
That works. The corresponding payload would be ignored...
One could add a sentence or two in
http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-11#section-6.6
and in the IANA section.

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


From nobody Wed Jul 23 05:00:38 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADAF1A0AC4 for ; Wed, 23 Jul 2014 05:00:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiGFky0dBEqk for ; Wed, 23 Jul 2014 05:00:30 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A160F1A0AC1 for ; Wed, 23 Jul 2014 05:00:29 -0700 (PDT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s6NC0Nh4003104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jul 2014 07:00:23 -0500 (CDT)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s6NC0NXS020781 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 08:00:23 -0400
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Wed, 23 Jul 2014 08:00:22 -0400
From: "Makaraju, Maridi Raju (Raju)" 
To: Justin Uberti , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Sending of zero-length messages over data channels
Thread-Index: AQHPpipfEWtPO6jXOES6Y6R7CwNaxJutiTxg
Date: Wed, 23 Jul 2014 12:00:22 +0000
Deferred-Delivery: Wed, 23 Jul 2014 12:00:00 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.18]
Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E4BCC13US70UWXCHMBA02z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xFNm-NvcFAuXjQ3XhZvkJaPL9Jk
Subject: Re: [rtcweb] Sending of zero-length messages over data channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 12:00:34 -0000

--_000_E1FE4C082A89A246A11D7F32A95A17828E4BCC13US70UWXCHMBA02z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQpJbiB0aGUgZXhpc3RpbmcgZGF0YSBjaGFubmVsIHByb3RvY29sLCBpdCdzIG5vdCBwb3NzaWJs
ZSB0byBzZW5kIHplcm8tbGVuZ3RoIG1lc3NhZ2VzLCBiZWNhdXNlIFNDVFAgcHJvaGliaXRzIGl0
Lg0KDQpXaGlsZSB0aGlzIG1heSBzZWVtIHRvIGJlIGFuIGFjYWRlbWljIHBvaW50LCBpdCBkb2Vz
IHJlcHJlc2VudCBhIGRpdmVyZ2VuY2UgZnJvbSBXZWJTb2NrZXRzLCBhbmQgdGhpcyBkaWZmZXJl
bmNlIGNvdWxkIGJlIG1lYW5pbmdmdWwgdG8gYXBwbGljYXRpb25zIHdobyB1c2UgZW1wdHkgbWVz
c2FnZXMgZm9yIGtlZXBhbGl2ZXMuIE9yIG1heWJlIHRoZSBZbyBhcHAuDQoNClNpbmNlIHdlIGNh
bid0IHNlbmQgYSB6ZXJvLWxlbmd0aCBTQ1RQIG1lc3NhZ2UsIEkgcHJvcG9zZSB3ZSBhZGQgYSBQ
UElEX0VNUFRZIHZhbHVlIG9yIHNvbWV0aGluZyBzaW1pbGFyIHRvIGluZGljYXRlIGEgbWVzc2Fn
ZSB3aXRoIGVtcHR5IGNvbnRlbnQuDQpbUmFqdV0gVGhlcmUgaXMgYSBnZW51aW5lIG5lZWQgZm9y
IHRoaXMgYW5kIHRoZSBwcm9wb3NhbCBpcyBnb29kLg0KSG93ZXZlciwgSSBhbSB0aGlua2luZyBv
ZiBhbiBhbHRlcm5hdGUgcHJvcG9zYWwgdG8gYWNoaWV2ZSB0aGUgc2FtZSBidXQgaW4gYSBnZW5l
cmljIHdheS4NCkRlZmluZSBhIFBQSURfT09CIChvdXQgb2YgYmFuZCkgb3Igc29tZXRoaW5nIHNp
bWlsYXIuDQpBcHBzIGNhbiB1c2UgdGhpcyB0byBzZW5kIGEgbWVzc2FnZSBvZiBub24temVybyBs
ZW5ndGguIEZvciB0aGUg4oCcWW/igJ0ga2luZCBvZiBhcHAgb3IgZW1wdHkgc3RyZWFtLWxldmVs
IGhlYXJ0YmVhdCBwdXJwb3NlLCBhcHAgY2FuIHNlbmQgYSAxIGJ5dGUgbGVuZ3RoIG1lc3NhZ2Us
IHdoaWNoIG90aGVyIGVuZOKAmXMgYXBwIGlnbm9yZXMuDQpUaGlzIGFwcHJvYWNoIGludm9sdmVz
IGJpdCBtb3JlIEFQSSB3b3JrIGZvciB3ZWJydGMgdG8gaGF2ZSBhIHZhcmlhdGlvbiBvZiBzZW5k
KGRhdGEsIG9vYkZsYWcpIGFuZCBuZXcgZGF0YSB0eXBlIGluIG9ubWVzc2FnZSgpLiBJTUhPLCB0
aGlzIGFwcHJvYWNoIGFsbG93cyBtb3JlIHBvc3NpYmlsaXRpZXMgaW4gZnV0dXJlIGFuZCBhbHNv
IHRoZSBzYW1lIGFwcHJvYWNoIGNhbiBiZSB1c2VkIGJ5IG90aGVyIFNDVFAgdXNlIGNhc2VzIG5v
dCBpbnZvbHZpbmcgd2VicnRjLg0KDQpCUg0KcmFqdQ0K

--_000_E1FE4C082A89A246A11D7F32A95A17828E4BCC13US70UWXCHMBA02z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh
IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8q
IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv
Tm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6
ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxp
bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi
bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5
cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7
DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28t
c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt
c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5
cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN
Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N
CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t
W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt
YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N
CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh
PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv
ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i
V29yZFNlY3Rpb24xIj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk
IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J
biB0aGUgZXhpc3RpbmcgZGF0YSBjaGFubmVsIHByb3RvY29sLCBpdCdzIG5vdCBwb3NzaWJsZSB0
byBzZW5kIHplcm8tbGVuZ3RoIG1lc3NhZ2VzLCBiZWNhdXNlIFNDVFAgcHJvaGliaXRzIGl0Ljxv
OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpbGUgdGhpcyBt
YXkgc2VlbSB0byBiZSBhbiBhY2FkZW1pYyBwb2ludCwgaXQgZG9lcyByZXByZXNlbnQgYSBkaXZl
cmdlbmNlIGZyb20gV2ViU29ja2V0cywgYW5kIHRoaXMgZGlmZmVyZW5jZSBjb3VsZCBiZSBtZWFu
aW5nZnVsIHRvIGFwcGxpY2F0aW9ucyB3aG8gdXNlIGVtcHR5IG1lc3NhZ2VzIGZvciBrZWVwYWxp
dmVzLiBPciBtYXliZSB0aGUgWW8gYXBwLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaW5jZSB3ZSBjYW4ndCBzZW5kIGEgemVyby1sZW5ndGgg
U0NUUCBtZXNzYWdlLCBJIHByb3Bvc2Ugd2UgYWRkIGEgUFBJRF9FTVBUWSB2YWx1ZSBvciBzb21l
dGhpbmcgc2ltaWxhciB0byBpbmRpY2F0ZSBhIG1lc3NhZ2Ugd2l0aCBlbXB0eSBjb250ZW50Ljxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltSYWp1XSBUaGVyZSBpcyBhIGdlbnVpbmUgbmVl
ZCBmb3IgdGhpcyBhbmQgdGhlIHByb3Bvc2FsIGlzIGdvb2QuDQo8bzpwPjwvbzpwPjwvc3Bhbj48
L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ib3dldmVyLCBJIGFtIHRoaW5raW5nIG9mIGFuIGFs
dGVybmF0ZSBwcm9wb3NhbCB0byBhY2hpZXZlIHRoZSBzYW1lIGJ1dCBpbiBhIGdlbmVyaWMgd2F5
Lg0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGVmaW5lIGEg
UFBJRF9PT0IgKG91dCBvZiBiYW5kKSBvciBzb21ldGhpbmcgc2ltaWxhci48bzpwPjwvbzpwPjwv
c3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcHBzIGNhbiB1c2UgdGhpcyB0byBzZW5k
IGEgbWVzc2FnZSBvZiBub24temVybyBsZW5ndGguIEZvciB0aGUg4oCcWW/igJ0ga2luZCBvZiBh
cHAgb3IgZW1wdHkgc3RyZWFtLWxldmVsIGhlYXJ0YmVhdCBwdXJwb3NlLCBhcHAgY2FuIHNlbmQg
YSAxIGJ5dGUgbGVuZ3RoDQogbWVzc2FnZSwgd2hpY2ggb3RoZXIgZW5k4oCZcyBhcHAgaWdub3Jl
cy48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi
PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIGFwcHJv
YWNoIGludm9sdmVzIGJpdCBtb3JlIEFQSSB3b3JrIGZvciB3ZWJydGMgdG8gaGF2ZSBhIHZhcmlh
dGlvbiBvZiBzZW5kKGRhdGEsIG9vYkZsYWcpIGFuZCBuZXcgZGF0YSB0eXBlIGluIG9ubWVzc2Fn
ZSgpLiBJTUhPLCB0aGlzIGFwcHJvYWNoIGFsbG93cw0KIG1vcmUgcG9zc2liaWxpdGllcyBpbiBm
dXR1cmUgYW5kIGFsc28gdGhlIHNhbWUgYXBwcm9hY2ggY2FuIGJlIHVzZWQgYnkgb3RoZXIgU0NU
UCB1c2UgY2FzZXMgbm90IGludm9sdmluZyB3ZWJydGMuPG86cD48L286cD48L3NwYW4+PC9pPjwv
Yj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+QlI8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5yYWp1PC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_E1FE4C082A89A246A11D7F32A95A17828E4BCC13US70UWXCHMBA02z_--


From nobody Wed Jul 23 05:18:47 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997021B279F for ; Wed, 23 Jul 2014 05:18:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Krn1cqwbF3bV for ; Wed, 23 Jul 2014 05:18:42 -0700 (PDT)
Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 05D6E1A0AC6 for ; Wed, 23 Jul 2014 05:18:42 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 6BCC923F0649 for ; Wed, 23 Jul 2014 14:18:41 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.120]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Wed, 23 Jul 2014 14:18:41 +0200
From: "Hutton, Andrew" 
To: "rtcweb@ietf.org" 
Thread-Topic: draft-hutton-httpbis-connect-protocol-00.txt
Thread-Index: AQHPkeGX5bnzJp6nL0GR/Q7sAjMPQputuW+g
Date: Wed, 23 Jul 2014 12:18:40 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17E301A3@MCHP04MSX.global-ad.net>
References: <9F33F40F6F2CD847824537F3C4E37DDF17E0CF6A@MCHP04MSX.global-ad.net>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17E0CF6A@MCHP04MSX.global-ad.net>
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: http://mailarchive.ietf.org/arch/msg/rtcweb/fUZjurr97-wKobZHI78pwuvEFps
Subject: Re: [rtcweb] draft-hutton-httpbis-connect-protocol-00.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 12:18:43 -0000

I presented this draft to HTTPBis yesterday and thought I should give rtcwe=
b an update on that discusson.

The draft proposes adding an indication in to HTTP Connect as to what proto=
col is used within the tunnel and specifically for use with WebRTC. Therefo=
re providing the HTTP Proxy an indication that the tunnel contains real-tim=
e media.

The feedback from the HTTP community was that there were no concerns about =
using the HTTP Connect within RTCWeb in this way and I hope this means we c=
an document the usage in -transports-.

There was no call to adopt the draft during the meeting and there is a need=
 to discuss in HTTPBis the exact naming of the header and what labels shoul=
d be used. I am hopeful that the draft will be adopted before too long and =
we can reference it in the -transports- draft.

Regards
Andy






> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Hutton,
> Andrew
> Sent: 27 June 2014 04:27
> To: rtcweb@ietf.org
> Subject: [rtcweb] draft-hutton-httpbis-connect-protocol-00.txt
>=20
>=20
> I just submitted this draft for which there is a short agenda slot in
> Toronto httpbis wg meeting.
>=20
> It was written as a result of our discussion during the recent rtcweb
> interim meeting in Washington DC.
>=20
> The draft proposes adding an indication in to HTTP Connect as to what
> protocol is used with the tunnel and specifically for use with WebRTC
> (I.e. TURN/ICE-TCP) so should be of interest to this group.
>=20
> Discussion should be on the HTTPBIS list.
>=20
> Regards
> Andy
>=20
>=20
>         Title           : HTTP Connect - Tunnel Protocol For WebRTC
>         Authors         : Andrew Hutton
>                           Justin Uberti
>                           Martin Thomson
> 	Filename        : draft-hutton-httpbis-connect-protocol-00.txt
> 	Pages           : 7
> 	Date            : 2014-06-27
>=20
> Abstract:
>    This document describes a mechanism to enable HTTP Clients to
> provide
>    an indication within a HTTP Connect request as to which protocol
> will
>    be used within the tunnel established to the Server identified by
> the
>    target resource.  The tunneled protocol is declared using the
> Tunnel-
>    Protocol HTTP Request header field.  Label usage relating to the use
>    of HTTP Connect by WebRTC clients (e.g. turn, webrtc) are described
>    in this document.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-hutton-httpbis-connect-protocol/
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-hutton-httpbis-connect-protocol-00
>=20
>=20
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From nobody Wed Jul 23 05:20:09 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D1B1B27D7 for ; Wed, 23 Jul 2014 05:20:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level: 
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NORMAL_HTTP_TO_IP=0.001, SPF_SOFTFAIL=0.665] autolearn=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 BB4AEUXSFaIB for ; Wed, 23 Jul 2014 05:20:05 -0700 (PDT)
Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCA51B27C3 for ; Wed, 23 Jul 2014 05:20:05 -0700 (PDT)
Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta12.westchester.pa.mail.comcast.net with comcast id VnqR1o0071HzFnQ5CoL5ig; Wed, 23 Jul 2014 12:20:05 +0000
Received: from dhcp-90b7.meeting.ietf.org ([31.133.144.183]) by omta14.westchester.pa.mail.comcast.net with comcast id VoHX1o00G3xdsjB3aoHZdc; Wed, 23 Jul 2014 12:18:03 +0000
Message-ID: <53CFA7DC.5060807@alum.mit.edu>
Date: Wed, 23 Jul 2014 08:17:32 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Kevin Dempsey , kiran.guduru@samsung.com
References:  
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1406118005; bh=I7frhRSnEbzA3Wt6CufPEQ54CFkwOX2aLsyuzseUjmI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Wcu/MK1V7QiHBZWvLsGzPtFNXw7NebuOyITIZcrc9rMmjrvOgrm/4WTP4fcLX0qjy 6hkV6x6j66Znb37EgfFHJbpdP8foSHUAi5F3fdJb4qC8A9g+ZsZdtIZJk0h7Bt+35q A5nUhUbCKVdIA2aqKEoHC4aCdlTC2n8Ddsxku8Zxch411RdjL4nOux6AtyzimZv9h4 rLDPgeavnlGWAC0bb77n30zC1mYCciRo23nIhdAw8SYzCKj4prPr5ID8yZ9BFb3ox/ IjeM0q5Jn/tJs7sWMu1BjVBgiujkmXLt4O4BjzRTi1b5c33sBMfIsAJJePGNOY7cKF sgILL6ic2DTLA==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vPlEg5BhosR0dyRqfTb4e9bgpNo
Cc: "rtcweb-request@ietf.org" , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 12:20:07 -0000

On 7/21/14 4:34 AM, Kevin Dempsey wrote:
> Would the browser be expected to act differently with "a=group:clue"? If
> not, then that is really part of the signalling and not part of the
> createXxx/setXxxDescription interface.
>
> The SDP passed to setXxxDescription and the SDP sent as part of the
> signalling (if SDP is used) do not need to be identical.

No, there is no need for the *browser* to act differently.

So yes, I suppose the app can manage the pair of SDPs used for SIP O/A 
separately from the SDPs that are passed through JSEP to control the 
browser. That will be annoying, and complicated, not so much for the 
first O/A but for subsequent ones.

	Thanks,
	Paul

> On 21 July 2014 03:35, Kiran Kumar Guduru  > wrote:
>
>     It seems there is a small mis-understanding here. I agree there is a
>     need for parsing and editing SDP by JS application for now.
>
>     I am not saying that constraints will do everything.
>
>     My intention is, to find the possibilities to extend the API of
>     existing RTCPeerConnection and proposed RTCRTPSender/Receiver to add
>     the attributes required by JS application.
>
>     For now, I proposed solution for one such kind of problem, i.e.,
>     prioritizing codecs.
>
>     setSdPAttribute (key, value) is just an example on top of my head,
>     which might solve this. But we can really figure out this after
>     getting the proposed API (RTCRTPSender/Receiver ) in draft.
>
>     Regards,
>
>     Kiran
>
>     ------- *Original Message* -------
>
>     *Sender* : Paul Kyzivat     >
>
>     *Date* : Jul 19, 2014 22:35 (GMT+09:00)
>
>     *Title* : Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
>
>     Kiran,
>
>
>     My need won't be satisfied by plausible constraints.
>     For instance, to interwork with CLUE it will be necessary to add an
>     "a=group:clue" and include in it those m-lines that are to be "clue
>     controlled". And that is needed in both offer and answer processing.
>
>     Thanks,
>     Paul
>
>
>     On 7/18/14 10:41 PM, Kiran Kumar Guduru wrote:
>      > Dear Paul,
>      >
>      > My comment is only regarding the comments on section 6 of the
>     JSEP draft.
>      >
>      > The sdp mangling described in section 6 may result in various error
>      > scenarios.
>      >
>      > In that section, it is described like most of the parameters can be
>      > modified thorugh constraints.
>      >
>      > The required modification, I found, which cannot not be done by the
>      > constraints is "Remove or reorder of codecs (m=)"
>      >
>      > In order to avoid the SDP mangling at Java Script application
>     level, I
>      > submitted a draft for changing the codec preferences
>      > http://tools.ietf.org/html/draft-guduru-rtcweb-codec-preferences-01.
>      > (Please review it).
>      >
>      > If this proposal is acceptable to the group, I hope we can remove
>      > section 6 from JSEP draft.
>      >
>      > (Expecting that we can find alternatives for adding extra attributes
>      > like CLUE as identified by you, for example by extending the
>      > proposed RTCRTPSender/Receiver by adding a generic
>     setSdPAttribute (key,
>      > value) method).
>      >
>      > Thanks,
>      >
>      > Kiran.
>      >
>      >
>      >
>      > -------Original Message--------
>      > Sent: Paul Kyzivat
>      > Date: Fri, 18 Jul 2014 14:32:24 -0400
>      > Subject: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
>      >
>      > I just did my first thorough read-through of JSEP in quite some
>     time. I
>      > came away with a number of concerns:
>      >
>      > Section 1.1:
>      >
>      > When describing offers, modification by the application is mentioned:
>      >
>      >      JSEP's handling of session descriptions is simple and
>      >      straightforward.  Whenever an offer/answer exchange is
>     needed, the
>      >      initiating side creates an offer by calling a createOffer()
>     API.  The
>      >      application *optionally modifies that offer*, and then uses
>     it to set
>      >      up its local config via the setLocalDescription() API.
>      >
>      > but when describing answers it is not:
>      >
>      >      When the call is accepted, the callee uses the
>     createAnswer() API to
>      >      generate an appropriate answer, applies it using
>      >      setLocalDescription(), and sends the answer back to the
>     initiator
>      >      over the signaling channel.  When the offerer gets that
>     answer, it
>      >      installs it using setRemoteDescription(), and initial setup is
>      >      complete.
>      >
>      > And Section 6 only talks about changing offers, not answers. It is
>      > equally important to be able to modify answers. (More on this in
>     later
>      > comment on section 6.)
>      >
>      > Section 4.1.4:
>      >
>      >      The only difference between a provisional and final answer
>     is that
>      >      the final answer results in the freeing of any unused
>     resources that
>      >      were allocated as a result of the offer.  As such, the
>     application
>      >      can use some discretion on whether an answer should be
>     applied as
>      >      provisional or final, and can change the type of the session
>      >      description as needed.  For example, in a serial forking
>     scenario, an
>      >      application may receive multiple "final" answers, one from each
>      >      remote endpoint.  The application could choose to accept the
>     initial
>      >      answers as provisional answers, and only apply an answer as
>     final
>      >      when it receives one that meets its criteria (e.g. a live user
>      >      instead of voicemail).
>      >
>      > Issue: in this forking case, until the final selection is made it is
>      > unclear which one will need ICE completed. Only when a setlocal
>     is done
>      > on one of the answers will ICE begin to be performed. Then, if
>     another
>      > answer is provisionally set, won't that stop ICE for the prior
>     one? And
>      > won't it require new candidates? What if one of the earlier ones is
>      > eventually chosen as final?
>      >
>      > And what if ICE completes for one of the candidates? Can't media
>     start
>      > to flow? Then what if a different candidate is set as the final
>     answer?
>      >
>      > Section 4.1.4.1 :
>      >
>      > I question the following:
>      >
>      >      ...  While it is good practice to send an immediate
>      >      response to an "offer", in order to warm up the session
>     transport and
>      >      prevent media clipping, the preferred handling for a web
>     application
>      >      would be to create and send an "inactive" final answer
>     immediately
>      >      after receiving the offer.  Later, when the called user actually
>      >      accepts the call, the application can create a new
>     "sendrecv" offer
>      >      to update the previous offer/answer pair and start the media
>     flow.
>      >
>      > This is very unfriendly when receiving calls that might be forked. By
>      > immediately "answering" a call before knowing if the user will accept
>      > it, you preempt the possibility that it will be answered on some
>     other fork.
>      >
>      > For instance, if a call could come to your browser, or be sent to an
>      > answering service, and your broswer is on but you aren't present to
>      > accept the call, then the call will be accepted and then dropped
>     rather
>      > than sent to the answering machine.
>      >
>      > So this technique should not be used if there is any possibility that
>      > the request could be coming from a source that might try other
>      > possibilities.
>      >
>      > Section 5.2.1:
>      >
>      >      When createOffer is called for the first time, the result is
>     known as
>      >      the initial offer.
>      >
>      > By this definition, if a peer connection initially *received* an
>     offer
>      > and sent an answer, and then it later sends an offer then that offer
>      > would be considered an initial offer.
>      >
>      > I think perhaps what is intended is:
>      >
>      >      When createOffer is called before setLocal has been called with
>      >      an offer,  the result is known as the initial offer.
>      >
>      > The following doesn't support the "balanced" BUNDLE policy:
>      >
>      >      Once all m= sections have been generated, a session-level
>     "a=group"
>      >      attribute MUST be added as specified in [RFC5888].  This
>     attribute
>      >      MUST have semantics "BUNDLE", and MUST include the mid
>     identifiers of
>      >      each m= section.  The effect of this is that the browser
>     offers all
>      >      m= sections as one BUNDLE group.  However, whether the m=
>     sections
>      >      are bundle-only or not depends on the BUNDLE policy.
>      >
>      > Section 5.2.2 says:
>      >
>      >      o  If any MediaStreamTracks have been added, and there exist
>     recvonly
>      >         m= sections of the appropriate media type with no associated
>      >         MediaStreamTracks, or rejected m= sections of any media type,
>      >         those m= sections MUST be recycled, and a local
>     MediaStreamTrack
>      >         associated with these recycled m= sections until all such
>     existing
>      >         m= sections have been used.  This includes any recvonly or
>      >         rejected m= sections created by the preceding paragraph.
>      >
>      > This fails to say anything about codec compatibility. SDP O/A
>     requires
>      > the answer to be a subset of the offer in terms of PT/codec
>      > configuration. You should not use the same m-line unless there is a
>      > desire to use the same settings for the new track as are currently in
>      > use in the other direction.
>      >
>      > Section 5.3.1:
>      >
>      >      When createAnswer is called for the first time after a remote
>      >      description has been provided, the result is known as the
>     initial
>      >      answer.
>      >
>      > By this definition, if a peer connection initially sent an offer and
>      > received an answer, and then it later receives an offer then the
>     answer
>      > to that first *received* offer would be considered an Initial Answer.
>      >
>      > I think perhaps what is intended is:
>      >
>      >      When createAnswer is called before setLocal has been called with
>      >      an offer,  the result is known as the initial answer.
>      >
>      > When specifying the mapping of local tracks to m-lines in a received
>      > offer, there is again no discussion of codec compatibility. It is
>     quite
>      > possible that the m-line chosen by the algorithm in this section
>     won't
>      > have compatible codec attributes, but some other m-line will.
>      >
>      > Sections 5.3.2, 5.3.3, and 5.4-5.7:
>      >
>      > Are these empty because the content is yet to be written?
>      >
>      > Section 6:
>      >
>      > Other likely changes are addition of extra attributes and maybe other
>      > parameters. For instance, CLUE will want to add another grouping
>     construct.
>      >
>      > Thanks,
>      > Paul
>      >
>      >
>
>
>     _______________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org 
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>


From nobody Wed Jul 23 05:20:46 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB581B27BF for ; Wed, 23 Jul 2014 05:20:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCpHZIKjPT-F for ; Wed, 23 Jul 2014 05:20:31 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7FB1A0AC6 for ; Wed, 23 Jul 2014 05:20:30 -0700 (PDT)
Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s6NCKQN4013091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jul 2014 07:20:27 -0500 (CDT)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s6NCKMps004312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 08:20:25 -0400
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Wed, 23 Jul 2014 08:20:24 -0400
From: "Makaraju, Maridi Raju (Raju)" 
To: "kiran.guduru@samsung.com" , Justin Uberti , franklin blek 
Thread-Topic: RE: [rtcweb] New Version Notification for draft-guduru-rtcweb-codec-preferences-01.txt
Thread-Index: AQHPpVwbpCorMbkhSEqJINbpedkhGJutkIog
Date: Wed, 23 Jul 2014 12:20:23 +0000
Deferred-Delivery: Wed, 23 Jul 2014 12:20:00 +0000
Message-ID: 
References: <0A.F9.03708.848DDC35@epcpsbgx1.samsung.com>
In-Reply-To: <0A.F9.03708.848DDC35@epcpsbgx1.samsung.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.18]
Content-Type: multipart/related; boundary="_004_E1FE4C082A89A246A11D7F32A95A17828E4BCD90US70UWXCHMBA02z_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/koUxcyNWzxAUyt7YmJ2AEjSUTNY
Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" 
Subject: Re: [rtcweb] New Version Notification for draft-guduru-rtcweb-codec-preferences-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 12:20:35 -0000

--_004_E1FE4C082A89A246A11D7F32A95A17828E4BCD90US70UWXCHMBA02z_
Content-Type: multipart/alternative;
	boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E4BCD90US70UWXCHMBA02z_"

--_000_E1FE4C082A89A246A11D7F32A95A17828E4BCD90US70UWXCHMBA02z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

S2lyYW4sDQpQbGVhc2Ugc2VlIG15IGlubGluZSBjb21tZW50cyBtYXJrZWQgYmV0d2VlbiA8UmFq
dTI+IGFuZCA8L1JhanUyPi4NCg0KDQo+VGhpcyBzZWVtcyBsaWtlIGEgcHJldHR5IGJpZyBoYW1t
ZXIgdG8gc29sdmUgYSBmYWlybHkgc21hbGwgcHJvYmxlbS4gVGhpcyBwcm9wb3NhbCBhZGRzIDYg
bmV3IEFQSSBwb2ludHMgZm9yIHRoZSBwdXJwb3NlIG9mID5jaGFuZ2luZyB0aGUgb3JkZXIgb2Yg
Y29kZWNzIGluIGNyZWF0ZU9mZmVyLCB3aGljaCBzZWVtcyBsaWtlIGEgaGlnaCBjb3N0LWJlbmVm
aXQgcmF0aW8uIEFuZCB3aGlsZSB0aGUgdXNlIGNhc2VzIGxpc3RlZCBoZXJlIGFyZSA+aGVscGZ1
bCwgdGhleSBzZWVtIHNvbWV3aGF0IGNvbnRyaXZlZCB0byBtZSwgc2luY2UgaXQgc2VlbXMgdW5s
aWtlbHkgdGhhdCB0aGUgYXBwbGljYXRpb24gY2FuIG1ha2UgYmV0dGVyIGNob2ljZXMgYWJvdXQg
PmJhbmR3aWR0aCA+b3IgcG93ZXIgY29uc3VtcHRpb24gdGhhbiB0aGUgYnJvd3Nlci4NCg0KDQoN
CltSYWp1XSBQZXIgbXkgdW5kZXJzdGFuZGluZywgdGhlIG1haW4gb2JqZWN0IG9mIHRoaXMgZHJh
ZnQgY2FuIGJlIGFjaGlldmVkIHdpdGggbm8gYWRkaXRpb25hbCBBUElzIGFuZCB3aXRoIGp1c3Qg
dGhlIHByb3Bvc2VkIGludHJvZHVjdGlvbiBvZiBwcmVmZXJyZWRBdWRpb0NvZGVjcyBhbmQgcHJl
ZmVycmVkVmlkZW9Db2RlY3Mgb3B0aW9ucyB0byBSVENPZmZlckFuc3dlck9wdGlvbnMgY29uc3Ry
YWludCBvZiBjcmVhdGVPZmZlcigpL2NyZWF0ZUFuc3dlcigpLg0KDQpTbywgSU1PIEkgZG9u4oCZ
dCB0aGluayBnZXRDb2RlY1ByZWZlcmVuY2VzKCkvc2V0Q29kZWNQcmVmZXJlbmNlcygpIGFkZCBt
dWNoIHZhbHVlLCBzbyBjYW4gYmUgZGVsYXllZCBvciBkcm9wcGVkLg0KDQoNCg0KVGhlIG5lZWQg
Zm9yIGdldFN1cHBvcnRlZEF1ZGlvQ29kZWNzKCkvZ2V0U3VwcG9ydGVkVmlkZW9Db2RlY3MoKSBp
biAxLjAgY2FuIGJlIHF1ZXN0aW9uYWJsZSBhcyB0aGUgYXBwbGljYXRpb24gY2FuIHNwZWNpZnkg
Y29kZWNzIG9yZGVyIHBlciBrbm93biBjb2RlY3MgKG9yIGdldCB0aGUgbGlzdCB2aWEgYSBkdW1t
eSBjcmVhdGVPZmZlcigpIGNhbGwpLg0KDQogW0tJUkFOXSBOZXcgQVBJIGlzIGFkZGVkIGZvciB0
aGlzIG9ubHkgYmVjYXVzZSwgaXQgY2FuIGJlIGNhbGxlZCBvbiBQZWVyY29ubmVjdGlvbiBpcnJl
c3BlY3RpdmUgb2YgaXRzIHN0YXRlIGFuZCB0aGUgb3JkZXIgb2YgcGFyc2luZyBpcyBhbHNvIGVh
c3kgd2hlbiBjb21wYXJlZCB0byBwYXJzaW5nIG9mIHdob2xlIFNEUCByZXR1cm5lZCB0aHJvdWdo
IGNyZWF0ZU9mZmVyL0Fuc3dlci4NCg0KPFJhanUyPiBJIGFncmVlIHRoYXQgaXQgaXMgZWFzeS4g
QnV0LCBJIGFsc28gYWdyZWUgd2l0aCB0aGF0IEp1c3RpbiB0aGF0IGdpdmVuIG90aGVyIG11c3Qg
aGF2ZSB3b3JrIHRoaXMgbWF5IGJlIGxvd2VyIHByaW9yaXR5OyB0aGVzZSBzbWFsbCB0aGluZ3Mg
ZG8gYWRkIHVwIHRvIGRlbGF5IHdlYnJ0YyAxLjAgZGVsaXZlcnkuDQoNCjwvUmFqdTI+DQoNCg0K
DQpUaGUgZHJhZnQgdGFsa3MgYWJvdXQgZnVsZmlsbGluZyBBNSBpbiBbSS1ELmlldGYtcnRjd2Vi
LXVzZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRzXSwgYnV0IEkgZG8gbm90IHNlZSBhbnkgZXhwbGlj
aXQgbWVudGlvbiBvZiBob3cgY29kZWNzIGNhbiBiZSByZW1vdmVkPyBwcmVmZXJyZWRBdWRpby9W
aWRlb0NvZGVjcyBjb25zdHJhaW50IG9ubHkgc3BlY2lmaWVzIHRoZSBvcmRlciBvZiBwcmVmZXJl
bmNlLiBEb27igJl0IHlvdSBuZWVkIGFub3RoZXIgY29uc3RyYWludCB0byBleGNsdWRlIHNwZWNp
ZmllZCBjb2RlY3M/IEl04oCZcyBwcm9iYWJseSBhIGJhZCBkZXNpZ24gdG8gaGF2ZSBjb2RlY3Mg
bm90IGluIHRoZSBwcmVmZXJyZWQgbGlzdCBiZSByZW1vdmVkIGF1dG9tYXRpY2FsbHkuDQoNCg0K
DQogW0tJUkFOXSBUaGUgcmVtb3ZhbCBvZiBjb2RlY3MgaXMgZXhwbGFpbmVkIGluIHNlY3Rpb24g
Ni4NCg0KICAiVGhlIG9mZmVyIC8gYW5zd2VyDQoNCiAgIFNIT1VMRCBOT1QgY29udGFpbiBhdWRp
byBjb2RlY3Mgb3RoZXIgdGhhbiB0aG9zZSBzcGVjaWZpZWQgYnkNCg0KICAgSmF2YVNjcmlwdCBh
cHBsaWNhdGlvbiBhbmQgdGhlIG9yZGVyIG9mIHByZWZlcmVuY2UgU0hPVUxEIGJlIHdpdGgNCg0K
ICAgaGlnaCBwcmlvcml0eSBmb3IgdGhlIGNvZGVjcyBmaXJzdCBpbiB0aGUgc2VxdWVuY2UuIg0K
DQoNCg0KUGVyaGFwcyB0aGlzIGlzIGluIGluZGlyZWN0IHdheS4gSSB3aWxsIG1vZGlmeSB0aGUg
c3RhdGVtZW50IHRvIGRpcmVjdGx5IHBvaW50IHRoaXMuIEkgZG9uJ3Qgd2FudCB0byBpbmNyZWFz
ZSB0aGUgY29uc3RyYWludHMganVzdCBmb3IgcmVtb3ZhbCwgd2hpY2ggY2FuIGJlIGFjaGlldmVk
IHdpdGggdGhpcyBjb25zdHJhaW50LiBTbyBJIGZvbGxvd2VkIHRoaXMgZGVzaWduLg0KDQo8UmFq
dTI+IFNvcnJ5IEkgbWlzc2VkIHRoYXQuIEJ1dCwgdGhlIG5hbWUg4oCccHJlZmVycmVkQ29kZWNz
4oCdIGRvZXMgbm90IGNvbnZleSB0aGUg4oCccmVtb3ZhbOKAnSBwYXJ0IGNsZWFybHkgYXMgcHJl
ZmVyZW5jZSBnZW5lcmFsbHkgaW5kaWNhdGVzIHJlb3JkZXJpbmcgcHJpb3JpdHksIGJ1dCBub3Qg
cmVtb3ZhbC4gU3VjaCBzZW1hbnRpY3MgbWF5IHB1dCBhZGRpdGlvbmFsIGJ1cmRlbiBvbiBhcHAg
dG8gbGlzdCBhbGwgdGhlIGNvZGVjcyBpbiBwcmVmZXJyZWRDb2RlY3MgbGlzdCB3aGVyZSBhcyB1
c2VyIG1heSBqdXN0IHByZWZlciBhIHBhcnRpY3VsYXIgY29kZWMgdG8gYmUgdGhlIDFzdCBvbmUg
YW5kIGRvZXMgbm90IGNhcmUgYWJvdXQgb3RoZXIgY29kZWNzIG9yZGVyLCBzbyB0aGV5IGNhbiBr
ZWVwIHRoZWlyIHJlbGF0aXZlIG9yZGVyIGJ1dCB0aGV5IGFyZSBuZWVkZWQgaW4gdGhlIGxpc3Qu
IElNTywgcmVtb3ZhbCBvZiBjb2RlY3MgcmVxdWlyZXMgYW5vdGhlciBzZXBhcmF0ZSBjb25zdHJh
aW50IGFuZCBub3QgYmUgbWl4ZWQgd2l0aCBwcmVmZXJyZWRDb2RlY3MgY29uc3RyYWludC4gSSBh
bSBub3Qgd2VkZGVkIHRvIGhhdmluZyBzZXBhcmF0ZSBjb25zdHJhaW50IGZvciByZW1vdmFsIHRo
b3VnaCwgYnV0IEkgc2VlayBpbnB1dCBmcm9tIG90aGVyIG1lbWJlcnMuDQoNCg0KDQo8L1JhanUy
Pg0KDQoNCg0KQlINCg0KUmFqdQ0KDQoNCg0KDQoNCkJSDQoNClJhanUNCg0KDQoNCg0KDQoNCg0K
DQoNCltjaWQ6aW1hZ2UwMDEuZ2lmQDAxQ0ZBNjQzLkNGREI3NzQwXQ0KDQpbaHR0cDovL2V4dC5z
YW1zdW5nLm5ldC9tYWlsY2hlY2svU2VlblRpbWVDaGVja2VyP2RvPWY0ZmI3MGJhOGI3MmM5ZWM1
NGY0NTVjZmU1MjIwMDVkM2VmOTg4YWEyZGFhYTMyZDUyY2NhYWE1ZTc4ZDc5MTdkZTZlZWUyYmU4
NzRlMDUyM2VjZDMxNDZiYTFlZGIzZWY0YmNkZWNlZDQ2ZWQ1ZWUwOGNlY2U4NTQxYmMxNGVhY2Y4
NzhmOWEyNmNlMTVhMF0NCg==

--_000_E1FE4C082A89A246A11D7F32A95A17828E4BCD90US70UWXCHMBA02z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYgIW1zb10+
PHN0eWxlIGlkPSJteXNpbmdsZV9zdHlsZSI+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZN
TCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6
dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9
DQo8L3N0eWxlPjwhW2VuZGlmXS0tPg0KPHRpdGxlPlNhbXN1bmcgRW50ZXJwcmlzZSBQb3J0YWwg
bXlTaW5nbGU8L3RpdGxlPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm
b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUg
MyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu
b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpD
b25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp
bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJbXNvLWJlbGlldmUtbm9y
bWFsLWxlZnQ6eWVzO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1hcmdpbi10b3A6My43NXB0Ow0KCW1hcmdpbi1yaWdo
dDowaW47DQoJbWFyZ2luLWJvdHRvbTozLjc1cHQ7DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt
c2l6ZTo5LjBwdDsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjt9DQpwcmUNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl
ZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9y
bWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl
ZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0
eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl
cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl
OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ
e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk
aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCFbaWYg
bXNvIDldPjxzdHlsZT5wLk1zb05vcm1hbA0KCXttYXJnaW4tbGVmdDo3LjVwdDt9DQo8L3N0eWxl
PjwhW2VuZGlmXT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl
eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0
ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6
ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t
Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi
IHN0eWxlPSJtYXJnaW4tbGVmdDo3LjVwdDttYXJnaW4tdG9wOjcuNXB0O21hcmdpbi1yaWdodDo3
LjVwdDttYXJnaW4tYm90dG9tOjcuNXB0Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+S2lyYW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBsZWFzZSBzZWUgbXkg
aW5saW5lIGNvbW1lbnRzIG1hcmtlZCBiZXR3ZWVuICZsdDtSYWp1MiZndDsgYW5kICZsdDsvUmFq
dTImZ3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0
b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7VGhpcyBzZWVtcyBsaWtl
IGEgcHJldHR5IGJpZyBoYW1tZXIgdG8gc29sdmUgYSBmYWlybHkgc21hbGwgcHJvYmxlbS4gVGhp
cyBwcm9wb3NhbCBhZGRzIDYgbmV3IEFQSSBwb2ludHMgZm9yIHRoZSBwdXJwb3NlIG9mICZndDtj
aGFuZ2luZw0KIHRoZSBvcmRlciBvZiBjb2RlY3MgaW4gY3JlYXRlT2ZmZXIsIHdoaWNoIHNlZW1z
IGxpa2UgYSBoaWdoIGNvc3QtYmVuZWZpdCByYXRpby4gQW5kIHdoaWxlIHRoZSB1c2UgY2FzZXMg
bGlzdGVkIGhlcmUgYXJlICZndDtoZWxwZnVsLCB0aGV5IHNlZW0gc29tZXdoYXQgY29udHJpdmVk
IHRvIG1lLCBzaW5jZSBpdCBzZWVtcyB1bmxpa2VseSB0aGF0IHRoZSBhcHBsaWNhdGlvbiBjYW4g
bWFrZSBiZXR0ZXIgY2hvaWNlcyBhYm91dCAmZ3Q7YmFuZHdpZHRoICZndDtvcg0KIHBvd2VyIGNv
bnN1bXB0aW9uIHRoYW4gdGhlIGJyb3dzZXIuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5bUmFqdV0gUGVyIG15IHVuZGVyc3RhbmRp
bmcsIHRoZSBtYWluIG9iamVjdCBvZiB0aGlzIGRyYWZ0IGNhbiBiZSBhY2hpZXZlZCB3aXRoIG5v
IGFkZGl0aW9uYWwgQVBJcyBhbmQgd2l0aCBqdXN0IHRoZSBwcm9wb3NlZCBpbnRyb2R1Y3Rpb24g
b2YgcHJlZmVycmVkQXVkaW9Db2RlY3MgYW5kIHByZWZlcnJlZFZpZGVvQ29kZWNzIG9wdGlvbnMg
dG8gUlRDT2ZmZXJBbnN3ZXJPcHRpb25zIGNvbnN0cmFpbnQgb2YgY3JlYXRlT2ZmZXIoKS9jcmVh
dGVBbnN3ZXIoKS4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+U28sIElNTyBJIGRvbuKAmXQgdGhpbmsgZ2V0Q29kZWNQcmVmZXJlbmNlcygp
L3NldENvZGVjUHJlZmVyZW5jZXMoKSBhZGQgbXVjaCB2YWx1ZSwgc28gY2FuIGJlIGRlbGF5ZWQg
b3IgZHJvcHBlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij5UaGUgbmVlZCBmb3IgZ2V0U3VwcG9ydGVkQXVkaW9Db2RlY3MoKS9n
ZXRTdXBwb3J0ZWRWaWRlb0NvZGVjcygpIGluIDEuMCBjYW4gYmUgcXVlc3Rpb25hYmxlIGFzIHRo
ZSBhcHBsaWNhdGlvbiBjYW4gc3BlY2lmeSBjb2RlY3Mgb3JkZXIgcGVyIGtub3duIGNvZGVjcyAo
b3IgZ2V0IHRoZSBsaXN0IHZpYSBhIGR1bW15IGNyZWF0ZU9mZmVyKCkgY2FsbCkuIDxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwO1tL
SVJBTl0gTmV3IEFQSSBpcyBhZGRlZCBmb3IgdGhpcyBvbmx5IGJlY2F1c2UsIGl0IGNhbiBiZSBj
YWxsZWQgb24gUGVlcmNvbm5lY3Rpb24gaXJyZXNwZWN0aXZlIG9mIGl0cyBzdGF0ZSBhbmQgdGhl
IG9yZGVyIG9mIHBhcnNpbmcgaXMgYWxzbyBlYXN5IHdoZW4gY29tcGFyZWQgdG8gcGFyc2luZyBv
ZiB3aG9sZSBTRFAgcmV0dXJuZWQgdGhyb3VnaCBjcmVhdGVPZmZlci9BbnN3ZXIuPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj4mbHQ7UmFqdTImZ3Q7IEkgYWdyZWUgdGhhdCBpdCBpcyBlYXN5LiBCdXQs
IEkgYWxzbyBhZ3JlZSB3aXRoIHRoYXQgSnVzdGluIHRoYXQgZ2l2ZW4gb3RoZXIgbXVzdCBoYXZl
IHdvcmsgdGhpcyBtYXkgYmUgbG93ZXIgcHJpb3JpdHk7IHRoZXNlIHNtYWxsIHRoaW5ncyBkbyBh
ZGQgdXAgdG8gZGVsYXkgd2VicnRjIDEuMCBkZWxpdmVyeS48bzpwPjwvbzpwPjwvc3Bhbj48L2k+
PC9iPjwvcHJlPg0KPHByZT48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+Jmx0Oy9SYWp1MiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcHJlPg0K
PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhl
IGRyYWZ0IHRhbGtzIGFib3V0IGZ1bGZpbGxpbmcgQTUgaW4gW0ktRC5pZXRmLXJ0Y3dlYi11c2Ut
Y2FzZXMtYW5kLXJlcXVpcmVtZW50c10sIGJ1dCBJIGRvIG5vdCBzZWUgYW55IGV4cGxpY2l0IG1l
bnRpb24gb2YgaG93IGNvZGVjcyBjYW4gYmUgcmVtb3ZlZD8gcHJlZmVycmVkQXVkaW8vVmlkZW9D
b2RlY3MgY29uc3RyYWludCBvbmx5IHNwZWNpZmllcyB0aGUgb3JkZXIgb2YgcHJlZmVyZW5jZS4g
RG9u4oCZdCB5b3UgbmVlZCBhbm90aGVyIGNvbnN0cmFpbnQgdG8gZXhjbHVkZSBzcGVjaWZpZWQg
Y29kZWNzPyBJdOKAmXMgcHJvYmFibHkgYSBiYWQgZGVzaWduIHRvIGhhdmUgY29kZWNzIG5vdCBp
biB0aGUgcHJlZmVycmVkIGxpc3QgYmUgcmVtb3ZlZCBhdXRvbWF0aWNhbGx5LjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBbS0lS
QU5dIFRoZSByZW1vdmFsIG9mIGNvZGVjcyBpcyBleHBsYWluZWQgaW4gc2VjdGlvbiA2LiA8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJz
cDsmbmJzcDsmcXVvdDs8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZSBvZmZlciAvIGFuc3dlcjxvOnA+PC9vOnA+
PC9zcGFuPjwvZW0+PC9zcGFuPjwvcHJlPg0KPHByZT48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij4mbmJzcDsmbmJzcDsgU0hPVUxEIE5PVCBjb250YWluIGF1ZGlvIGNvZGVjcyBvdGhlciB0
aGFuIHRob3NlIHNwZWNpZmllZCBieTxvOnA+PC9vOnA+PC9zcGFuPjwvZW0+PC9wcmU+DQo8cHJl
PjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyBKYXZhU2NyaXB0IGFw
cGxpY2F0aW9uIGFuZCB0aGUgb3JkZXIgb2YgcHJlZmVyZW5jZSBTSE9VTEQgYmUgd2l0aDxvOnA+
PC9vOnA+PC9zcGFuPjwvZW0+PC9wcmU+DQo8cHJlPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPiZuYnNwOyZuYnNwOyBoaWdoIHByaW9yaXR5IGZvciB0aGUgY29kZWNzIGZpcnN0IGluIHRo
ZSBzZXF1ZW5jZS4mcXVvdDs8L3NwYW4+PC9lbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3
YXlzOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsYWNrIj4gPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXM7LXdlYmtpdC10ZXh0
LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjpibGFjayI+UGVyaGFwcyB0aGlzIGlzIGluIGluZGlyZWN0IHdheS4gSSB3aWxs
IG1vZGlmeSB0aGUgc3RhdGVtZW50IHRvIGRpcmVjdGx5IHBvaW50IHRoaXMuIEkgZG9uJ3Qgd2Fu
dCB0byBpbmNyZWFzZSB0aGUgY29uc3RyYWludHMganVzdCBmb3IgcmVtb3ZhbCwgd2hpY2ggY2Fu
IGJlIGFjaGlldmVkIHdpdGggdGhpcyBjb25zdHJhaW50LiBTbyBJIGZvbGxvd2VkIHRoaXMgZGVz
aWduLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZv
cmU6YWx3YXlzIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+Jmx0O1JhanUyJmd0OyBTb3JyeSBJIG1pc3NlZCB0aGF0LiBCdXQsIHRoZSBuYW1lIOKAnHBy
ZWZlcnJlZENvZGVjc+KAnSBkb2VzIG5vdCBjb252ZXkgdGhlIOKAnHJlbW92YWzigJ0gcGFydCBj
bGVhcmx5IGFzIHByZWZlcmVuY2UgZ2VuZXJhbGx5IGluZGljYXRlcyByZW9yZGVyaW5nIHByaW9y
aXR5LCBidXQgbm90IHJlbW92YWwuIFN1Y2ggc2VtYW50aWNzIG1heSBwdXQgYWRkaXRpb25hbCBi
dXJkZW4gb24gYXBwIHRvIGxpc3QgYWxsIHRoZSBjb2RlY3MgaW4gcHJlZmVycmVkQ29kZWNzIGxp
c3Qgd2hlcmUgYXMgdXNlciBtYXkganVzdCBwcmVmZXIgYSBwYXJ0aWN1bGFyIGNvZGVjIHRvIGJl
IHRoZSAxPHN1cD5zdDwvc3VwPiBvbmUgYW5kIGRvZXMgbm90IGNhcmUgYWJvdXQgb3RoZXIgY29k
ZWNzIG9yZGVyLCBzbyB0aGV5IGNhbiBrZWVwIHRoZWlyIHJlbGF0aXZlIG9yZGVyIGJ1dCB0aGV5
IGFyZSBuZWVkZWQgaW4gdGhlIGxpc3QuIElNTywgcmVtb3ZhbCBvZiBjb2RlY3MgcmVxdWlyZXMg
YW5vdGhlciBzZXBhcmF0ZSBjb25zdHJhaW50IGFuZCBub3QgYmUgbWl4ZWQgd2l0aCBwcmVmZXJy
ZWRDb2RlY3MgY29uc3RyYWludC4gSSBhbSBub3Qgd2VkZGVkIHRvIGhhdmluZyBzZXBhcmF0ZSBj
b25zdHJhaW50IGZvciByZW1vdmFsIHRob3VnaCwgYnV0IEkgc2VlayBpbnB1dCBmcm9tIG90aGVy
IG1lbWJlcnMuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3ByZT4NCjxwcmUgc3R5bGU9InBh
Z2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wcmU+DQo8
cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxiPjxpPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7L1JhanUyJmd0OzxvOnA+PC9vOnA+PC9z
cGFuPjwvaT48L2I+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi
PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1i
ZWZvcmU6YWx3YXlzIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+QlI8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcHJlPg0KPHByZSBzdHlsZT0icGFn
ZS1icmVhay1iZWZvcmU6YWx3YXlzIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+UmFqdTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wcmU+DQo8cHJl
IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9i
PjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QlI8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SYWp1PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxl
IiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBpZD0iY29uZmlkZW50aWFsc2lnbmltZyI+DQo8
dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQi
Pg0KPHA+PGltZyBpZD0iX3gwMDAwX2kxMDMzIiBzcmM9ImNpZDppbWFnZTAwMS5naWZAMDFDRkE2
NDMuQ0ZEQjc3NDAiPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90
YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0
b206LjAwMDFwdCI+PGltZyBpZD0iX3gwMDAwX2kxMDM0IiBzcmM9Imh0dHA6Ly9leHQuc2Ftc3Vu
Zy5uZXQvbWFpbGNoZWNrL1NlZW5UaW1lQ2hlY2tlcj9kbz1mNGZiNzBiYThiNzJjOWVjNTRmNDU1
Y2ZlNTIyMDA1ZDNlZjk4OGFhMmRhYWEzMmQ1MmNjYWFhNWU3OGQ3OTE3ZGU2ZWVlMmJlODc0ZTA1
MjNlY2QzMTQ2YmExZWRiM2VmNGJjZGVjZWQ0NmVkNWVlMDhjZWNlODU0MWJjMTRlYWNmODc4Zjlh
MjZjZTE1YTAiPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_E1FE4C082A89A246A11D7F32A95A17828E4BCD90US70UWXCHMBA02z_--

--_004_E1FE4C082A89A246A11D7F32A95A17828E4BCD90US70UWXCHMBA02z_
Content-Type: image/gif; name="image001.gif"
Content-Description: image001.gif
Content-Disposition: inline; filename="image001.gif"; size=13168;
	creation-date="Wed, 23 Jul 2014 12:20:19 GMT";
	modification-date="Wed, 23 Jul 2014 12:20:19 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

R0lGODlhCAKQAMQAAAAAAP///8k6OspMTNRiYtt0dOSOjumiovLExPfZ2fvt7f/+/uvr69TU1Lm5
uYyMjG9vb0dHRzMzMyoqKgICAv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEA
ABUALAAAAAAIApAAAAX/ICOOZGmeaKqubOu+cCzPdG3feK7vfO//uYBwSCwaj8ikcslsOp/QqHRK
rVqv2Kx2y+16v1YReEwum8/otHrNbhcX8Lh8Tq/b73al2M3v+/+AgYKDVniGh4h1egyEjY6PkJGS
k0OJlpd5SXsBDQ6engwNjFKilHoNSaVYqkisTK5CoUqdo02waLJMubGogg6Nt1S/a3IIeAoJmHAJ
CnTIipq1EBETFBERDRHDUdqmSQ8PSd1GENzbR+NN6UPgqRPYr+Hrae1MDhFE94MUfA3hRvOKlHPC
z8xAIXIG4EFQAJGBOQWMzWEIDckmIfqEBFR3zhuWgk82DhGJrmOAekcy/zJpR5IMSiUqA8T8A5LN
yyc1l+QEU9MSxUMKD/2cs6iIyggQKExAxSCCtVoBmlKgIC/pBEZSIzBw8I/ryWr/hDSYRjUpvq9U
ozpdGiBp2rZTyzUAO9BqLyHt3IZt22Cs03Jm0YbzS2HgA2sTfj0AixfxNqlsszLqtjgtuAfDMA+p
BlgpqgdJh82d8ACpZ7VPiUA4HNlp2tVKHVT7NbewWKUR9kpNy4Azvt6F8SGdIBg1W71C7CY/rTru
ycr/kiYlAm620+hxm4o9K5ax5Las+04gvTschL5kD8LFBmFCZ9twp8NlO6S21uJfE7dNygD6+kpx
NGTAAQMQkIwCBAxggP+AySTw0AEJPmTAAAU4SIABBiQDIYUKDCVHUflwd81JgJWomlz8UMMABCay
OFdyDzBAgXh3OTBjA1T1JsqNS5VG4lxbEVeaCEut1hQ+i/VHHDsPACkbEdrYuGNfFDggI41SXnml
jVbyiGWV7CDZYjnaXDmXP+CcNWOY/ly12En3xeLiiKDtZ+dISOLDIicpCucmPuTlFkBiMu61J47g
HZnoiFWK4KWPoDkppJuTKkmdVjomieiQ8uHl5o38DKkjW3Vu5gCOK5pIp1YuHpqiJzNeWV+VNjIi
ao+shkoplPLE6OWVbyLlKI04bpPQAgU0dICAByiQLLLGUDSAMQMkkMD/tAgMoICzCChQLbIHeBgH
iEMc9Ys+a8pIhBg2BiCoumsiqh8F/dUVVkYFaVPqaj6KIBsjvQCcGL0yCTcMfc8ByQmUnpzVTaj2
ZqTvQIntCw7F2/TLSLyvWgyOjEGG6O7BaBbB0rn4pFtTN/qw++pzBb8Y85KrrctIuwT7mHPKeNmr
8b8Lj7OU0HdFxUnF/7yMKJMFC1GQwA7sqV93GMmKKMtIhuPyyBKfw49KUHdzNckjDUYijKXKo5i9
AfQUh0IRLSBtM8tCK3dD3yazgEI/xd3ggOLCQS5GIqLc9lRTEWHfy2037jR4Lx6G+L1qasQV4jlS
E2N8TK01MOHuYp6x/3mFFR2lw7+EijlmqNej7+quP6b5xkN0DHuvNZdrsOU3ndw05isbvvjIMN9j
I+LanPXS8AWhC3pBkk8V4+ych474PaIPARnSj49TUzv4GpcYkDXFBNLL+rQz/OmWE/H1Wdsb3332
3QkaPVUvUba64wi9bbe0cKBI3CgCobjt7W5wiNuECECAcDWEDoNrWvucJxYiTO1l8MLK19xTjnoU
LXwj82BUQtGeqPiDXnsaGcH0MY6iqa8/BLNc1xonwq7FToSx0x4JiUMwdenrH58JB2jWpDviDYor
e4EZ1vhnOsNdkHjgS14stqK8vTyxeTz7HV6AOMKxECcUh2mKaIxYtP8U/rB7w/heOMJnxl9wUGQy
AVlU0Je1QSWNa6hznwTb6D0yKq5g/KpgPdQGs4XxLwDHGiDeAtgQRS6AGcs6wAH7hoBl0c2BFTnC
RSRIPBaucUlOs1WKOigcIZ5lPKgAmqBA57goXcVdoNEaVU4pv2KxSFH9QthlaDmShrVvg5NhneVe
VCxVYoY4xRpCzXxoSq69MjftkBEoQeejTSXRd56UyTSXmLOXRbFtnynHmkjjPlHCsi2lRKfjjLnM
WQqhYr/BVVQQJrYq1QNiJ1GjBJUGptAUgV4gs9/u0heObuKxfbWTYD250sFQxfMuhLqHwnLzoiex
7JkFxQgi/efIAkj/ckHgWsCyEkCAZgxokg+MyAEegiBMQjAaRilc03DklHO0xz30okY1UEFTIjpF
meOZJgi7cVNkIiZGQcWHjaiRG+BMY57UUM/HksqwGY5nRUFV6C+KutWstiWo26ApOXuKCqJm1XVJ
bNl4wNS7WQrPGmDqZdNuyh/KrBFJ71jTYsZjqPHwR6z4GM07+FdUPs2Oqr2JKlTdkw/EQPOOvckr
de76uKW+Y4072SuKnFJWwx0GNH7NqS+N+M7EnMWyTR3PTxPLWHYc9avjSc5sjFjYQV2FH4mMVkNI
ysCGZCtZAiJAAQy0AAZS0lvDxVDgFhDBJpzKCH0xSi22ApUidAIK/9eNxXMxcpfsnsRW3NluSoqm
BytxwiT5gIp342iErdyFutA1CcLGOwvylsu+0MVvfGsR3fyuq2i7sO5jxCtemXzQvutNCXbPUSrr
vte8reCpfjUJYbF05ML2ha+F84Ff71I3HIh4RhysVQyJLKBDzZgDig3RXI9MYTGHQa+Ln+CXGdsY
DIuR8Y2x0B+PiEAZQA6ykO/AJB0bYchITrIcFNAsJTs5yDvOgieiTGUt/BgTzLhElp9siS0X48R6
C7KXtZxiMSNgzGM2hIjn4OU1TyTMSXYzi1NRXezWeRBGhgkYaHNn66q3zyaUQp4DrQmeArrQTbgy
HB5yCAMmwtFcbv+0if13AEkKudJAxnSQfwtpSN/hIct19HIN0EAlg/qBiDiCP0grhZtoQTNLWJFO
qLATLYQqiSVhWBJm0oRaxxQmu3tCOXitSQYcS9KX8HSkM23pIGsaE89WRrQDNOk7BMUOyqZDtoF8
bUscwXeEaAkrk+BrJpT7CucuwjpIQmwstHvcUHhfoo29aAqJtECWJhBxC7DAZAyoQAcqAIfs1u9H
ChxDzoJDwkccoQSSesQLGoAkLYShBBQgxRlS1sQbfm9+N4jj1xJusx+ZoH0T6OKPLJBHi8FASTpr
4P82EG9XqiEKEcAYG5p4xCVEIQedWOASt9syJKTvBBT95SjHULX/Ir5Se9+bQxOqEEsFnvSij0sy
siGNaVqTGhY9JRtb7Q/pyDkfF1ZmbVWqTUOXovbupOUvZV9OpwqZNb7KvSDKGWJYq8GW3FhDI4ep
HPjsXh53WWUyilHKXlrmGsw00ysjeY7d10NFvnCiHE7VE3rgHrqnKtMasuE8a3RD75SfWebaIqnR
CYAsZT3kWXXD0AJkr9KLQ2j2BnBWQ4i7Ujk0sKV761YcstUsbWVrWxE5KUkPiOnfe9RbHZpWcZu1
8ptfa+SlrlvQq3/moMfh5seXPe2VdfGKR0T12Tp9t4xfLW9ZC1sCesjyRd1I8jurWeJ/fe6z9f5m
ydzk14IAFJF//60nUqhmJ7c0J2KCgGQCAWJkI76SMFfxJEPyJK7VCUJyH+QRKEg1PeEwPvSyGP6g
FRSYK5P1OEnSLpziUCHzJhbUTIXRFAXlgIJya0dUK4dCHCqyJ9pwJqhSRK7CQvyQOyg4gSyIFCxk
ODxoMFkyIyuoOLQSK/TigzE0QsfSe7NXaYwmSR2lW3vTIHDDEJZmINqCQLJ3cwzHSAfEcovmUrUn
Ug+hEJWGAKx3N1gIfnXIEMuXhUt2YtoHB5W2hye1DHnofin3PxoHLXdYSYwGOClFLQi0LXIThsPX
SF4YN3lDiT8RFH7zc5LEN3gDhog4LhyjRIajMlCUJlIEDkBTVv//oEsUUzIWmISziA2vZCXZNChg
xycnSEN3VE/npIs3gRU6k0opY4y+KDNWsjWr1DFsAzpbww/WsIsJdU/EsxVJ+DvgdVAj0w3qokc2
9IxWSGkDUI4SF21diEDXFoYGFBFBQRGq120/AUDF8EBz+IjFZTdyGC7mSCGaFhHZYo4RYY8jp2/P
EhT3CIjN5iHrOIqYplKWplL96IaQCI8JInBCh0Dp2JCOtIYKVCClBopreEAdyVznY4q/gzmdhBQw
JkSkcx7WMxWjwzuU1TRRgjlSVESuIZN9xDS+iEbzcz1t9Q5ZREHOw4rccTRwZUS2MzlFNDyJ4R7t
okfWmA7ZaJT/TIg6PZlQNrQ/U3SFlqYh+TaKjlSG3gItBnRzZfgTF8JoAZSHi1SPCklJ01eG+/gT
27KIeNkhBMlwyUCPCSlSC/lA69cMZ+lID1lJEamYy4BA+ohAaEiSJiZAl0gthqmJD8SJlYRymCaS
ZomZpKhBKElBQUMboAd6MANGQzNGPnlGtciN/nJalddCTNmLNtg4fUSby8MWWLlOPIOUVfNE3tgx
XFRETzQNuUEN/1RISuNL3AQ67NONv/CNXNk6xfmV/kNSzeBRy0eHZHmJklQ3b3gtuKd79VZt37Jy
3TaJyWAgdAkhjLaPXwiH1xJ91KIhcdgMpfaWCRSXnamfI6ct/+63cuLphYm5fAGoneBCl55JN5So
hulIoJbomJrZe8AnkhI6ioIjUKOZThZ1MDqYM2nyTlzxG1X4JtbkNK5IPHolTsOSPiZaL/lEHcN2
m/h0GHAyR2KXD0vCKOZRUD/6kwA1IwaFFDnagxhVRAYFYzaiHj9JQx0EAdnkI4LyVNGpLyYIjqgz
UWGhaMVVUqTGQIuWIMaQjvBIIenZLQxUagiiIIS5npPIQM2wnnTIQKeWQMZwfXAgnyf3LfqGhn1a
cy3ne3bKeggZniBZkHaacgKXDIjJhd0SpmgoqY4ZN8YVXBdSLfT3nYyaphSKp8jVll96po2qocxF
VvlUGm9VU/9G9FMlBDOIpVNSFVQu6SlX9VWXw1n5gSI06FeLVRM09VPWyFr80BS+ehNBVUKI8UrL
SjvtoFmwlRTZsFadBVtCpSehRSW+kkQ2ClUzog9LNSKClZXtIx05MR4zVFvYqXDClwCTJnyJsGJv
Boh0Y49uKQfuegd6WG2WsGJGBwfEdWLwCmZ1MLB1IGfLEGbyiggGm692sLAkFmQLewgLW7EG+1Ia
xgn4lbFOUGAF9hwfu2HlghUV1l/nxV35QGFLgGEwUQv0sg0vmwrdRV7olWCKM2FOwLGExgtLoBlL
oz0Vpjgd4aXLhgcQQiA4F5mXsFxAhiALUodFG7VSO7VAFgj/rlZly6lHWCsMs+SkUUC0VDsHcxhA
/IoI/+pkRtdkYbu2bNu2gTBlW4sE1xS3wnC1ULAJuxBgQgtdgIZEYJC3OGsEnxC0W6C3WsAKnTC4
h8azMPExXICNcFu4gdtegwYgIwZnbftIZXYMmMu5dUBiZbtpSztkz5Bmn7stnXuwqZsHm6ASxLZU
ACFj17AYXhsGHWQenNRr16CrWzBsSbkF6TAN1XANk/tuXwFai9uz2xCut6oJtUsOudsEItgKezEH
F5K5jwSpiDBtC4FqctCZTwandRAuIwlklEkH9wotTKtwDzJyLNa64fW7WwQFPjJPlduxSZluSAAS
DZYF+msF//NgvL9Gbr1AhFNglSKCa3A0awe8SkbwEvg6XNibmMu2XNy7ttu2tN47B+K7vo55CSNU
RNQEHaMxPdLDF150EAjzXP5BGEMUWGSBHWwBFhczjZjnFPfhd3HyONBZQtAha2qhlHKRHusxFkIM
eKlRH3y3efAReFMjwilceJmHGjvcNqNQCt8hFVGaGLJhG3vVCyrBEiWkHIyhHFpcxHLBGUhcxYOi
HW7XJJO3UQppABIRc+5qaZUUB/8omAnickD3UX8zc/wGcCSnIA7XQAdgccD1cwPXpiA1YirHhYV8
cS9HXCRlyODij3KKLFlIyC93jgxkcfVGXHZ8sBHCIJdcfv89R2oVV6dB53Ozd8mVtnGG7CAH9yHw
W0SagkLn4SpcA1AJVQQycipLISU4glSdkCMhuCsiCA7FpCcm8nZ7wb/itIxSeCZnw4FNSCW+xIFt
0ysWpBjacM1nwiUDXCupwotGMiJ7kkLJQVHKNCa9wRWvxIFzsTmcVIOKwcw9siu3BILd7IHfHIwY
UQ6vdESo4iKWW1xGx2iwVyGc2GyaJoclRZ6yR56KpADm53rTd3/Bx2TNIoAgRYADYp7ft36fGFIe
VTe953yf6H+vl9IPjXskR1LFJ1IldXszjb7UZ4krx53YIqAAKXHo94gQkrYd3UD8Z4iCk8sjjIJa
czOvMhP/mRUxleNMMEI0BNU46MJT0ji/tXMNO+U4FlMzFLUkxpNH7yMzOgPWFdQfOTkxJHrO8CPV
VpyjqEijp4GKK1QyyhhsMmENOsXDWh1sS9HXXG2LeJFFL1EzNaOMO2q5y4cgeAqZhanHliafBySJ
2eKQ2ssQ3mmAa6hpqjefZ1mGdUOIbUiSEyfaqAuXHolzMu2FnE2JD2ogJZkQ9YqWrY1SeBrajvjb
GreHK0WXTV0LrltHP7k+o1U70xXZwNlKo5UmorPV8naS0DPNnxDM9yNMRog8M/Q+GUFBLyE512BD
/xDAp3UWzPM8KtleewI8hwQ+OElasuEJd5Evw8A+O1kl/zkh3utN1lb0DowVExAcQBRSqog5IN47
0YK5p5MMmhQM2oTpn2OY2f24hkPxE+BLUivnLL8XkOUYl3EDvo6UyrYtdAPphXTwjpbo4ZldqQJI
kJREQC5F4ZV93Eqsy3fUDmQ31b+bDrFk1YQ93apaQdatjXMk4FqrtSJUKMSREbH5SwXzmtmtxMaI
3gglwhlxRc9TH+UCSqSJCs0ji3Vt3/Kr3ySajQtT5olt5W49F58gb3F04AuKACd14gpSkDHu4JEp
4Z8dEbB9qKIN4Y3p4pWokAf0l/yGuqS2l7H94KC5nymelqD9wcdGmYwehzL+E8GtvhoX2jiekSFc
O71gP/89XlDmFJ1hjhXjcxU6MlSwggryFOt1JG8ceuXBrLXG5C7NGE7h/TsrquvapBFx7QlGdWEB
ftc4WqUeOk1xVSeC8qGwdE/hhOZGAD2BJW/1K1rndN3D7tZE+DDDEk2o4D+q3ZECt7m919kOjtpw
E56JWJaOmtKCWZ8BIkneuXKPvKftmdI3x5cnddr4Gekm7oXw/ph1g9G0DWf8boloCEA13n7uyXre
MuOSXu90aQyl7ilMZSupHq2ixWvtcR2y5R6VJ91Zh/Ksxas+blqGtSbEfkg8bK2N0QuLwVlWBfN7
xaxubVvuAfPEw1V0ffJ/5Vgxfw42ElQAA1e0cVb/kPP/a9Iew8BrT7NWpumABJ7GsWVb6cP0TP5O
d1En0PpZ7QCI3qstHZnakJwsmq0QYToh0bfIBLIsBrqmc6qQBGKO3SdwebqmDb6mKX1yDXQtwxWe
wvUtminpoxj32vLoCoEgZOrZ+Ar4imhzknSpv72mjAb43TcgiC+nDMpcm+RetjC5FlY0NhtT6yVe
HlZhOksKOkYLFlGylRuy6YVdAEaz+PWxrl+zFYb7SPD7KCuyUWH7VGCyJosJg7hkoZuw+ApnEctm
z+8MZxYHCPtInSuvHRJm7rq5WgZn1z98q8tkKrb98DqxI/auZeawy/D8ktTxjSDAdFv/9n8EhkBq
4I+9//wPAos4kqV5oql4KKr7wqlyLAHDBLm+873/A4M5xkNoPCKTyiWz6XxCo9Kd65CIYbPaLbfr
/YJdNkZYlGiV0yTEtYSInU8JBLocV8feWb25ruKLAOJxCboUqtxxJZosdi3GCR6eFNo05DQ44EA5
TD01aB4xWOrcpB3QDJYZEKAuHLwNxBQUKgwUtH0l0MymjryexGYFr7Se/A6LIPcKwxxn8cYYlECT
/FJ7nVbTKMcqSKso1zhE2FBEjD5RdDo9FCGN75Quz2td84bvFZgWL1974ae4R2+gCH+pAE57Y3BL
NhP4EOgDZyIAPHhS1K3L6MPiEDK+BhC4oqCArRYGDv+AnIMKwaldKAu0eGkA14IEBAZ8K7DKFyp9
NkvWvPltxE9pKEOuSIkTaNESM0/d3IVzgYGUrqoiOAkSwc03I0G+IsBqJlWrUFk5ZSq04EtXKX8i
1XcWVVWkZatqW1DgZZ2jCZbC1Ot2ajWrXwNrJcB1wJvEixUS08tXcNnAcHWl1HfYpF8SM7/aTTq1
6q1VBsj69bs34kgSe20V3Fn3yoECYmlkW5pT72ird8NRJBeBAoQh5GyQazCBeI7j7XYQN4dDOYUJ
DR5wCoA9AITq6LR3d0C9OMUJE9x1t679QQRNED4Nb29jOYTjHYmGPECAqrTTevef9hdbubn0lwII
MEb/AisKoMVYX6jEspdkCywo4QgLVsiCCCOxMIBLFLJgYUEsEXDgfvrpApN+rgRWgD62zaCPfwIG
OIt+M5xYIoLVwKQTiAxuU+BeQLK4QCw37libiSx6gwyBE244pIcTxjLAGaHZpAuA/Unj4n8x6vVi
ibUZGdmUEh7ZozRoKSklf296SeYINso1lJFXJvAXAggqMBIb+ZU45CxIHWAnThwaSYeSKyJ54jYG
IHpkfjBxxSReJQSnnXo5qPdAcecxcF4AGD2nAwVFRFCEqOx5yul1EzDgwAQ7sIcDqKkGMIEDDlBA
RHuyrgdBEcpxVxwExhYXgX1j+PLNNlcIaGEsitUy/8M2xBQqgmL4BaKPMg1FSAO0+y0AEbflvgiI
QK5YQa65c7IEIbpQ5tfTG9mY22e5R+6SFSqKgeuaV392Wya7er0hEpn8JkNvArwIyJPBDY048bVW
1lSNs3fWFOG9NJjLC77emlkyLwcu0AKYAmEc7RvvjkimviO03PC7Nm7Myyz+bUvzFeYGYyHA8ub2
M8kh//twwsBVtOyxue46a6akupMD1TbYUKs6wArrqg7PARscsRQFgGuu12FHTqsUWMKAOr1qt6w8
B9NcNzRHniTXtew2RM27QJcQsE1oITiA4RHNO689sBBT+OECBxyyHjbae7C5P5F08CzQUN4wvCP8
Tf+y5vfe5CXDZZJkOGN35xUMxQhbXKZ+17w+jMeWp4t77K5fSztIXrJs98uIIzzSgtUQwPrN8QqM
cJbcFBz05MzLvjfgIau+uh5Mk8NRAMo1sPVx8Fxtag7PPVCdsme3OhwF72e3HkXvvx+B9+7D347b
ZXNC//uj5sB7c2vINlR2uzL95SQH4122KMSHSs3rW/IymgHeNbNyuSt3n+OdBf3QuTJJTlvUExnI
9NEzhm1OD0PzXMXmAEHAja4WRqtew6BxBdZJjHfN02EszlCbVhDQSAaE3ciIWMLdmSxhf5ohy4bI
C5gVTwEJ2AlRYnSt5QVRZ28ggH9IEAwYQmOFNPz/4tE0eMPtTaRpPJjA08JGvvNVDYDrAV+mjqUr
/l2CVkWwyA0skgn75fE5qYIbRr4nRwF6JCgYnBCZfCSnm5SMXQZCECAwhqbASWNH2wIabQx1w37t
0EydhJy8zEUmAfXtYxGMCQpZ4pPTOcko0rDk3rIxCwiajm5pStkAZmAUJ9WyGOsqWomo0gqbLFJC
jVRlCItISyRmq1C4zF24ivRE4u2MBrXAD2dAGJFZILNSWiyLIKakQNe9UpcL/FAsTKmZXkazG7jI
lPe4Q4HssK1sRcin2awGx7CtTzlSY085QFGqfK7tBmwjqNuIUIQHTOA4uAIWruoTj0RSpSsdI8kN
/8ViFznlJjJH6VkgQFJMZfzFRUeyxbZegjHQmbQF11jFjg7mUpp8sJ2a8ShuKlfEVXDRSiipDR14
qs4RMIij+xJLC3RIU9twcT+wTBlUpZFUSOYwMiOgKQ8zahuarCJBKbUkM3P3U7FccoEpSx7GPCob
xfTQFmRN3IhSipatJg8pYlleRhP01JeFg6Un3ZBRA5abvDa1Y5Cq6lpto9MR0HNZ8/uaeWDFHfP0
U47PqSwEpGYO45iHPHA8nzkQGlrknPY54XNH+IbDCYFG9KJuqMOB0HDLOigwBbrQFk1qIokNAaK2
SKUDI35brt4C1w95QC4iaJKnNTC3BMI1g3HZcP9cGFgXdISIbrkOQdzkeuG5LphuufyQ3ZR99wUH
Qu6ehqvcQNThvA30Isomwd3hFjcQNJGEEFqlA0zsoAHfAUImgiCeIMQKFALewYERXOAhDJhZsgDE
Kt5LgloYwDYE2TCHO+zhD4M4xK4gad1EPBEgQDR+GllxJ+b2Ag354r4bOoWFTWzjG+M4xzouQ3tN
wA8bG1jFLB4yFG7QA1HEI8JENoKQEaxkIHxiyQaWsg+Q/L0m88DKQ9ayk5fMCS4nAcwQ3ggUFkyK
J1P5yGhWsxKw/AQkRxkJYjaCkXVQHO/VM81AKGQQ7ixZIQBSzzzgM5X9PL8/2zlTRM7zRhC9DnX/
lGoJkdajDwg9BNFWuTiTnrSgG01nTcfRCJbehHCwjGkdMFoIdfZnqjsdhVG7egmwHjKfOT1oRQ+5
1Qx2dEZsfQRf+3rUuoaHr2P9BF3rWdfC5jUQVt0d+0WUOQ3QNH14ANE7jqc56UuVeXAwSG5b1jmo
2ra3kcMcTUnn2dM2t3yE5Z0dvGfawzk1RE/1vc4eqzuiqPa02diDb/vTnpvqjrSXI596x1He50a4
Pc/xHvOUygFVe7as5n2+5cSRAcNRj8alw530cZw+yal22TqLavPYWz5lA0XH2w1yWd3ze8tRj9oS
PnNLfHs66kv4zmV+boykxxIYF/h3MM6eoT+H/+AZtzi6h1WfUz373sPx1GfXzR0BP70466YOet73
qVOpluQ53wE53K2r5XDC7DD/cnxwECrilN0S6Uv3Zxk+DokHMNRVVvA9eWUJtpGvf+hw26ty9QCN
7/Pw/sbVqUKVrH2ONuWQP1aoMsHPB4RvV2VHVtnUtiz7+Z3wpGAb+HjlbQjYSvHY6RUoTIV6xmuK
CLOqVagagKtUEZ6OAWQb4d0mHutkfhwMOFb4tP3fvueT96TfVNzAU6znr4+gwtI4OW61zwfPD/PW
6drYcvC0p60vArAi6B0JCuk4lp8ckoea29BveVUdHvYQlb2mXkV/ykocVsBqh3JiJTXvo56u+P9e
6ZFe41mH361W7VkE6CkfJlSfePQK7VkHRKGN4SHeqIwbdHRe2YyfcAhHBz7f98VfqTWUPmVe7h3g
OWBEZv3AqgHQAmreqFjCd/iX9p2P+jUHJzzHCuog5MnP1bwNDhzYDMIe+cygOgDS/cQgHp0PeQgL
DMpcE6ZaPr1RoHGczI3DsDjfx6GaREmcE0IesamK5bWe+OSgf3XNDY6BDJYDHpEPDrDH2LwRg0nN
E87K05hK2yBhD2ZK25if/PxX1uDgHNVh1YyNsMghDlqhAzIh84mhP/GfZX0H3IgHGqZNwIHecfAg
DHLiOUhNgU2Hrojh2PwhIPoTIIFNqcmPEbb/IdwQFCBNh/yBITwIINyoWhkqWiZqSqCNVgCNzyCi
og8Go2b54A7KkZ1Vh6iYYSHtIa7xDxSSFv1cohv+4hT6IgDhzz11nHn8Hq7M3ftUDQyWijE+oqcQ
lAaKo/9UjcaByqj4DzUekv34zyB2YeTpntW84zASW/3g4KbxIzFaRKQF5OrRjyL6TwxmY/w8IgAl
HXFMIqWth0VsoibmYCdWpP3IzcaJYs350SBOWjOmIh6FpP+8zTUCUnooo3aoI7EJC7ORAi5a5Cew
yte4A3Z8IjDyIQ/+YOTxJEZU4sGFofq5XTMqITQCoiVAoRth5A/4pCJmhyXgof0gZQQIC2vt/9oZ
guEL1tz3EEeomSH/lMp33EC/HSPOccIc3t1xGBmhWUTX2NGt5ZE+euJUMqQhqscctsNA1mNEqiUO
NKMhwUOgfcdCnt/3EIEtHtJ1zCJFPiNj6mJjXqQfDR956GJe3iQxaqBciuQe0ePfmaTEAWVd5hE8
hE8a3iI6euE49B8XXsKsAMvlydEw6uQO4lwxQh4gpUqrhEpQ6lPzJeHnLSEvyoq3TWOgXZ5FxJnV
FEHXQJom2t5r3ZMAqma4haMX9l/taSUgLkfrZSf/rGY/dc3+TNSs/GZvWhRCFQdb8t5dnpsOjOdm
BgdA9WM4Ss36AKHQxVE+KaPcpWfzKaDnzf8HOhDmepzjHeWgCcLKf2LiEm7irPieRbIe2wBS8G0l
bJbPKfJhYGaocOwReS5nqelmSg6nPi0gJZ6mDnBjapZdRDHfZcXctVnWbAojH3ZWRNkmAMFWOYjf
06QoVw6HWTrjY/LiZZlHLmYHjMaKF0IHi/rlfOzoodkoRInfclbWVeJRjaJerujKVjbfGm3pgdbo
//moqLRWzJUnbKlNtHkmHYaWJuRTgJUWJ2gmZ81KYaJoaNXpaMFoHO3pLiafk/pbaYbKkx5fVUKi
4mFWgFUpkaKeRF7kgmqp+AVnDF7bnZmDjbqNoSIpZpqPZmpmmb5WZZWacuzop8BKmCraOc7/WkfE
A/b1wK5sBDoAmCes2SXET4KRAvbhahTMKpQ1WYNZTazE6n+pGCYomJvxQK/uKrzp3bKeWZPFymCi
GZcZaxCYWRQOqxAAK4Gt2bUG2HdUKw8A66xuq60aWIT16pVtAnf6wLWm67siqxRE65kdma4WWLp6
n961ILsaW792mlf6KxB0Fr8GLJOxYMEibMIqbJoNrJwR7MJCbK9FrHbU6sR+j75abMZq7MbSSsW+
JMeCbMiK7MiSbMmaLBO44Mmq7MqybMu67MvK68PC7MzSbM3a7M0qbMri7M7ybM/67M+irMwC7dAS
bdEarcrq7NEq7dIybdMWbNI6bdRK7dRS/+2bCW3VYm3Wam3U6qwE7IDXAgHYBoHXiq0EmO3X8oDZ
qq3YCkHZrq0OgO3anm0AsK0P1C3coi3czm0OxO3b8u3Xym3Y7q3bsu3dBu7fhm3b9oDh6q3a4i3d
+i3d8u3bxm3aPq7kjm3aRu7dQm7hNm7eJm7nDq4TRK7dYi7g+i3hgu7lli3qHu7klm4SOC7r7u3p
/gDnrqHlPu7rGu7ski3inq7n6m7jUu7wIi7n4u7k3i7otu7xsu7lQu/z2u7iZi7wzq71bu7iym3t
Tm/vXm/wAq/10m7g1m3zTm/wpq70gq/zii/1Gu/Ytm7ysu/yDq/50u/5Iu/2yu/+ou7qXv+U+4Zv
++Zt5VauAOPv/XYv7Bbw+w4w9ZrvAwtw4b5u/f6t/gaw5vqu+kIwA5evAgOw8IouBg9u7YJwBH/w
7hLvBmOuCvsv+m4v+/6u6a6w6GawCE+w/kpw7Oou4aavBa/vD2cZd8Zw5zKv+xKwCbsu966u5wrv
C58v5AIu2qpw8z6wElfvDFdw/wIwFv8wD3vvDdtuB0MvFVPwBZdwF39w+iLx+rJwCn8vF2PxEFsu
BOdwEYev/C7BAmfx58qwC1tx7rYv45qxB6tu9MquHQNxGDMBGSPxBuOwFV/vAtuv/0qyBhuy4hpw
345uAYtxIityEl/y9xYy9kayAk/yII//8e46Lu6Wbymjchc/Mg1PcANbMuwi8imzagDL8SfT8i5P
wRDrMRzzMhJ0cB2rsitHQSWbsSBPsfoegRj3rRHjbTDz7hxf8hZfcR+38TNvMQhzMv6+sDKDMzLf
cRPgcCOPLxrvXR638Dd7cSTHsjVf8O2esw3PcgszMPP6cBKf7Sg/sQw3synbsw4XLDALLh6Trgbv
Mz9zb+m6MzHz8TwbQT3L8h8bsiivsRfvqz2/LzPvMQJD9PyaMh6TNDdnMzbnczmH7kpntDOj9Ehz
dExrb+wyMumCcRl7Mj7rtC47L0JL9DwLMku/9E5rcy3/swsyc1AT70dT9D9T8jAbcEgT/7VTU3VT
Gy8uw+9M6zM5v3RQK7VSv3Ix260Tc7AbjzAyW/VQL/M093Fbwy9ZV/Q7W/QykzVGR/RRtx5Yp7QU
X3NfY3JYL7Ja/3RVK4E3F/ZgIzb/ovQpn/EB7/VP+/JFS/YV+/Qjk208y/Nj+7RjD3Zlx7NeTzXu
MkAL8PNf/3VTp7Vbw3Vqt/NCU/RrLzRlx7by6u1JCzYrzzJcw/RYEzQHnzVvi/Js169wa0T+1rVw
o/Y+s/Zb33NotyBpb210S/d0G+1o1wB1Y3d2azfMWvd2e/d3gzfHdnd4k3d5m3esjfd5q/d6s/cU
jLcTa/Lo3rJAQzZV+/Vmi/BEV+9X2/92URuBAAC4AOgAgA94gBd4EBB4AAS4gSu4gB9Bgjd4gUM4
hPsAhR84ECx4hu9Ahlu4Eiz4hROxX/P2Ejc3Udv1Y9+3UI9zidc356Y3LUtxQ7u05AY3W/fvKtM3
Z4v4Uusyjuu4P39xP+94gnN4DhC5gx+5kSP5kit5kz+4g0d4lCd5g394lEs4g/dAh284lDt5lnO4
loO4Nsd2QO+0RW+zjBtx9tKzbv/4VcdvlUE3DJ8wQ89tNct5JzP2ZG/14TbxVb8yF+c5TmM4k0v5
klf5lCM6of83lCd6lW95l2M5lXu5EHw5pQv4hFc6gfuwYhu1LIcuK7u0HiMvUKu4Xp//MSNH9osb
NA1HryNjMArTOE579UzntkqL9CeLtQdHNWdb9ZEfOqEnupMH+6L7OoNP+aNbuYd/OZczAYFbuKM7
umbLeh5L8JyjbxQ/cTBD9myjdhkf8ZHFefe+8bhL76gfr4/Xsp238xKncgLzeCCvsZ4jAbQzOpYX
e6MbO7P/wK9feZgLu6Ev+xIse6TzgLNz+bCHeGdr9TET90STsEnvsFuD9GGH8LkLObhftwVru7i7
MnzD+i5XMSQ/vJ+PMVf3OU+Lc5BHtsDrO7Ij/BMkOZh3OaS3vMwPvMwjeMAXupOHPCL395DFdzgD
9Ij/vGV/NBsfPSmEe5qrcSc89Hxn/zut0/QbqzaMn3ZfUzFmTwHCD7ylbznOV3i9X7mGN7vO57yX
Y3q873rbjrnWJ/PQD7XRT7wco/oTv/htL3Zpf7y7I70WT/xU8zSsu3GnC/q8F7m/DzvOg/2+iz2y
z7zitzyVR3vYLzo77/rGr72J67etC74tc/w64Hm5J30uK7zD13U3v/mNX7zHqzglC73eNzaQD7R8
e73jd73kH/vtJ7u/F7zOEzymV/qk277ZDzraH37C6/j95jCL2zcQ1zPrQ79gOzM0Y3us80DK5PXP
l/WfZ7b2c7zGu73mQzVhb37z737aOz7lz7zw9/7Zpz/7L/76oz+x+z6z43zQ3/Pvrv/6IWcuCEiB
KAajiZ7pWq5o2b7uHM9unZLuojC5BAy2hMIbEfgr2mRLpg3XjD6lqhcxCr1ZjzOB9ytIgcdNL2oM
Npm76HWg7Waf4ba2mE51wcPLbN8Jc+RXRQNoIjiY2CdoxPXXhMPjk0dZaXmJmam5ydnp+QkaKjpK
Wmp6KiWJusra6voKGys7S1tLqmqbq7vL2+v7CxwcgCtcbHyMnKy8fNvD/AwdLT1NDUssFZQzckW4
nX2YOeQ4pEU5uKXdXYW4sqeG9sZnmpYXd2f/jh9v1x6mL/evnrx3ZQYKzBSHXz55awLe+0JwIUQ2
bszAizenosF9F+vwucbuD5SRLMD/lTz0TV0NcY7QKVFXbh3KloXu9ItoMyM9jmQeWpyYZg/DhhDJ
7Izy0+jGORwxSjyqBw9TnDp7OqWicapWOVcPOrWHjyhVnku3LiGK55pJlkp0xEzXtlwMGHJT4ljp
JO8UkyrubuFmVuzNsQH1afyJMyvGpAMZF6QatOziogYRI62M2ezXjQ4HXwXrz45gShdBR306mHFk
rJkjqu1bci4jlYQCjYMbO503wHzvzja09vc5skA5U04tNWdT5YoRH3V8NnQ/ywCP2+xM3PTYzVEV
ek7Y0ePTiVw/h5862vzjy6ddOzs5FzjfbuTWysUtf7hu/TSQ6O0fEmsPBcYHduNp/6feZFYRt153
UPm04GSV/KNYTgY2aBpoFU7YmGTRVaiaTgS6o9UaPCiwwF9x9aZbbfDN15tdetFlzm/GiNahVRce
ViB59MAD3WZhCUUQdaetdqBkQg2FVo7nCdTkktwtx1prnCSFXEQXTtcjCgygWFMS2iDC30y8vbUX
mVmsRCYLjKhp5kvZkdeeFCQOSKWWxRUZWnN0kiZdYX1KV+eVe0bHpXcLbSced1LaOaiihuqJyY/y
fJkimpeMdCaMe0ES5iOe+IUNopBeImiTN4nF6qCJ/VmVn12tap1nBSnUaoOodgmejl3OasmWDvZE
omBD4srrpWBqGpJ+pLa4WzZ4Uf8x3LOQ2OhpgIUyumujjqkqYj6L9rpUhkNNGSuhtgLLFbm6cqsc
lQjulF6V65qqWYk+GpdluAFgGic3pDqrBZyfenqwigJTy/BJXsWb6JJPcrloow5SVK6VTNVLa5JG
4luex792S5iHHD8G3sPwOjTkvcoBTO1s2iqsCZs0/RfzzdGm9N/MEM/JypYsK1mWpNd5+HPI77p8
mdGFOo1echlNDfSwD+ar2Z3lwVxN115/DXbY0XAtdtlmn4122qSQrXbbbr8Nd9psx0133XbfLczc
eO/Nd99+r71stAjjDG3CMOU2U+GFv6mwf40j7NuKKs7Y6X4z7uf44SesCRPPirj/ia3DNeqs+Hyc
s1R6zz6nrjl8L30uKi1cDxwmYM6GHheNMiVOuIvZJuybpprzZq3D9eWl+/HbyGAbXc/WZzuoB7Ml
p/Cmx05C7tLzPnj38Qn+O4vGQz55964wMEn4JJFfquj2bS4+bPG/Ja31zb+ouB/KF5+E49+4Jb/d
yQ+A9nkeOuRTsOltr2Dr856Y4pO9hcVPf4f7nuXGFxy78AyBvTtf+sCnuwu67wm4K+AET1iI462O
gOIAh/8kSD/QbRCDLoJefkyIGwP+bobzQ94CrfAD0Z0OgQSMCfU+1UDahG9362tgEmeBvhh2Dmdl
cuBu1pG55KkOiE8UYRd9WJfM/1kieuLTYhnr17/OZTFOWwxii2A3xvwxgRxFQN0Ns8UmIRqxEf6D
0f9qFyoopo9xU4ScGH+InyIisYMAstG0mnczC6LEep3Aix3L6ELLVbGQcVReD3f2OgFS0Ydm9IYA
N5lJPy4OEM1inxpRGYooNoyGrAtY9WgEwFZ+EpSwpKQMK3et1dkSjnuEjQUVyUs/ilFNdOwZI6fg
yVI185Ss3CAzmXc5Z+5SeNFsXStkqT7QUa6XNXGe9FSYhy8ukHQj3FnsKkFMDJrzevwJYQedGM5G
hvJ9v/zjNNGJQsMxEVo6FCU/uWezXIAzme7E4ori2chUMtSUVCwhIlf5TCWiie1TLYGoG+FHn1cK
jAvxtKQv04Q4ac7RoW9c4ztDGghm7ZOhtwnYQWGxUP7V0p7tVKn5AvnTzVHwpZIkKvCAyroqIhOk
PX1pLefYpvYJFKlMpeo903lRQDbVmzz1YP+qt1VvDhOrY3VqgLLIUeKdaYXA9B0fXyec0G01rWBN
Klk54VFf5tV89cyqEeXKSHKCYqF/K6xhD4vYJRA2sYxtrGPrttjHSnaylPVaZCuL2cxqNm8f3Kxn
PwtaQYZ2tKQtbSnQh9rUqna1rG2ta18L29jKdra0ra1tb4vb3Op2t7ztrW9/C9zgCne4xP1tCAAA
Ow==

--_004_E1FE4C082A89A246A11D7F32A95A17828E4BCD90US70UWXCHMBA02z_--


From nobody Wed Jul 23 05:25:22 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3F01B27B3 for ; Wed, 23 Jul 2014 05:25:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level: 
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NORMAL_HTTP_TO_IP=0.001, SPF_SOFTFAIL=0.665] autolearn=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 1bsWzM03TpLe for ; Wed, 23 Jul 2014 05:25:19 -0700 (PDT)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 773FD1A0AFE for ; Wed, 23 Jul 2014 05:25:19 -0700 (PDT)
Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta05.westchester.pa.mail.comcast.net with comcast id Vn4q1o0031YDfWL55oRKT4; Wed, 23 Jul 2014 12:25:19 +0000
Received: from dhcp-90b7.meeting.ietf.org ([31.133.144.183]) by omta20.westchester.pa.mail.comcast.net with comcast id VoPA1o00R3xdsjB3goPC3L; Wed, 23 Jul 2014 12:23:17 +0000
Message-ID: <53CFA92F.5070306@alum.mit.edu>
Date: Wed, 23 Jul 2014 08:23:11 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References:   <53CEFA2C.8040407@nteczone.com>
In-Reply-To: <53CEFA2C.8040407@nteczone.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1406118319; bh=wPIVRoTWOsw8lc+TXGpQGN7dBGa1fPemCFISRCC8V/s=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=J9GjX9NYQjs1zM7+7NmEvP+8tEu8kaMESwU7i03Wykg6ZDDFqIHVr8tyDwyrrvG6N QuSFyiMle7T+jt5TT3rldneBc2VZ99EImnB8WChwkgjToOAGAbYAW0cpbUqkGivBT7 opUKKxq0d2wIeO7qFnySA2IeBY2tCu2YvbLYuOFXwMZQnBCVoP92lze1m9UIT6rLte XK4xp9fkHwxgvqBDQ3qNGbi/LuUuCuqylFpMDqa/rrk/2g2x+ShQjfM4siw7ylDClP QXQlxWymJQSkOKj8RRlRHruKIkB5G7dK+MmluMGrMDxYOykOOf5e3+pdsknLjucYIS 6SNpL1GKonxIg==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vBD-ujuCoART_c3KkeQhWM5fohE
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 12:25:21 -0000

On 7/22/14 7:56 PM, Christian Groves wrote:
> The browser would delay the establishment of media that are part of the
> "a=group:clue" group until a CLUE exchange has taken place and those
> media have been selected via a CLUE configure message. I'm not sure if
> that fits your criteria for acting differently?

I haven't thought about it much, but I think there are a couple of ways 
to deal with that. One is to simply hide those from the browser until 
the desired time. Another is to mark them as inactive for the browser 
until configured.

A more difficult problem is that CLUE uses one-way media streams, while 
jsep forces opposite direction ones to be merged into a single sendrecv 
m-line. I don't know how to fix that.

	Thanks,
	Paul

> Christian
>
> On 21/07/2014 6:34 PM, Kevin Dempsey wrote:
>> Would the browser be expected to act differently with "a=group:clue"?
>> If not, then that is really part of the signalling and not part of the
>> createXxx/setXxxDescription interface.
>>
>> The SDP passed to setXxxDescription and the SDP sent as part of the
>> signalling (if SDP is used) do not need to be identical.
>>
>>
>> On 21 July 2014 03:35, Kiran Kumar Guduru > > wrote:
>>
>>     It seems there is a small mis-understanding here. I agree there is
>>     a need for parsing and editing SDP by JS application for now.
>>
>>     I am not saying that constraints will do everything.
>>
>>     My intention is, to find the possibilities to extend the API of
>>     existing RTCPeerConnection and proposed RTCRTPSender/Receiver to
>>     add the attributes required by JS application.
>>
>>     For now, I proposed solution for one such kind of problem, i.e.,
>>     prioritizing codecs.
>>
>>     setSdPAttribute (key, value) is just an example on top of my head,
>>     which might solve this. But we can really figure out this after
>>     getting the proposed API (RTCRTPSender/Receiver ) in draft.
>>
>>     Regards,
>>
>>     Kiran
>>
>>     ------- *Original Message* -------
>>
>>     *Sender* : Paul Kyzivat>     >
>>
>>     *Date* : Jul 19, 2014 22:35 (GMT+09:00)
>>
>>     *Title* : Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
>>
>>     Kiran,
>>
>>
>>     My need won't be satisfied by plausible constraints.
>>     For instance, to interwork with CLUE it will be necessary to add an
>>     "a=group:clue" and include in it those m-lines that are to be "clue
>>     controlled". And that is needed in both offer and answer processing.
>>
>>     Thanks,
>>     Paul
>>
>>
>>     On 7/18/14 10:41 PM, Kiran Kumar Guduru wrote:
>>     > Dear Paul,
>>     >
>>     > My comment is only regarding the comments on section 6 of the
>>     JSEP draft.
>>     >
>>     > The sdp mangling described in section 6 may result in various error
>>     > scenarios.
>>     >
>>     > In that section, it is described like most of the parameters can be
>>     > modified thorugh constraints.
>>     >
>>     > The required modification, I found, which cannot not be done by the
>>     > constraints is "Remove or reorder of codecs (m=)"
>>     >
>>     > In order to avoid the SDP mangling at Java Script application
>>     level, I
>>     > submitted a draft for changing the codec preferences
>>     >
>> http://tools.ietf.org/html/draft-guduru-rtcweb-codec-preferences-01.
>>     > (Please review it).
>>     >
>>     > If this proposal is acceptable to the group, I hope we can remove
>>     > section 6 from JSEP draft.
>>     >
>>     > (Expecting that we can find alternatives for adding extra
>> attributes
>>     > like CLUE as identified by you, for example by extending the
>>     > proposed RTCRTPSender/Receiver by adding a generic
>>     setSdPAttribute (key,
>>     > value) method).
>>     >
>>     > Thanks,
>>     >
>>     > Kiran.
>>     >
>>     >
>>     >
>>     > -------Original Message--------
>>     > Sent: Paul Kyzivat
>>     > Date: Fri, 18 Jul 2014 14:32:24 -0400
>>     > Subject: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
>>     >
>>     > I just did my first thorough read-through of JSEP in quite some
>>     time. I
>>     > came away with a number of concerns:
>>     >
>>     > Section 1.1:
>>     >
>>     > When describing offers, modification by the application is
>>     mentioned:
>>     >
>>     >      JSEP's handling of session descriptions is simple and
>>     >      straightforward.  Whenever an offer/answer exchange is
>>     needed, the
>>     >      initiating side creates an offer by calling a createOffer()
>>     API.  The
>>     >      application *optionally modifies that offer*, and then uses
>>     it to set
>>     >      up its local config via the setLocalDescription() API.
>>     >
>>     > but when describing answers it is not:
>>     >
>>     >      When the call is accepted, the callee uses the
>>     createAnswer() API to
>>     >      generate an appropriate answer, applies it using
>>     >      setLocalDescription(), and sends the answer back to the
>>     initiator
>>     >      over the signaling channel.  When the offerer gets that
>>     answer, it
>>     >      installs it using setRemoteDescription(), and initial setup is
>>     >      complete.
>>     >
>>     > And Section 6 only talks about changing offers, not answers. It is
>>     > equally important to be able to modify answers. (More on this in
>>     later
>>     > comment on section 6.)
>>     >
>>     > Section 4.1.4:
>>     >
>>     >      The only difference between a provisional and final answer
>>     is that
>>     >      the final answer results in the freeing of any unused
>>     resources that
>>     >      were allocated as a result of the offer.  As such, the
>>     application
>>     >      can use some discretion on whether an answer should be
>>     applied as
>>     >      provisional or final, and can change the type of the session
>>     >      description as needed.  For example, in a serial forking
>>     scenario, an
>>     >      application may receive multiple "final" answers, one from
>> each
>>     >      remote endpoint.  The application could choose to accept
>>     the initial
>>     >      answers as provisional answers, and only apply an answer as
>>     final
>>     >      when it receives one that meets its criteria (e.g. a live user
>>     >      instead of voicemail).
>>     >
>>     > Issue: in this forking case, until the final selection is made
>> it is
>>     > unclear which one will need ICE completed. Only when a setlocal
>>     is done
>>     > on one of the answers will ICE begin to be performed. Then, if
>>     another
>>     > answer is provisionally set, won't that stop ICE for the prior
>>     one? And
>>     > won't it require new candidates? What if one of the earlier ones is
>>     > eventually chosen as final?
>>     >
>>     > And what if ICE completes for one of the candidates? Can't media
>>     start
>>     > to flow? Then what if a different candidate is set as the final
>>     answer?
>>     >
>>     > Section 4.1.4.1 :
>>     >
>>     > I question the following:
>>     >
>>     >      ...  While it is good practice to send an immediate
>>     >      response to an "offer", in order to warm up the session
>>     transport and
>>     >      prevent media clipping, the preferred handling for a web
>>     application
>>     >      would be to create and send an "inactive" final answer
>>     immediately
>>     >      after receiving the offer.  Later, when the called user
>>     actually
>>     >      accepts the call, the application can create a new
>>     "sendrecv" offer
>>     >      to update the previous offer/answer pair and start the
>>     media flow.
>>     >
>>     > This is very unfriendly when receiving calls that might be
>>     forked. By
>>     > immediately "answering" a call before knowing if the user will
>>     accept
>>     > it, you preempt the possibility that it will be answered on some
>>     other fork.
>>     >
>>     > For instance, if a call could come to your browser, or be sent
>> to an
>>     > answering service, and your broswer is on but you aren't present to
>>     > accept the call, then the call will be accepted and then dropped
>>     rather
>>     > than sent to the answering machine.
>>     >
>>     > So this technique should not be used if there is any possibility
>>     that
>>     > the request could be coming from a source that might try other
>>     > possibilities.
>>     >
>>     > Section 5.2.1:
>>     >
>>     >      When createOffer is called for the first time, the result
>>     is known as
>>     >      the initial offer.
>>     >
>>     > By this definition, if a peer connection initially *received* an
>>     offer
>>     > and sent an answer, and then it later sends an offer then that
>> offer
>>     > would be considered an initial offer.
>>     >
>>     > I think perhaps what is intended is:
>>     >
>>     >      When createOffer is called before setLocal has been called
>> with
>>     >      an offer,  the result is known as the initial offer.
>>     >
>>     > The following doesn't support the "balanced" BUNDLE policy:
>>     >
>>     >      Once all m= sections have been generated, a session-level
>>     "a=group"
>>     >      attribute MUST be added as specified in [RFC5888].  This
>>     attribute
>>     >      MUST have semantics "BUNDLE", and MUST include the mid
>>     identifiers of
>>     >      each m= section.  The effect of this is that the browser
>>     offers all
>>     >      m= sections as one BUNDLE group.  However, whether the m=
>>     sections
>>     >      are bundle-only or not depends on the BUNDLE policy.
>>     >
>>     > Section 5.2.2 says:
>>     >
>>     >      o  If any MediaStreamTracks have been added, and there
>>     exist recvonly
>>     >         m= sections of the appropriate media type with no
>> associated
>>     >         MediaStreamTracks, or rejected m= sections of any media
>>     type,
>>     >         those m= sections MUST be recycled, and a local
>>     MediaStreamTrack
>>     >         associated with these recycled m= sections until all
>>     such existing
>>     >         m= sections have been used.  This includes any recvonly or
>>     >         rejected m= sections created by the preceding paragraph.
>>     >
>>     > This fails to say anything about codec compatibility. SDP O/A
>>     requires
>>     > the answer to be a subset of the offer in terms of PT/codec
>>     > configuration. You should not use the same m-line unless there is a
>>     > desire to use the same settings for the new track as are
>>     currently in
>>     > use in the other direction.
>>     >
>>     > Section 5.3.1:
>>     >
>>     >      When createAnswer is called for the first time after a remote
>>     >      description has been provided, the result is known as the
>>     initial
>>     >      answer.
>>     >
>>     > By this definition, if a peer connection initially sent an offer
>> and
>>     > received an answer, and then it later receives an offer then the
>>     answer
>>     > to that first *received* offer would be considered an Initial
>>     Answer.
>>     >
>>     > I think perhaps what is intended is:
>>     >
>>     >      When createAnswer is called before setLocal has been called
>>     with
>>     >      an offer,  the result is known as the initial answer.
>>     >
>>     > When specifying the mapping of local tracks to m-lines in a
>> received
>>     > offer, there is again no discussion of codec compatibility. It
>>     is quite
>>     > possible that the m-line chosen by the algorithm in this section
>>     won't
>>     > have compatible codec attributes, but some other m-line will.
>>     >
>>     > Sections 5.3.2, 5.3.3, and 5.4-5.7:
>>     >
>>     > Are these empty because the content is yet to be written?
>>     >
>>     > Section 6:
>>     >
>>     > Other likely changes are addition of extra attributes and maybe
>>     other
>>     > parameters. For instance, CLUE will want to add another grouping
>>     construct.
>>     >
>>     > 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
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>


From nobody Wed Jul 23 05:55:23 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984181A0ACA for ; Wed, 23 Jul 2014 05:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBgNv1SH2c-Q for ; Wed, 23 Jul 2014 05:55:20 -0700 (PDT)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D12D1A02F8 for ; Wed, 23 Jul 2014 05:55:20 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id lx4so917989iec.31 for ; Wed, 23 Jul 2014 05:55:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vnmm+mhJE7OyQGwU4ek1PCABT+HPjD1mJX6QBZ3FYIg=; b=ETP8mhp5ePEl2E7VElP9HWr0qodZvsimQj2GP4zJKd/6lGzIHyLClLlcVRkx8TWTTf SPi1R2o+OR4chEq/hhKX6PQ0uPdMHRWDF0W+vD1WJ+HHuO4ygXb8GQ0wwRlJ6NlQrhYr TgJ4xujXPhFiran84gubAc4W9pfFZaxtI9kbyQ2Fb2EYv5WlWexDPpaBxMaiWHWlXpse HxVBrseYppVyvsnNCgFQz1j1HpGI1CHZYPRAm5Md/B6gDElhxg3BmygYgd/8uSQrG9O1 lHWCHOHkjtnVcah4G0sdte3gpa/+ACjVjVQEixuWTHH5Lw1ZBLbgOl/TwpqnKoE+MJO8 WqsQ==
MIME-Version: 1.0
X-Received: by 10.42.84.76 with SMTP id k12mr2973355icl.18.1406120119756; Wed, 23 Jul 2014 05:55:19 -0700 (PDT)
Received: by 10.43.154.80 with HTTP; Wed, 23 Jul 2014 05:55:19 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 23 Jul 2014 08:55:19 -0400
Message-ID: 
From: Ted Hardie 
To: Justin Uberti 
Content-Type: multipart/alternative; boundary=20cf30363feb3fecfb04fedbdaec
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5HOCIr6PiHaqN-41wM0hjaW5dps
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Sending of zero-length messages over data channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 12:55:21 -0000

--20cf30363feb3fecfb04fedbdaec
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 22, 2014 at 11:58 PM, Justin Uberti  wrote:

> I
> Since we can't send a zero-length SCTP message, I propose we add a
> PPID_EMPTY value or something similar to indicate a message with empty
> content.
>
>
=E2=80=8BHowdy,

The keepalive problem seems to be pretty amenable to any message, whether
of zero length, single byte or something else.  Is the convergence with
websockets on zero length important enough to re-open the drafts we just
sent to the ADs?

Ted

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


On Tue, Jul 22, 2014 at 11:58 P=
M, Justin Uberti <juberti@google.com> wrote:


I
Since we can't se=
nd a zero-length SCTP message, I propose we add a PPID_EMPTY value or somet=
hing similar to indicate a message with empty content.





=E2=80=8BHowdy,


The keepalive problem seems to be pretty am=
enable to any message, whether of zero length, single byte or something els=
e.=C2=A0 Is the convergence with websockets on zero length important enough=
 to re-open the drafts we just sent to the ADs?


Ted


--20cf30363feb3fecfb04fedbdaec--


From nobody Wed Jul 23 06:08:22 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BBD1B289E for ; Wed, 23 Jul 2014 06:08:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 aVDmlB-sgd2f for ; Wed, 23 Jul 2014 06:08:15 -0700 (PDT)
Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A6D91B28A2 for ; Wed, 23 Jul 2014 06:08:15 -0700 (PDT)
Received: by mail-vc0-f171.google.com with SMTP id hq11so2081628vcb.2 for ; Wed, 23 Jul 2014 06:08:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VqxyKINHupo8jdEy0qPakhTp4gLgu1A6KIaA6RZ9e6s=; b=VeiLWGl6DCerldGS/tr9y9SSR950Cs56o5DUTsBfdiU+8b1fJwfgUzzo9bogpuYiFw Rer5rcK1kP/lrMj+weAo1kLUF+GOfGgt3kD//chEoprU5krlNq8FGnWHqmvIcSbtehhg TlzKsFA179pmHRW1Q+IArRq2Ya1q0/9gIptGVmsKJR+P8N5PzxehnPYcvI9g61z5GT7h mX4fRtqoA1DDUpjqqD0HvumYbirsIHVpGz2da2R8U8H11nXwpCKUOrNfnuYnPNvuMUMb 6UqWFRf7m1IDp+Im/hr+/SNfG9KR4GABC991VPL6d7Gx+TaoGkekyHH+eEvx0GUzbpE0 rRsQ==
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:content-type; bh=VqxyKINHupo8jdEy0qPakhTp4gLgu1A6KIaA6RZ9e6s=; b=lUuEQvppGXl4oQ/BQinS/219CtyHIcXoWjzX6fRI350Etuozc3LPd1i7S4ydnjexYv g7t4R13Af5YWPOlc+u4omnQXfHpJ09aMLqDdJYGJ+VVgScJbiqzsi0AvxCu+wN0oSqqb lxWL9t1dvXxZXKTyLTUJpt1VFW45+lHkSUweJy67zXESwDe8w4uYB+R1B7Pmw0QW6T/1 CF/6RKbARzLlM4wkKGiqS2kn0asEXggsZcm9Lc/yBq6NB+KI64YRUT6RQMULl9xrRDST d/rBWAKBAp4qls+iQYP1Esw4/t4vYAGK4QWb9Ro8BAutAeKr4CeZrgSJc1KZnSjcJEpz 9j1w==
X-Gm-Message-State: ALoCoQmf+ggLehbbEgAuFMBG0zNqIPMz4Al6vW1SM9D1CEdDAzDDl0DvVkGZIGpNe4XB0az4C1cp
X-Received: by 10.220.94.135 with SMTP id z7mr2010417vcm.46.1406120894087; Wed, 23 Jul 2014 06:08:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.4.70 with HTTP; Wed, 23 Jul 2014 06:07:53 -0700 (PDT)
In-Reply-To: 
References:  
From: Justin Uberti 
Date: Wed, 23 Jul 2014 09:07:53 -0400
Message-ID: 
To: Ted Hardie 
Content-Type: multipart/alternative; boundary=001a11c1e48867621e04fedc084d
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/x25bAKJsJKwOP9P0C2ii0t9HDoc
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Sending of zero-length messages over data channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 13:08:19 -0000

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

Since we have promised drop-in compatibility with WebSockets, I think we
ought to do this, and the resulting text change here should be small enough
that we could update the doc without a long re-review.

It would be unfortunate to have to have an errata section on a draft that
isn't even a RFC yet.


On Wed, Jul 23, 2014 at 8:55 AM, Ted Hardie  wrote:

> On Tue, Jul 22, 2014 at 11:58 PM, Justin Uberti 
> wrote:
>
>> I
>> Since we can't send a zero-length SCTP message, I propose we add a
>> PPID_EMPTY value or something similar to indicate a message with empty
>> content.
>>
>>
> =E2=80=8BHowdy,
>
> The keepalive problem seems to be pretty amenable to any message, whether
> of zero length, single byte or something else.  Is the convergence with
> websockets on zero length important enough to re-open the drafts we just
> sent to the ADs?
>
> Ted
>

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


Since we have promised drop-in compatibility with WebSocke=
ts, I think we ought to do this, and the resulting text change here should =
be small enough that we could update the doc without a long re-review.=C2=
=A0



It would be unfortunate to have to have an errata section on=
 a draft that isn't even a RFC yet.


--001a11c1e48867621e04fedc084d--


From nobody Wed Jul 23 06:18:58 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E381A0ADC for ; Wed, 23 Jul 2014 06:18:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level: 
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyHluqGuSlMB for ; Wed, 23 Jul 2014 06:18:52 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4E401B28C7 for ; Wed, 23 Jul 2014 06:18:51 -0700 (PDT)
X-AuditID: c1b4fb25-f79da6d000004ad3-14-53cfb6395c54
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 8B.78.19155.936BFC35; Wed, 23 Jul 2014 15:18:49 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0174.001; Wed, 23 Jul 2014 15:18:48 +0200
From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= 
To: Paul Kyzivat , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
Thread-Index: AQHPpIxjcjDBq2U/J0e6rZ0BlTlHKw==
Date: Wed, 23 Jul 2014 13:18:47 +0000
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D033E33@ESESSMB209.ericsson.se>
References:   <53CEFA2C.8040407@nteczone.com> <53CFA92F.5070306@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvja7ltvPBBv/PiVus2HCA1WLtv3Z2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj8vdVzAVz2CqOz73F2MD4j6WLkZNDQsBE 4sTn2awQtpjEhXvr2boYuTiEBI4ySux8M40FwlnEKLG/bwIjSBWbQKDE1n0L2EBsEQFfid7L 54DiHBzCApYSDw4mQYStJH43rmeEsPUkWuY3sYPYLAKqEnM+XANbxgvUuvbvYVaI+QcZJdbs +gzWwAh0xfdTa5hAbGYBcYlbT+YzQVwnILFkz3lmCFtU4uXjf1BXK0ksuv0Zql5P4sbUKWwQ trbEsoWvmSGWCUqcnPmEZQKjyCwkY2chaZmFpGUWkpYFjCyrGEWLU4uTctONjPVSizKTi4vz 8/TyUks2MQIj4uCW36o7GC+/cTzEKMDBqMTDu2DZuWAh1sSy4srcQ4zSHCxK4rwLz80LFhJI TyxJzU5NLUgtii8qzUktPsTIxMEp1cBoyug1e5mXn1C4/o/3rJWumjPERPUe7aqbFlibq1VX OufVuuxH/+/4szxd2bRmZSFr+i/NltJ4T5aL1ts+lVze+333s0uiPye2JXWf6l5wwH7Z/WWS 3+31WFK8jA/xb/qut+fX35VmfI/m3BPVYbB+9byCjXFrZuglu1IjD02Hd0YWP878V9urxFKc kWioxVxUnAgA4YWsiWkCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/m5NEtGizH9VPpUcjvWmYS81WIiI
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 13:18:54 -0000

On 23/07/14 14:25, Paul Kyzivat wrote:=0A=
=0A=
> A more difficult problem is that CLUE uses one-way media streams, while=
=0A=
> jsep forces opposite direction ones to be merged into a single sendrecv=
=0A=
> m-line. I don't know how to fix that.=0A=
=0A=
Some time back I argued a lot that rtcweb should also use also use =0A=
one-way m-lines. Perhaps that ship has sailed, but I think it is a =0A=
cleaner solution (especially as the app at one end can at any time =0A=
change a lot of settings related to a MediaStreamTrack being sent - and =0A=
then perhaps it is unsuitable to use the same codec settings etc. as the =
=0A=
reverse stream any more). Naturally there would need to be a way to =0A=
support senrecv m-lines when interoperating with legacy equipment.=0A=
=0A=


From nobody Wed Jul 23 06:20:00 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D3F1B2903 for ; Wed, 23 Jul 2014 06:19:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.779
X-Spam-Level: 
X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 ucUR6U_1dV7Y for ; Wed, 23 Jul 2014 06:19:57 -0700 (PDT)
Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8921E1B28F7 for ; Wed, 23 Jul 2014 06:19:57 -0700 (PDT)
Received: by mail-vc0-f178.google.com with SMTP id la4so2116578vcb.9 for ; Wed, 23 Jul 2014 06:19:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vf+PghZSL5d/OBDEpBe/ABM2tPPIEXXKgLoRI6UERj0=; b=LJVVt2QY41PndCms9XHGhK98I1txscxZ82NWOW492nRAtHDzzL4J2pR/IbUaJgEvxW y0JGB5s6PYQuLY8/owjpx1DJsv26x0d8XqCLYuAZxPjI27GLLRCqMxR0O8g4/2/pZdRG fmnvrCVuLp/uwuZ6SE8mrDPE8B3N7ZUI2jipub0T3CoqXXNNVGc4uzbECueAI4vx7FOo jj+AvSZFHNTk63yTG8b44jG9hvg4ATeMvqa+IAX3SvsKIZm8oo0gxqq0BwmHaASjlkIb Zt7QTPyf0Kq7J3iyRM4IhP/6RIYI7ur1qOPufvK49/cvlblFu5rciqZ2ZKwCYrJC8YBD rybg==
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:content-type; bh=vf+PghZSL5d/OBDEpBe/ABM2tPPIEXXKgLoRI6UERj0=; b=OhcpfX5nuS0NR4OXZ4CAEzsuYqphSg65eElnco3iCcUJfkeT4fxRsMTBcUgSTYmpM1 eKTyE9igBGJDMJCiJ4F0WSYQudZuKh0UoJGge1FJHvX0pytRFtKfkkAAQ2ie4UZWeQf5 eEwopjpNM/PIEcKrMKO+6r/UbgHYKJv8he38X2cwbsYbj7OXosa26DjtVhTBatWB2bvc rxBUufC374h7gHEK6S5K/uRgXZibrp3oZtPiTkJ7E+ouIIJ5AyuKDbRhsatNHOo9w/1G zXQqX2kLA2kzht5z2LWGHTa/i/RTuUbs+ujFrVZwslnhQIF71KCxAOudlZSeaqzLov7U CM/g==
X-Gm-Message-State: ALoCoQkQJiFpIDwQ+w5mOTOtc0+f38UTHO3ZN77Z5Ge0zIy/MToldms7yWC7N9ns365+ZWUUNINP
X-Received: by 10.221.9.72 with SMTP id ov8mr1914955vcb.27.1406121596768; Wed, 23 Jul 2014 06:19:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.4.70 with HTTP; Wed, 23 Jul 2014 06:19:36 -0700 (PDT)
In-Reply-To: <53CFA92F.5070306@alum.mit.edu>
References:   <53CEFA2C.8040407@nteczone.com> <53CFA92F.5070306@alum.mit.edu>
From: Justin Uberti 
Date: Wed, 23 Jul 2014 09:19:36 -0400
Message-ID: 
To: Paul Kyzivat 
Content-Type: multipart/alternative; boundary=089e0117772149798f04fedc3292
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1UxggPb7lhJFlJh2BlI7ExRf_LE
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 13:19:58 -0000

--089e0117772149798f04fedc3292
Content-Type: text/plain; charset=UTF-8

On Wed, Jul 23, 2014 at 8:23 AM, Paul Kyzivat  wrote:

> On 7/22/14 7:56 PM, Christian Groves wrote:
>
>> The browser would delay the establishment of media that are part of the
>> "a=group:clue" group until a CLUE exchange has taken place and those
>> media have been selected via a CLUE configure message. I'm not sure if
>> that fits your criteria for acting differently?
>>
>
> I haven't thought about it much, but I think there are a couple of ways to
> deal with that. One is to simply hide those from the browser until the
> desired time. Another is to mark them as inactive for the browser until
> configured.
>
> A more difficult problem is that CLUE uses one-way media streams, while
> jsep forces opposite direction ones to be merged into a single sendrecv
> m-line. I don't know how to fix that.


If you can demonstrate a specific problem that this causes, we can
re-evaluate this. But we need to ensure that a simple phone call ends up
with a single m=audio line.

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





On Wed, Jul 23, 2014 at 8:23 AM, Paul Kyzivat <=
;pkyzivat@alum.m=
it.edu> wrote:



On 7/22/14 7:56 PM, Christia=
n Groves wrote:



The browser would delay the establishment of media that are part of the

"a=3Dgroup:clue" group until a CLUE exchange has taken place and =
those

media have been selected via a CLUE configure message. I'm not sure if<=
br>
that fits your criteria for acting differently?





I haven't thought about it much, but I think there are a couple of ways=
 to deal with that. One is to simply hide those from the browser until the =
desired time. Another is to mark them as inactive for the browser until con=
figured.





A more difficult problem is that CLUE uses one-way media streams, while jse=
p forces opposite direction ones to be merged into a single sendrecv m-line=
. I don't know how to fix that.

If you =
can demonstrate a specific problem that this causes, we can re-evaluate thi=
s. But we need to ensure that a simple phone call ends up with a single m=
=3Daudio line.





--089e0117772149798f04fedc3292--


From nobody Wed Jul 23 06:21:49 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FAB1A0AEA for ; Wed, 23 Jul 2014 06:21:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgnLoVy5hltp for ; Wed, 23 Jul 2014 06:21:45 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CE151A0ADC for ; Wed, 23 Jul 2014 06:21:45 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s6NDLbWp012734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 Jul 2014 13:21:37 GMT
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s6NDLZdD002675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 15:21:35 +0200
Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 23 Jul 2014 15:21:35 +0200
Received: from DEMUMBX005.nsn-intra.net ([169.254.5.198]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0181.006; Wed, 23 Jul 2014 15:21:35 +0200
From: "Rauschenbach, Uwe (NSN - DE/Munich)" 
To: ext Paul Kyzivat , Martin Thomson , Harald Alvestrand , "ext Hutton, Andrew" 
Thread-Topic: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness-05
Thread-Index: AQHPoivz5Q/X1aIUn0KWl+9ozKg7Opuk95sAgAAQD4CACKFccA==
Date: Wed, 23 Jul 2014 13:21:34 +0000
Message-ID: <56C2F665D49E0341B9DF5938005ACDF81944CF02@DEMUMBX005.nsn-intra.net>
References: <53C87F76.8070007@alum.mit.edu>  <53C891B9.6060103@alum.mit.edu>
In-Reply-To: <53C891B9.6060103@alum.mit.edu>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.110]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 2398
X-purgate-ID: 151667::1406121699-00007A71-8D438B86/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/BCQRZBe0mi8Ck-oLRYqTFeVN6y4
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness-05
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 13:21:48 -0000

Hi Martin, Paul, Harald, Andy,


> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Paul
> Kyzivat
> Sent: Thursday, July 17, 2014 11:17 PM
> To: Martin Thomson
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-
> freshness-05
>=20
> On 7/17/14 10:19 PM, Martin Thomson wrote:
> > On 17 July 2014 18:59, Paul Kyzivat  wrote:
> >>     WebRTC devices are required to support full ICE as specified in
> >>     section 3.4 of [I-D.ietf-rtcweb-transports].  However, when
> WebRTC
> >>     devices interwork with other endpoints that support only ICE-lite
> >>     (e.g. gateways) those endpoints will not generate consent checks,
> but
> >>     just respond to consent checks they receive.
> >
> > Yes, this.
>=20
> OK.
>=20

This ("WebRTC devices MUST support full ICE") contradicts with another exch=
ange on the mailing list:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg12554.html =20
------------------
> Section 4 [of -overview, U.R.] now states "WebRTC devices MUST implement =
the transport protocols described in [I-D.ietf-rtcweb-transports]"
>
> =20
> This might be a comment on -transports- more than -overview- but section =
3.4 of transports states that "The implementation MUST be a full ICE implem=
entation, not ICE-Lite". This is however not true for "WebRTC devices" only=
 for "WebRTC browsers" since ICE-Lite is sufficient for "WebRTC devices".

Good point. -transports- was last updated before I invented "WebRTC devices=
", it uses "devices" and "browsers" interchangeably.

Will make them consistent next round, if WG signs off on the split.
------------------

This discussion hints at that we still have no clear understanding of what =
a WebRTC device is. Does this class include gateways or not?

In other discussions on this list, there was no opposition against the fact=
 that gateways are OK with supporting ICE Lite only.

The question we have to answer is whether gateways are WebRTC devices. This=
 would imply that there may be different flavours of WebRTC devices (such a=
s at least native apps and gateways) and these flavours differ in some prop=
erties (such as ICE support). Alternatively, we could mention WebRTC gatewa=
ys as a third category in -overview.=20

Kind regards,
Uwe=20


From nobody Wed Jul 23 06:30:56 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCF71B2955 for ; Wed, 23 Jul 2014 06:30:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.952
X-Spam-Level: 
X-Spam-Status: No, score=-0.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_44=0.6, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=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 sxcFmY9NizWW for ; Wed, 23 Jul 2014 06:30:52 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 237061B28E9 for ; Wed, 23 Jul 2014 06:30:51 -0700 (PDT)
Received: from dhcp-9cdd.meeting.ietf.org (dhcp-9cdd.meeting.ietf.org [31.133.156.221]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id C5D211C1047F2; Wed, 23 Jul 2014 15:30:48 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Michael Tuexen 
In-Reply-To: 
Date: Wed, 23 Jul 2014 09:30:45 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  
To: "Makaraju, Maridi Raju (Raju)" 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/D7Dz2OBsnuCttWvEPJiZ7jUVCvI
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Sending of zero-length messages over data channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 13:30:53 -0000

On 23 Jul 2014, at 08:00, Makaraju, Maridi Raju (Raju) =
 wrote:

> =20
> In the existing data channel protocol, it's not possible to send =
zero-length messages, because SCTP prohibits it.
> =20
> While this may seem to be an academic point, it does represent a =
divergence from WebSockets, and this difference could be meaningful to =
applications who use empty messages for keepalives. Or maybe the Yo app.
> =20
> Since we can't send a zero-length SCTP message, I propose we add a =
PPID_EMPTY value or something similar to indicate a message with empty =
content.
> [Raju] There is a genuine need for this and the proposal is good.
> However, I am thinking of an alternate proposal to achieve the same =
but in a generic way.
> Define a PPID_OOB (out of band) or something similar.
> Apps can use this to send a message of non-zero length. For the =93Yo=94=
 kind of app or empty stream-level heartbeat purpose, app can send a 1 =
byte length message, which other end=92s app ignores.
What do you want to check with the heartbeat purpose? If you can talk to =
the peer?
That doesn't need to be done for every data channel, but only once for =
all of them.
As far as I understand, this is done by ICE...

Best regards
Michael
> This approach involves bit more API work for webrtc to have a =
variation of send(data, oobFlag) and new data type in onmessage(). IMHO, =
this approach allows more possibilities in future and also the same =
approach can be used by other SCTP use cases not involving webrtc.
> =20
> BR
> raju
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From nobody Wed Jul 23 06:33:00 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B081A0ADC; Wed, 23 Jul 2014 06:32:58 -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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qC5yw93FTTJh; Wed, 23 Jul 2014 06:32:56 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 624E31A0208; Wed, 23 Jul 2014 06:32:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.2.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140723133256.14499.93901.idtracker@ietfa.amsl.com>
Date: Wed, 23 Jul 2014 06:32:56 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vg3AImmzLZkOrrU642z5I_cBFFQ
Cc: rtcweb@ietf.org
Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-alpn-00.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 13:32:58 -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 Working Group of the IETF.

        Title           : Application Layer Protocol Negotiation for Web Real-Time Communications (WebRTC)
        Author          : Martin Thomson
	Filename        : draft-ietf-rtcweb-alpn-00.txt
	Pages           : 7
	Date            : 2014-07-23

Abstract:
   Application Layer Protocol Negotiation (ALPN) labels are defined for
   use in identifying Web Real-Time Communications (WebRTC) usages of
   Datagram Transport Layer Security (DTLS).  Labels are provided for
   identifying a session that uses a combination of WebRTC compatible
   media and data, and for identifying a session requiring
   confidentiality protection.


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:
http://tools.ietf.org/html/draft-ietf-rtcweb-alpn-00


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

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


From nobody Wed Jul 23 07:26:47 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829F61B2812 for ; Wed, 23 Jul 2014 07:26:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.779
X-Spam-Level: 
X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 uyMobGuxDO3K for ; Wed, 23 Jul 2014 07:26:39 -0700 (PDT)
Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37EE91B280E for ; Wed, 23 Jul 2014 07:26:39 -0700 (PDT)
Received: by mail-vc0-f171.google.com with SMTP id hq11so2275524vcb.30 for ; Wed, 23 Jul 2014 07:26:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TMoNwxuHOUlDxijQl4uI4zYyBefKhaexGlN+AVAmMNc=; b=KvGLovr/dfBuWXZee6PL7ph8g0Qg0oOSPeZUEKg8CeyTrl0N1ifwNKD5Z9KRlcMhFw AZhhcGXOjb7BcZ3cKAim/zsUtkOyAFTsfotmZqpTaWNq6wUSIZ/eYe4nYpMXTgskRawj znuFjjD/DK5DwSs2cuPDTxnWx9DJQQyUEWwudaYI4LVwtlzW47xCOrle5k3o9DZAvMw1 pctYDl3laOhNz+TyGJ9/sMCYnk8/8EkldMYxldcRdKEQQu0jyBH8lWQ1Y2uTsFGcv0ri 5ZlJBluRD2wW9Cmbtv52KZxAmrtJKRVq2gVeUyf5aXHnpbfE3jGdXuNwUOg9jYNsRMzv CQrw==
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:content-type; bh=TMoNwxuHOUlDxijQl4uI4zYyBefKhaexGlN+AVAmMNc=; b=LoAxcTKWz4eouZOUqvu+OzORh/enZvmoWibCbe2HLSmA1tL/SFWNKt1QS38KTY3Hn+ KTdxcihVMt8zw42CXyj2uI9X0vqKycdV0AV/kotuoo+9od42fBCZOy7jbTU2n4O6K+4u DP3uwPsmYub7LvVFQnLRqFUlsd83AomcE9DDIKfS0CgbBAxZ+F6rzVa/xpgEvrmHM0Rc W9E1aXHU6QdehprlwUmPAmlk56YefvUqS/Ii//jSrBctyECr6y1R+MsDuKX4Z9WMBaHz FAn2h1kjmzLMwPD2fQNGrMqZRRYJ8+T2mAbtgtNcN819755ncKJcZ0xhVXx3ZBlQSfqE xdTA==
X-Gm-Message-State: ALoCoQmNy4hyFNbqnk5KHyIeWtEidTXebUNBdAJ+KXwGWGute74A/1hro7WDplxvRHVTYO21c+fX
X-Received: by 10.221.9.72 with SMTP id ov8mr2532474vcb.27.1406125597039; Wed, 23 Jul 2014 07:26:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.4.70 with HTTP; Wed, 23 Jul 2014 07:26:16 -0700 (PDT)
In-Reply-To: 
References:   
From: Justin Uberti 
Date: Wed, 23 Jul 2014 10:26:16 -0400
Message-ID: 
To: Michael Tuexen 
Content-Type: multipart/alternative; boundary=089e01177721b8c44604fedd20b7
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uTFoYo89lc9bwdu3c6qa4gz4lnQ
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Sending of zero-length messages over data channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 14:26:40 -0000

--089e01177721b8c44604fedd20b7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

This would be apps that have some sort of application-level heartbeat. Of
course, you could change the apps, but that means we can't claim full
WebSockets fidelity.


On Wed, Jul 23, 2014 at 9:30 AM, Michael Tuexen <
Michael.Tuexen@lurchi.franken.de> wrote:

>
> On 23 Jul 2014, at 08:00, Makaraju, Maridi Raju (Raju) <
> Raju.Makaraju@alcatel-lucent.com> wrote:
>
> >
> > In the existing data channel protocol, it's not possible to send
> zero-length messages, because SCTP prohibits it.
> >
> > While this may seem to be an academic point, it does represent a
> divergence from WebSockets, and this difference could be meaningful to
> applications who use empty messages for keepalives. Or maybe the Yo app.
> >
> > Since we can't send a zero-length SCTP message, I propose we add a
> PPID_EMPTY value or something similar to indicate a message with empty
> content.
> > [Raju] There is a genuine need for this and the proposal is good.
> > However, I am thinking of an alternate proposal to achieve the same but
> in a generic way.
> > Define a PPID_OOB (out of band) or something similar.
> > Apps can use this to send a message of non-zero length. For the =E2=80=
=9CYo=E2=80=9D
> kind of app or empty stream-level heartbeat purpose, app can send a 1 byt=
e
> length message, which other end=E2=80=99s app ignores.
> What do you want to check with the heartbeat purpose? If you can talk to
> the peer?
> That doesn't need to be done for every data channel, but only once for al=
l
> of them.
> As far as I understand, this is done by ICE...
>
> Best regards
> Michael
> > This approach involves bit more API work for webrtc to have a variation
> of send(data, oobFlag) and new data type in onmessage(). IMHO, this
> approach allows more possibilities in future and also the same approach c=
an
> be used by other SCTP use cases not involving webrtc.
> >
> > BR
> > raju
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
>
>

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


This would be apps that have some sort of application-leve=
l heartbeat. Of course, you could change the apps, but that means we can=
9;t claim full WebSockets fidelity.




On Wed, Jul 23, 2014 at 9:30 AM, Michael Tuexen =
<Michael.Tuexen@lurchi.franken.de> wrote:
=






On 23 Jul 2014, at 08:00, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com>=
; wrote:



>

> In the existing data channel protocol, it's not possible to send z=
ero-length messages, because SCTP prohibits it.

>

> While this may seem to be an academic point, it does represent a diver=
gence from WebSockets, and this difference could be meaningful to applicati=
ons who use empty messages for keepalives. Or maybe the Yo app.

>

> Since we can't send a zero-length SCTP message, I propose we add a=
 PPID_EMPTY value or something similar to indicate a message with empty con=
tent.

> [Raju] There is a genuine need for this and the proposal is good.

> However, I am thinking of an alternate proposal to achieve the same bu=
t in a generic way.

> Define a PPID_OOB (out of band) or something similar.

> Apps can use this to send a message of non-zero length. For the =E2=80=
=9CYo=E2=80=9D kind of app or empty stream-level heartbeat purpose, app can=
 send a 1 byte length message, which other end=E2=80=99s app ignores.


What do you want to check with the heartbeat purpose? If you can talk=
 to the peer?

That doesn't need to be done for every data channel, but only once for =
all of them.

As far as I understand, this is done by ICE...



Best regards

Michael


> This approach involves bit more=
 API work for webrtc to have a variation of send(data, oobFlag) and new dat=
a type in onmessage(). IMHO, this approach allows more possibilities in fut=
ure and also the same approach can be used by other SCTP use cases not invo=
lving webrtc.



>

> BR

> raju


> ________________________=
_______________________

> rtcweb mailing list

> rtcweb@ietf.org

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







--089e01177721b8c44604fedd20b7--


From nobody Wed Jul 23 07:39:04 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEE91B27D4 for ; Wed, 23 Jul 2014 07:38:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXqAfu4GFy29 for ; Wed, 23 Jul 2014 07:38:53 -0700 (PDT)
Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2D491B2AB3 for ; Wed, 23 Jul 2014 07:37:28 -0700 (PDT)
Received: by mail-wg0-f50.google.com with SMTP id n12so1272731wgh.33 for ; Wed, 23 Jul 2014 07:37:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=VAUKjhOBR4/kli4lj2UbnbDQg1QAdna2qRQy3WjNwos=; b=TfZJjtMU41AGyszqRC6ucV9g8mTxkXfHTua4WEk2/1RvIJ58AgaId9LDq/ba4I+NXd IVU8ZJact4ouHfaSuTMf/k2aHS/opm4wWteBCr+5pqMQpf700wlb9lpdM327kBzay5iH +xU++bkT+2Nhuf9aQzsVb51GFJp4+U9eKPz2rU5trw4X1V3Yy0PMxmYXyJFifABf3ukd iImZvtnFqkODngUU7OTfOlcwANIQTejzrsj91y7dKalMfJXPy82Ibsq2KggSjPdJkfN6 2Iw+nCx5wTQCsCBxSeJD7kcQE0DlvwT5gs3g3Qat2Kg2yfckwQBsItN/2fKSBVjCfjc7 SBiA==
X-Gm-Message-State: ALoCoQlsTBXSSNmAQUVqlu8LngCQ6dUfVhhHeVkac6P/+qg4/NXoCZHKxu2PRbQCbuMSszXZf8GK
X-Received: by 10.180.105.68 with SMTP id gk4mr3853558wib.24.1406126247344; Wed, 23 Jul 2014 07:37:27 -0700 (PDT)
Received: from dhcp-a316.meeting.ietf.org (dhcp-a316.meeting.ietf.org. [31.133.163.22]) by mx.google.com with ESMTPSA id cx5sm6766834wjb.8.2014.07.23.07.37.25 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 07:37:26 -0700 (PDT)
Message-ID: <53CFC899.6010307@jitsi.org>
Date: Wed, 23 Jul 2014 10:37:13 -0400
From: Emil Ivov 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: RTCWEB 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/r_FfuM_DaGKxg6qoIRFOaehV_Aw
Subject: [rtcweb] Efficient crypto for conferences
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 14:38:55 -0000

Hey all,

Lately, we have been working on SFU-based conferencing. SFUs and WebRTC 
go together quite well: SFUs scale beautifully and are very latency 
friendly which makes them great for cloud deployment.

But!

There is a glass ceiling currently that I was hoping we could discuss.

Performance.

Currently the only way an SFU can operate is by terminating DTLS/SRTP 
for every participant. This means decrypting and (worse) re-encrypting 
all traffic that traverses the SFU. This easily accounts for 90% of the 
CPU use on the SFU.

This is not a difficult problem to solve and AVTCORE even has a WG 
document that addresses it. It removes the need for decrypting and 
allows SFUs to just forward packets.

However, while chatting with many others in Toronto it appeared that 
most of us are focused on solving a slightly different problem:

Privacy.

Or in other words: making it impossible (as opposed to unnecessary) for 
SFUs to decrypt.

While this is a notable effort, it is also much more complex and parts 
of it (i.e. not requiring end users to trust their web provider) would 
be arguably very hard to solve.

Therefore, my question to the working group is: wouldn't it make sense 
to try and solve the efficiency issue as a first step and then worry 
about the privacy one on a later stage?

Emil

-- 
https://jitsi.org


From nobody Wed Jul 23 07:46:52 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD561ABB17 for ; Wed, 23 Jul 2014 07:46:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKkeZ5rrfWgP for ; Wed, 23 Jul 2014 07:46:48 -0700 (PDT)
Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA97D1B27E3 for ; Wed, 23 Jul 2014 07:46:46 -0700 (PDT)
Received: by mail-we0-f175.google.com with SMTP id t60so1326013wes.20 for ; Wed, 23 Jul 2014 07:46:45 -0700 (PDT)
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:content-type; bh=qbNfLD4Abp5a4ZaGmcN2Kh2JnkRK8OXfsxilEjONnaY=; b=IDnYwHuMWyIEIC0+ySBte7BVjP2Vcb+O/DPjJ56lDrSFCA0IYtwSq6Myemr5c4wGZC uQIVkMuMmn0V/cqWcAPQ7+XRcv7DZb7HyX1PrC8sdt9wj4ymCYAOxrRVKuMBUsSu/mR+ oTMmxLi29zy8tZQKPnF6Iq/5yyUp/WQoReHX4YnY5ML7i+bh7csHcwI9HBuBqJiv2Ybf v+U+Kl7NK+GQdfB/CwtTf1JSeOQyVyhjpJVNb2gcSZOzM2+bejxrO4jNksLIuf9TCcIL FYJB2HkXetX+ibPdEVZuMWxK0/0huCAgv1VxyVn27xOOVFSOlPuuRwRjfiyyxAg5zkMi QZ7g==
X-Gm-Message-State: ALoCoQnuwb28Fa+rjb3jYpWLE27SQ6YxxZU0156xSjkp12ekUnZkbIvomaCUptkx7AbH1a2AiyXr
X-Received: by 10.194.184.166 with SMTP id ev6mr69225wjc.61.1406126805214; Wed, 23 Jul 2014 07:46:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.217.128.12 with HTTP; Wed, 23 Jul 2014 07:46:05 -0700 (PDT)
X-Originating-IP: [2001:67c:370:176:21c7:53e7:5370:2a3c]
In-Reply-To: <53CFC899.6010307@jitsi.org>
References: <53CFC899.6010307@jitsi.org>
From: Eric Rescorla 
Date: Wed, 23 Jul 2014 07:46:05 -0700
Message-ID: 
To: Emil Ivov 
Content-Type: multipart/alternative; boundary=047d7bae4932bc05b704fedd68ae
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7oFu1ulAHa0If75n6GpUCzmI0e4
Cc: RTCWEB 
Subject: Re: [rtcweb] Efficient crypto for conferences
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 14:46:49 -0000

--047d7bae4932bc05b704fedd68ae
Content-Type: text/plain; charset=UTF-8

On Wed, Jul 23, 2014 at 7:37 AM, Emil Ivov  wrote:

> Hey all,
>
> Lately, we have been working on SFU-based conferencing. SFUs and WebRTC go
> together quite well: SFUs scale beautifully and are very latency friendly
> which makes them great for cloud deployment.
>
> But!
>
> There is a glass ceiling currently that I was hoping we could discuss.
>
> Performance.
>
> Currently the only way an SFU can operate is by terminating DTLS/SRTP for
> every participant. This means decrypting and (worse) re-encrypting all
> traffic that traverses the SFU. This easily accounts for 90% of the CPU use
> on the SFU.
>
> This is not a difficult problem to solve and AVTCORE even has a WG
> document that addresses it. It removes the need for decrypting and allows
> SFUs to just forward packets.
>
> However, while chatting with many others in Toronto it appeared that most
> of us are focused on solving a slightly different problem:
>
> Privacy.
>
> Or in other words: making it impossible (as opposed to unnecessary) for
> SFUs to decrypt.
>
> While this is a notable effort, it is also much more complex and parts of
> it (i.e. not requiring end users to trust their web provider) would be
> arguably very hard to solve.
>
> Therefore, my question to the working group is: wouldn't it make sense to
> try and solve the efficiency issue as a first step and then worry about the
> privacy one on a later stage?


In what way is the efficiency issue not solved by EKT?

-Ekr


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

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





On Wed, Jul 23, 2014 at 7:37 AM, Emil Ivov <emcho@jitsi.org><=
/span> wrote:



Hey all,



Lately, we have been working on SFU-based conferencing. SFUs and WebRTC go =
together quite well: SFUs scale beautifully and are very latency friendly w=
hich makes them great for cloud deployment.



But!



There is a glass ceiling currently that I was hoping we could discuss.



Performance.



Currently the only way an SFU can operate is by terminating DTLS/SRTP for e=
very participant. This means decrypting and (worse) re-encrypting all traff=
ic that traverses the SFU. This easily accounts for 90% of the CPU use on t=
he SFU.





This is not a difficult problem to solve and AVTCORE even has a WG document=
 that addresses it. It removes the need for decrypting and allows SFUs to j=
ust forward packets.



However, while chatting with many others in Toronto it appeared that most o=
f us are focused on solving a slightly different problem:



Privacy.



Or in other words: making it impossible (as opposed to unnecessary) for SFU=
s to decrypt.



While this is a notable effort, it is also much more complex and parts of i=
t (i.e. not requiring end users to trust their web provider) would be argua=
bly very hard to solve.



Therefore, my question to the working group is: wouldn't it make sense =
to try and solve the efficiency issue as a first step and then worry about =
the privacy one on a later stage?

In what w=
ay is the efficiency issue not solved by EKT?




-Ekr
=C2=A0


Emil



-- 

https://jitsi.org



_______________________________________________

rtcweb mailing list

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





--047d7bae4932bc05b704fedd68ae--


From nobody Wed Jul 23 07:54:59 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6C91B2895 for ; Wed, 23 Jul 2014 07:54:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 sJTzSZuRz80u for ; Wed, 23 Jul 2014 07:54:55 -0700 (PDT)
Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 796BA1A00F8 for ; Wed, 23 Jul 2014 07:54:55 -0700 (PDT)
Received: by mail-vc0-f180.google.com with SMTP id ij19so2312978vcb.25 for ; Wed, 23 Jul 2014 07:54:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Dpl8JzjFVa8u0RJG9vpnoA24MZHyScXMkQ/U88E12P0=; b=nYKENwvrMCdvvhLaXTaDFqcoS+e6NUF0YjGrZfwERHiGzatOGqHHDJ3iqntf53+Zmr UFElSspPF99LuNFJU2D2B6IFT5gxZv4yIVAemf5l00kkS+ZBBiRsQm9VwNnAMPzlnHWa wgwri2lBQR3rVeOoPuH71lEaqMFKevqGvugtAGLToryRC8ptsHZWBsdU1zKxuaMmmEok onQiZZhF4KKqSJkJGvJZCIzfVsy1OSGyZY2jZWKTLx9V4qpshqVY/dOYdT62OfdIY48d dqxBRDwqTQqKwjCg3DWNgcQQ08B7XCpo9ewJXt+pvgeM4HZIUpVRw2IJ1ViD8W+92it/ ohDw==
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:content-type; bh=Dpl8JzjFVa8u0RJG9vpnoA24MZHyScXMkQ/U88E12P0=; b=CMeRYirV4BH6VabC/1ot4DzcowHSlZK9aGWo0xzX8IxNcf3S7+shy0spbFWBQq4qno WRx+DbPfHqThiC5LT+a8ggoP+8J2WnkbMC/DwvxXJI9ZEbKbdMdCdoCfCzjNvUYzhaa2 mBFp3x6/ftu+bShTDbEFrkCxwpsvwVfy5zaW0MHq8Reftdd6lczcQ2KhMpm0/XPxgAty nN7mKA0szLopUsnviI4PGv+b1JRXr4gRC0eBuaNSWbspoHkTixkbNTFgRpiAPtPpiXjm dxPDie7H7aHmLsS6DB1pmKq0R4VOGwPuJwygyLP0eyo8KDM6kxELbvcYZVem/iSg9kFP /FuQ==
X-Gm-Message-State: ALoCoQnCzQKgVI5VTyH2lPuGCzLe+h+0IeGOxfakmfdZEPIW6AJ9+UR1yun4KiR7r9ftuXzUEyj0
X-Received: by 10.220.69.68 with SMTP id y4mr2816018vci.21.1406127293429; Wed, 23 Jul 2014 07:54:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.47.238 with HTTP; Wed, 23 Jul 2014 07:54:13 -0700 (PDT)
In-Reply-To: <53CFC899.6010307@jitsi.org>
References: <53CFC899.6010307@jitsi.org>
From: Peter Thatcher 
Date: Wed, 23 Jul 2014 07:54:13 -0700
Message-ID: 
To: Emil Ivov 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nHeUz5z1Uj5cd7BUrALl0rZ-Dwo
Cc: RTCWEB 
Subject: Re: [rtcweb] Efficient crypto for conferences
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 14:54:56 -0000

I'd be in favor of seeing if solving both is possible before in a good
way before committing to a "first step" which might end up a dead-end.

In terms of timeline and scope, I think this is out of scope for
WebRTC 1.0, so even a small "first step" might be quite a ways off.

On Wed, Jul 23, 2014 at 7:37 AM, Emil Ivov  wrote:
> Hey all,
>
> Lately, we have been working on SFU-based conferencing. SFUs and WebRTC go
> together quite well: SFUs scale beautifully and are very latency friendly
> which makes them great for cloud deployment.
>
> But!
>
> There is a glass ceiling currently that I was hoping we could discuss.
>
> Performance.
>
> Currently the only way an SFU can operate is by terminating DTLS/SRTP for
> every participant. This means decrypting and (worse) re-encrypting all
> traffic that traverses the SFU. This easily accounts for 90% of the CPU use
> on the SFU.
>
> This is not a difficult problem to solve and AVTCORE even has a WG document
> that addresses it. It removes the need for decrypting and allows SFUs to
> just forward packets.
>
> However, while chatting with many others in Toronto it appeared that most of
> us are focused on solving a slightly different problem:
>
> Privacy.
>
> Or in other words: making it impossible (as opposed to unnecessary) for SFUs
> to decrypt.
>
> While this is a notable effort, it is also much more complex and parts of it
> (i.e. not requiring end users to trust their web provider) would be arguably
> very hard to solve.
>
> Therefore, my question to the working group is: wouldn't it make sense to
> try and solve the efficiency issue as a first step and then worry about the
> privacy one on a later stage?
>
> Emil
>
> --
> https://jitsi.org
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From nobody Wed Jul 23 07:57:55 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3061B28C4 for ; Wed, 23 Jul 2014 07:57:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bMrxk5IO4jJ for ; Wed, 23 Jul 2014 07:57:49 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A53841B28C8 for ; Wed, 23 Jul 2014 07:57:48 -0700 (PDT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s6NEvkAH010730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jul 2014 09:57:46 -0500 (CDT)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s6NEviZX010155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 10:57:45 -0400
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Wed, 23 Jul 2014 10:57:44 -0400
From: "Makaraju, Maridi Raju (Raju)" 
To: Michael Tuexen 
Thread-Topic: [rtcweb] Sending of zero-length messages over data channels
Thread-Index: AQHPpipfEWtPO6jXOES6Y6R7CwNaxJutiTxggABiGoD//9LzQA==
Date: Wed, 23 Jul 2014 14:57:44 +0000
Message-ID: 
References:   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.16]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8YgBiM5yOiIGeU20GZTuEC322n0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Sending of zero-length messages over data channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 14:57:51 -0000

> > In the existing data channel protocol, it's not possible to send zero-
> length messages, because SCTP prohibits it.
> >
> > While this may seem to be an academic point, it does represent a
> divergence from WebSockets, and this difference could be meaningful to
> applications who use empty messages for keepalives. Or maybe the Yo app.
> >
> > Since we can't send a zero-length SCTP message, I propose we add a
> PPID_EMPTY value or something similar to indicate a message with empty
> content.
> > [Raju] There is a genuine need for this and the proposal is good.
> > However, I am thinking of an alternate proposal to achieve the same but=
 in
> a generic way.
> > Define a PPID_OOB (out of band) or something similar.
> > Apps can use this to send a message of non-zero length. For the "Yo" ki=
nd
> of app or empty stream-level heartbeat purpose, app can send a 1 byte len=
gth
> message, which other end's app ignores.
> What do you want to check with the heartbeat purpose? If you can talk to =
the
> peer?
> That doesn't need to be done for every data channel, but only once for al=
l
> of them.
> As far as I understand, this is done by ICE...
=20
Yes, heartbeats to the peer will be taken care by SCTP heartbeats and/or DT=
LS heartbeats and/or ICE.
But, that does not guarantee data channel level liveliness.
Generic heartbeats are just one of the use cases for PPID_OOB proposal. Oth=
er use cases for this include... app can send low-frequency OOB data to the=
 peer within the same data channel instead of creating a new one. This way =
the OOB will not interfere with syntax+semantics of the main app protocol u=
sed in that data channel.


BR
Raju


From nobody Wed Jul 23 07:59:20 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAAD1B2A6F for ; Wed, 23 Jul 2014 07:59:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EebO5N5_N3QV for ; Wed, 23 Jul 2014 07:59:10 -0700 (PDT)
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC301B2A6B for ; Wed, 23 Jul 2014 07:59:09 -0700 (PDT)
Received: by mail-wg0-f45.google.com with SMTP id x12so1304645wgg.28 for ; Wed, 23 Jul 2014 07:59:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4esGkul1OEVe60dizU1PnnPMXWfNzj3tAihT9tribKA=; b=W/r8FWP7M1Rzzvaz0kRtFyetdtcHv4DVaFheTuEC9n+PTwGnPswPEhbGcVZulsmYTM OHyI6YmVguCARCT7+kdjOFUIxZn42an87DpQRX4x3f38510INTAD+v7TwBDAgNsNO2AV G3c58bWQmh/PcIT2lr8CE6Yx1kmgvaFPRcz1biDBr2GoQR1OtjJcb1AEq8Mkx2DJ8Log IMVLpgT2Rk91CYp7jf6hH0rjCNt3ImaQKko6IOGVYORzc9rdwT9YIHVCnl/moIEB7Vto hVK6nQQcRugHXEe/xPfFQtigL77JiVBz2ZWWefDbfTLb+lQ4URYsBBlrYKaIZXMWQEEl gIGQ==
X-Gm-Message-State: ALoCoQkoZWuUxPMxgw8tLUT4CBOABINspbmfYW8oOMZCttIvBzML5rft1Y8HWmH7Msd8DCf/TJK6
X-Received: by 10.180.101.136 with SMTP id fg8mr4057161wib.44.1406127548708; Wed, 23 Jul 2014 07:59:08 -0700 (PDT)
Received: from dhcp-a316.meeting.ietf.org (dhcp-a316.meeting.ietf.org. [31.133.163.22]) by mx.google.com with ESMTPSA id ko8sm6914946wjc.11.2014.07.23.07.59.06 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 07:59:07 -0700 (PDT)
Message-ID: <53CFCDB8.3020206@jitsi.org>
Date: Wed, 23 Jul 2014 10:59:04 -0400
From: Emil Ivov 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Eric Rescorla 
References: <53CFC899.6010307@jitsi.org> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/eDzy17PR2F9PDVgvtHS5_RYthhQ
Cc: RTCWEB 
Subject: Re: [rtcweb] Efficient crypto for conferences
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 14:59:18 -0000

On 23.07.14, 10:46, Eric Rescorla wrote:
>
>
>
> On Wed, Jul 23, 2014 at 7:37 AM, Emil Ivov  > wrote:
>
>     Hey all,
>
>     Lately, we have been working on SFU-based conferencing. SFUs and
>     WebRTC go together quite well: SFUs scale beautifully and are very
>     latency friendly which makes them great for cloud deployment.
>
>     But!
>
>     There is a glass ceiling currently that I was hoping we could discuss.
>
>     Performance.
>
>     Currently the only way an SFU can operate is by terminating
>     DTLS/SRTP for every participant. This means decrypting and (worse)
>     re-encrypting all traffic that traverses the SFU. This easily
>     accounts for 90% of the CPU use on the SFU.
>
>     This is not a difficult problem to solve and AVTCORE even has a WG
>     document that addresses it. It removes the need for decrypting and
>     allows SFUs to just forward packets.
>
>     However, while chatting with many others in Toronto it appeared that
>     most of us are focused on solving a slightly different problem:
>
>     Privacy.
>
>     Or in other words: making it impossible (as opposed to unnecessary)
>     for SFUs to decrypt.
>
>     While this is a notable effort, it is also much more complex and
>     parts of it (i.e. not requiring end users to trust their web
>     provider) would be arguably very hard to solve.
>
>     Therefore, my question to the working group is: wouldn't it make
>     sense to try and solve the efficiency issue as a first step and then
>     worry about the privacy one on a later stage?
>
>
> In what way is the efficiency issue not solved by EKT?

EKT is exactly the AVTCORE solution I was referring to.

Emil


From nobody Wed Jul 23 08:41:51 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CC71A01E7 for ; Wed, 23 Jul 2014 08:41:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 5rUtnbcI3jS3 for ; Wed, 23 Jul 2014 08:41:48 -0700 (PDT)
Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665DE1A00AA for ; Wed, 23 Jul 2014 08:41:48 -0700 (PDT)
Received: by mail-vc0-f181.google.com with SMTP id lf12so2456721vcb.40 for ; Wed, 23 Jul 2014 08:41:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PgFRdEsi/FDKkM4cIyDOLC0fVTs0Hmzftsvwq4VlFw4=; b=MlponczLQ7Ai7tmkw7Q78NnRl8AoCEwXS1Ckn0KRWeX21dwXFyboGJFO7cv9HKTIji VUthQBp1FSBj4UX7f1LD/Qj/lJZvo7jQfACxqry2nBd1CwOF/IUAk8s60ZVZGY3bdpeQ hm92p+IhJ/YKUoFp2YglNMY0elw2/TxU4LiKB0X/bbciqbhiyYYcc69cYuWYu02FqxBc R+tRo3cdf4muWvfHIhgw527ETB2RNVrIEcso+j6IM3RJ0GgMmeqKYrHoj5tLfrgCwbOD U4ahUvz8Gky3xJ2vhuD2m+ZI1TJsheeuQnitSJQYxF3SK0QGxNzYUdA0b3tU5bTyr2Be A23g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PgFRdEsi/FDKkM4cIyDOLC0fVTs0Hmzftsvwq4VlFw4=; b=EmKVvX2WvgI98fP6p7Odwn1Jx+37vScsslwSFa8/jXz5tWh+5KPUvkzbU0IgcLERWi 9Pv+T3TkdASUbo/E0wMW8WwPMJrdjYyJ8NO4apCcKAUWBZlNC0tmiS3mlXFEypolXmHt HvF7N3pl7o+W4Aq3jAT1luE1cvymW9nxeDhmZAC8XCgUU1m4e1CWziCdVSqA0kRYWFCx blfeReJEwcfEpfdIMon33AlvnSrmVurtY/z3Q/EwA0jBEW/AuxLaiHYTG3UyMwGq5uBD 4iArrPZexX0SijG9hdnkPQekfDvmYaPjRkmLjTw37GKAQhqWc2ZUXKZzkEmX/3gI800W UEUA==
X-Gm-Message-State: ALoCoQmrxRMbRnZqTxrVuWJBSFzalM3WD4PPbOCGBsOsYNAO+WQfyWEHDdEnFb7FWmqgoq9OVbKC
MIME-Version: 1.0
X-Received: by 10.52.135.133 with SMTP id ps5mr2711096vdb.33.1406130103588; Wed, 23 Jul 2014 08:41:43 -0700 (PDT)
Received: by 10.52.4.70 with HTTP; Wed, 23 Jul 2014 08:41:43 -0700 (PDT)
Received: by 10.52.4.70 with HTTP; Wed, 23 Jul 2014 08:41:43 -0700 (PDT)
In-Reply-To: <53CFCDB8.3020206@jitsi.org>
References: <53CFC899.6010307@jitsi.org>  <53CFCDB8.3020206@jitsi.org>
Date: Wed, 23 Jul 2014 11:41:43 -0400
Message-ID: 
From: Justin Uberti 
To: Emil Ivov 
Content-Type: multipart/alternative; boundary=bcaec51a70a255391804fede2d81
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nyi9-O4j-lYRgw6xyqgzYRidlSE
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Efficient crypto for conferences
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 15:41:49 -0000

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

>From an efficiency perspective, doesn't AES-NI make this much less of an
issue, especially when the SFU has to do real work like rate shaping?
On Jul 23, 2014 10:59 AM, "Emil Ivov"  wrote:

>
>
> On 23.07.14, 10:46, Eric Rescorla wrote:
>
>>
>>
>>
>> On Wed, Jul 23, 2014 at 7:37 AM, Emil Ivov > > wrote:
>>
>>     Hey all,
>>
>>     Lately, we have been working on SFU-based conferencing. SFUs and
>>     WebRTC go together quite well: SFUs scale beautifully and are very
>>     latency friendly which makes them great for cloud deployment.
>>
>>     But!
>>
>>     There is a glass ceiling currently that I was hoping we could discuss.
>>
>>     Performance.
>>
>>     Currently the only way an SFU can operate is by terminating
>>     DTLS/SRTP for every participant. This means decrypting and (worse)
>>     re-encrypting all traffic that traverses the SFU. This easily
>>     accounts for 90% of the CPU use on the SFU.
>>
>>     This is not a difficult problem to solve and AVTCORE even has a WG
>>     document that addresses it. It removes the need for decrypting and
>>     allows SFUs to just forward packets.
>>
>>     However, while chatting with many others in Toronto it appeared that
>>     most of us are focused on solving a slightly different problem:
>>
>>     Privacy.
>>
>>     Or in other words: making it impossible (as opposed to unnecessary)
>>     for SFUs to decrypt.
>>
>>     While this is a notable effort, it is also much more complex and
>>     parts of it (i.e. not requiring end users to trust their web
>>     provider) would be arguably very hard to solve.
>>
>>     Therefore, my question to the working group is: wouldn't it make
>>     sense to try and solve the efficiency issue as a first step and then
>>     worry about the privacy one on a later stage?
>>
>>
>> In what way is the efficiency issue not solved by EKT?
>>
>
> EKT is exactly the AVTCORE solution I was referring to.
>
> Emil
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

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


From an efficiency perspective, doesn't AES-NI make this=
 much less of an issue, especially when the SFU has to do real work like ra=
te shaping?


On Jul 23, 2014 10:59 AM, "Emil Ivov" =
<emcho@jitsi.org> wrote:





On 23.07.14, 10:46, Eric Rescorla wrote:









On Wed, Jul 23, 2014 at 7:37 AM, Emil Ivov <emcho@jitsi.org

<mailto:emcho@jitsi=
.org>> wrote:



=C2=A0 =C2=A0 Hey all,



=C2=A0 =C2=A0 Lately, we have been working on SFU-based conferencing. SFUs =
and

=C2=A0 =C2=A0 WebRTC go together quite well: SFUs scale beautifully and are=
 very

=C2=A0 =C2=A0 latency friendly which makes them great for cloud deployment.=




=C2=A0 =C2=A0 But!



=C2=A0 =C2=A0 There is a glass ceiling currently that I was hoping we could=
 discuss.



=C2=A0 =C2=A0 Performance.



=C2=A0 =C2=A0 Currently the only way an SFU can operate is by terminating
=C2=A0 =C2=A0 DTLS/SRTP for every participant. This means decrypting and (w=
orse)

=C2=A0 =C2=A0 re-encrypting all traffic that traverses the SFU. This easily=


=C2=A0 =C2=A0 accounts for 90% of the CPU use on the SFU.



=C2=A0 =C2=A0 This is not a difficult problem to solve and AVTCORE even has=
 a WG

=C2=A0 =C2=A0 document that addresses it. It removes the need for decryptin=
g and

=C2=A0 =C2=A0 allows SFUs to just forward packets.



=C2=A0 =C2=A0 However, while chatting with many others in Toronto it appear=
ed that

=C2=A0 =C2=A0 most of us are focused on solving a slightly different proble=
m:



=C2=A0 =C2=A0 Privacy.



=C2=A0 =C2=A0 Or in other words: making it impossible (as opposed to unnece=
ssary)

=C2=A0 =C2=A0 for SFUs to decrypt.



=C2=A0 =C2=A0 While this is a notable effort, it is also much more complex =
and

=C2=A0 =C2=A0 parts of it (i.e. not requiring end users to trust their web<=
br>
=C2=A0 =C2=A0 provider) would be arguably very hard to solve.



=C2=A0 =C2=A0 Therefore, my question to the working group is: wouldn't =
it make

=C2=A0 =C2=A0 sense to try and solve the efficiency issue as a first step a=
nd then

=C2=A0 =C2=A0 worry about the privacy one on a later stage?





In what way is the efficiency issue not solved by EKT?





EKT is exactly the AVTCORE solution I was referring to.



Emil



_______________________________________________

rtcweb mailing list

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




--bcaec51a70a255391804fede2d81--


From nobody Wed Jul 23 09:41:50 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4891A0146 for ; Wed, 23 Jul 2014 09:41:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CL91RjChw6P for ; Wed, 23 Jul 2014 09:41:49 -0700 (PDT)
Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59D81A0242 for ; Wed, 23 Jul 2014 09:41:48 -0700 (PDT)
Received: by mail-wi0-f171.google.com with SMTP id hi2so8117178wib.10 for ; Wed, 23 Jul 2014 09:41:46 -0700 (PDT)
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:content-type; bh=EMGjw7+8opvlRUwzHCGzgdNZsB6GKBMF5dwMxz5jD10=; b=DPqvqK9e5L1HbKbRN50RDab6/4fhh5pQUnRhObjaGYW+q2nZXNE8m+HWWYf9+0Krin ooydbOWKidCAYVNrMxbLmhSzDIzoqy8xUc9Dr9214LaODNxjprEY8zU4H/aYS1WnJ2Io 6+p8CmA/dH0hQFMsoQGUEUBfqud7TGvXbAYpOinLi5OlE/OTy6H4zNufE0f95dTLwXoQ UtcWdU4OhxziZdhysiXq25VEIs813R7wSI7Ypb0scoJanOzpVVApNiwNLsCgFN9SEWAl Jqa2Ph+v4j9lVor5RRphtqpaUYSQcb2aducACiRt2hTYR4s4KQcXA+i8C/+mKsv30D+2 12Tg==
X-Gm-Message-State: ALoCoQlPsKzInGGQB4PhaZpqIrkAtVvplL7pQeO+864bsFwdvlq1iVRln78jnDUVs4j7EcG49xyv
X-Received: by 10.180.89.143 with SMTP id bo15mr4708375wib.78.1406133706656; Wed, 23 Jul 2014 09:41:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.217.128.12 with HTTP; Wed, 23 Jul 2014 09:41:06 -0700 (PDT)
X-Originating-IP: [2001:67c:370:144:cd58:8a9f:687b:f686]
In-Reply-To: <53CFCDB8.3020206@jitsi.org>
References: <53CFC899.6010307@jitsi.org>  <53CFCDB8.3020206@jitsi.org>
From: Eric Rescorla 
Date: Wed, 23 Jul 2014 09:41:06 -0700
Message-ID: 
To: Emil Ivov 
Content-Type: multipart/alternative; boundary=e89a8f3bab8717a68604fedf0447
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/pIGlBDwziDch_fLD7pXQTkjy41Y
Cc: RTCWEB 
Subject: Re: [rtcweb] Efficient crypto for conferences
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 16:41:50 -0000

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

On Wed, Jul 23, 2014 at 7:59 AM, Emil Ivov  wrote:

>
>
> On 23.07.14, 10:46, Eric Rescorla wrote:
>
>>
>>
>>
>> On Wed, Jul 23, 2014 at 7:37 AM, Emil Ivov > > wrote:
>>
>>     Hey all,
>>
>>     Lately, we have been working on SFU-based conferencing. SFUs and
>>     WebRTC go together quite well: SFUs scale beautifully and are very
>>     latency friendly which makes them great for cloud deployment.
>>
>>     But!
>>
>>     There is a glass ceiling currently that I was hoping we could discuss.
>>
>>     Performance.
>>
>>     Currently the only way an SFU can operate is by terminating
>>     DTLS/SRTP for every participant. This means decrypting and (worse)
>>     re-encrypting all traffic that traverses the SFU. This easily
>>     accounts for 90% of the CPU use on the SFU.
>>
>>     This is not a difficult problem to solve and AVTCORE even has a WG
>>     document that addresses it. It removes the need for decrypting and
>>     allows SFUs to just forward packets.
>>
>>     However, while chatting with many others in Toronto it appeared that
>>     most of us are focused on solving a slightly different problem:
>>
>>     Privacy.
>>
>>     Or in other words: making it impossible (as opposed to unnecessary)
>>     for SFUs to decrypt.
>>
>>     While this is a notable effort, it is also much more complex and
>>     parts of it (i.e. not requiring end users to trust their web
>>     provider) would be arguably very hard to solve.
>>
>>     Therefore, my question to the working group is: wouldn't it make
>>     sense to try and solve the efficiency issue as a first step and then
>>     worry about the privacy one on a later stage?
>>
>>
>> In what way is the efficiency issue not solved by EKT?
>>
>
> EKT is exactly the AVTCORE solution I was referring to.


In that case, I am in favor of this work. I think it also is a step towards
better privacy.

-Ekr


> Emil
>

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





On Wed, Jul 23, 2014 at 7:59 AM, Emil Ivov <emcho@jitsi.org><=
/span> wrote:







On 23.07.14, 10:46, Eric Rescorla wrote:









On Wed, Jul 23, 2014 at 7:37 AM, Emil Ivov <emcho@jitsi.org

<mailto:emcho@jitsi=
.org>> wrote:



=C2=A0 =C2=A0 Hey all,



=C2=A0 =C2=A0 Lately, we have been working on SFU-based conferencing. SFUs =
and

=C2=A0 =C2=A0 WebRTC go together quite well: SFUs scale beautifully and are=
 very

=C2=A0 =C2=A0 latency friendly which makes them great for cloud deployment.=




=C2=A0 =C2=A0 But!



=C2=A0 =C2=A0 There is a glass ceiling currently that I was hoping we could=
 discuss.



=C2=A0 =C2=A0 Performance.



=C2=A0 =C2=A0 Currently the only way an SFU can operate is by terminating
=C2=A0 =C2=A0 DTLS/SRTP for every participant. This means decrypting and (w=
orse)

=C2=A0 =C2=A0 re-encrypting all traffic that traverses the SFU. This easily=


=C2=A0 =C2=A0 accounts for 90% of the CPU use on the SFU.



=C2=A0 =C2=A0 This is not a difficult problem to solve and AVTCORE even has=
 a WG

=C2=A0 =C2=A0 document that addresses it. It removes the need for decryptin=
g and

=C2=A0 =C2=A0 allows SFUs to just forward packets.



=C2=A0 =C2=A0 However, while chatting with many others in Toronto it appear=
ed that

=C2=A0 =C2=A0 most of us are focused on solving a slightly different proble=
m:



=C2=A0 =C2=A0 Privacy.



=C2=A0 =C2=A0 Or in other words: making it impossible (as opposed to unnece=
ssary)

=C2=A0 =C2=A0 for SFUs to decrypt.



=C2=A0 =C2=A0 While this is a notable effort, it is also much more complex =
and

=C2=A0 =C2=A0 parts of it (i.e. not requiring end users to trust their web<=
br>
=C2=A0 =C2=A0 provider) would be arguably very hard to solve.



=C2=A0 =C2=A0 Therefore, my question to the working group is: wouldn't =
it make

=C2=A0 =C2=A0 sense to try and solve the efficiency issue as a first step a=
nd then

=C2=A0 =C2=A0 worry about the privacy one on a later stage?





In what way is the efficiency issue not solved by EKT?





EKT is exactly the AVTCORE solution I was referring to.
In that case, I am in favor of this work. I think it also is a=
 step towards
better privacy.

-Ekr



=C2=A0
Emil





--e89a8f3bab8717a68604fedf0447--


From nobody Wed Jul 23 10:30:53 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38501B2A1B; Wed, 23 Jul 2014 10:30:42 -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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIYCN2qcDvGm; Wed, 23 Jul 2014 10:30:39 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DA91B2A1C; Wed, 23 Jul 2014 10:30:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.2.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140723173022.20496.79339.idtracker@ietfa.amsl.com>
Date: Wed, 23 Jul 2014 10:30:22 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/oWIbauRJzEZkMBuUesonxt__Idc
Cc: rtcweb@ietf.org
Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-16.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 17:30:43 -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 Working Group of the IETF.

        Title           : Web Real-Time Communication (WebRTC): Media Transport and Use of RTP
        Authors         : Colin Perkins
                          Magnus Westerlund
                          Joerg Ott
	Filename        : draft-ietf-rtcweb-rtp-usage-16.txt
	Pages           : 44
	Date            : 2014-07-23

Abstract:
   The Web Real-Time Communication (WebRTC) framework provides support
   for direct interactive rich communication using audio, video, text,
   collaboration, games, etc.  between two peers' web-browsers.  This
   memo describes the media transport aspects of the WebRTC framework.
   It specifies how the Real-time Transport Protocol (RTP) is used in
   the WebRTC context, and gives requirements for which RTP features,
   profiles, and extensions need to be supported.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-16

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-rtp-usage-16


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

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


From nobody Wed Jul 23 10:36:20 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9AFA1B2BCD for ; Wed, 23 Jul 2014 10:36:16 -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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIz7NWfl2cgc for ; Wed, 23 Jul 2014 10:36:10 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C56171B2BBD for ; Wed, 23 Jul 2014 10:35:36 -0700 (PDT)
Received: from [130.209.254.13] (port=57137 helo=vpn13.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XA0Ry-0007iV-MP for rtcweb@ietf.org; Wed, 23 Jul 2014 18:35:35 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Colin Perkins 
In-Reply-To: <20140723173022.20496.79339.idtracker@ietfa.amsl.com>
Date: Wed, 23 Jul 2014 13:35:30 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20140723173022.20496.79339.idtracker@ietfa.amsl.com>
To: rtcweb@ietf.org
X-Mailer: Apple Mail (2.1878.6)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold =  On = 
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4XQIaRniNoulZIFIXZ5uzUGu1Zs
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-16.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 17:36:17 -0000

This version makes the two changes discussed this morning, to adds a =
reminder about discontinuous transmission to Section 4.1, and to make a =
clarification about use of multiple RTCP CNAMEs in Section 11.

There is no change to the section on FEC, but we will add a reference to =
a FEC draft is one is produced that has consensus.

Colin


On 23 Jul 2014, at 13:30, Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the Real-Time Communication in =
WEB-browsers Working Group of the IETF.
>=20
>        Title           : Web Real-Time Communication (WebRTC): Media =
Transport and Use of RTP
>        Authors         : Colin Perkins
>                          Magnus Westerlund
>                          Joerg Ott
> 	Filename        : draft-ietf-rtcweb-rtp-usage-16.txt
> 	Pages           : 44
> 	Date            : 2014-07-23
>=20
> Abstract:
>   The Web Real-Time Communication (WebRTC) framework provides support
>   for direct interactive rich communication using audio, video, text,
>   collaboration, games, etc.  between two peers' web-browsers.  This
>   memo describes the media transport aspects of the WebRTC framework.
>   It specifies how the Real-time Transport Protocol (RTP) is used in
>   the WebRTC context, and gives requirements for which RTP features,
>   profiles, and extensions need to be supported.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-16
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-16
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb



--=20
Colin Perkins
http://csperkins.org/




From nobody Wed Jul 23 10:59:48 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7C11B2C12 for ; Wed, 23 Jul 2014 10:59:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMYB_snYtm-Q for ; Wed, 23 Jul 2014 10:59:37 -0700 (PDT)
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02621B2BF9 for ; Wed, 23 Jul 2014 10:58:43 -0700 (PDT)
Received: by mail-wi0-f176.google.com with SMTP id bs8so8316018wib.3 for ; Wed, 23 Jul 2014 10:58:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=czNFxHQtr1xhbh1BEBo7FJNwdBdFLjtlvmXXlBx7aqA=; b=Z97VrF0WR0BefYnXNHCsp6JG7Ie2DrbN1GNunRVmZCmGJZzz74KB8kV8+3fw+R0El0 MHvw1b7cpoXHrTlafo209R4PkORYsSOOa5ubi2fldHFoevz2yQl6Q+m1cTuRfGTo1lRs dV9NLAh5Af9vaGmKVeBnyxh+4wEi7N8xxTtLf+Dt052fF5+4NYbcy9thhsD+vhmjyCYU E1vYaEhVSlA4eT8+sgyk0dCUFY8ICWs2Ss1kzWHt9wMnf5chczAKOm8vY0cPa9GxM1Yn Y1rWVfcwpWIrDAuvZDFDymkixRcSjUaNEnF/ruYlUO5GwHKa/pN1GQ4A6Xna0jNmbXN+ OEcg==
X-Gm-Message-State: ALoCoQl8o5S5J/02pErOhQtuOaoHPdBdA2NOCACAy7BaVPrVR3p0K9coVNVa+aMR11l9l/I3KjDw
X-Received: by 10.180.221.134 with SMTP id qe6mr5443266wic.66.1406138322228; Wed, 23 Jul 2014 10:58:42 -0700 (PDT)
Received: from dhcp-9b22.meeting.ietf.org (dhcp-9b22.meeting.ietf.org. [31.133.155.34]) by mx.google.com with ESMTPSA id cx5sm8157980wjb.8.2014.07.23.10.58.40 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 10:58:41 -0700 (PDT)
Message-ID: <53CFF7CF.7040705@jitsi.org>
Date: Wed, 23 Jul 2014 13:58:39 -0400
From: Emil Ivov 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Peter Thatcher 
References: <53CFC899.6010307@jitsi.org> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/B1OR_OkmZB8QXzu1k8VFjKCM4hk
Cc: RTCWEB 
Subject: Re: [rtcweb] Efficient crypto for conferences
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 17:59:43 -0000

On 23.07.14, 10:54, Peter Thatcher wrote:
> I'd be in favor of seeing if solving both is possible before in a good
> way before committing to a "first step" which might end up a dead-end.

Let's look at the privacy challenge though. First let's agree on who we 
are protecting from whom. Most of the solutions that are currently being 
mentioned here and there are about making sure that an SFU will not have 
the possibility to decrypt. It never sees the keys.

Well, while that does solve some part of the privacy concerns we should 
be aware that it does very little to guarantee privacy to end users.

In other words, consider a scenario where Alice connects to a video 
conference at SuperCollaboration.com. SuperCollaboration rely on 
CloudSFU.com for the actual conference support.

While not providing CloudSFU with the keys makes it easier for 
SuperCollaboration to trust and use them, it does nothing to protect 
Alice from SuperCollaboration performing MitM attacks on it. That is a 
much harder problem to solve (if at all with WebRTC).

On the other hand, making SFUs very lightweight (e.g., with EKT) would 
make it easier for Alice to deploy her own SFU on infrastructure that 
matches her security concerns, regardless of whether that means a VM she 
has root for, or a data center protected by her own private militia.

> In terms of timeline and scope, I think this is out of scope for
> WebRTC 1.0, so even a small "first step" might be quite a ways off.

The good thing about EKT is that it's already there, it's relatively 
straightforward and does not require a lot more spec work. It's 
primarily a matter of implementation. So it shouldn't be delaying anytihng.

Emil

>
> On Wed, Jul 23, 2014 at 7:37 AM, Emil Ivov  wrote:
>> Hey all,
>>
>> Lately, we have been working on SFU-based conferencing. SFUs and WebRTC go
>> together quite well: SFUs scale beautifully and are very latency friendly
>> which makes them great for cloud deployment.
>>
>> But!
>>
>> There is a glass ceiling currently that I was hoping we could discuss.
>>
>> Performance.
>>
>> Currently the only way an SFU can operate is by terminating DTLS/SRTP for
>> every participant. This means decrypting and (worse) re-encrypting all
>> traffic that traverses the SFU. This easily accounts for 90% of the CPU use
>> on the SFU.
>>
>> This is not a difficult problem to solve and AVTCORE even has a WG document
>> that addresses it. It removes the need for decrypting and allows SFUs to
>> just forward packets.
>>
>> However, while chatting with many others in Toronto it appeared that most of
>> us are focused on solving a slightly different problem:
>>
>> Privacy.
>>
>> Or in other words: making it impossible (as opposed to unnecessary) for SFUs
>> to decrypt.
>>
>> While this is a notable effort, it is also much more complex and parts of it
>> (i.e. not requiring end users to trust their web provider) would be arguably
>> very hard to solve.
>>
>> Therefore, my question to the working group is: wouldn't it make sense to
>> try and solve the efficiency issue as a first step and then worry about the
>> privacy one on a later stage?
>>
>> Emil
>>
>> --
>> https://jitsi.org
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>

-- 
https://jitsi.org


From nobody Wed Jul 23 11:41:16 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471CC1A034B for ; Wed, 23 Jul 2014 11:41:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.773
X-Spam-Level: 
X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=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 r6vI4NtzQon3 for ; Wed, 23 Jul 2014 11:41:14 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (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 1C5071B2846 for ; Wed, 23 Jul 2014 11:41:14 -0700 (PDT)
Received: from [31.133.172.38] (dhcp-ac26.meeting.ietf.org [31.133.172.38]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id F0483F22D3 for ; Wed, 23 Jul 2014 11:41:12 -0700 (PDT)
Message-ID: <53D001C8.4060703@mozilla.com>
Date: Wed, 23 Jul 2014 11:41:12 -0700
From: "Timothy B. Terriberry" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/H605uqpozKcFGyQLooDSOd7tDy0
Subject: [rtcweb] RFC 5109 IPR
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 18:41:15 -0000

It was mentioned in the meeting this morning that RFC 5109 has a couple 
of 3rd-party IPR disclosures:
https://datatracker.ietf.org/ipr/703/
https://datatracker.ietf.org/ipr/704/

I just wanted to point out that I looked up both patents on PAIR, and 
both have expired due to nonpayment of maintenance fees.


From nobody Wed Jul 23 11:51:14 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAB51B2AC2 for ; Wed, 23 Jul 2014 11:51:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKqxqByURnGN for ; Wed, 23 Jul 2014 11:51:10 -0700 (PDT)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9537F1A0347 for ; Wed, 23 Jul 2014 11:51:09 -0700 (PDT)
Received: by mail-wi0-f173.google.com with SMTP id f8so8310839wiw.12 for ; Wed, 23 Jul 2014 11:51:08 -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:content-type; bh=l4z275Rr+SMYtOluuOnpToPXCfH7SW70RLncOJ7VFn8=; b=ul6taCbIAxXloV15XTqicEuHBu6c9pYlL8GmdXAQQB7ecged2oI8WsDntDlOMJYGVz jpW0ya+EgbbgbKLHni6eBkY3a7RG8fdTLzUgvD1b3Zjyys8Lkfx3IPjcmhWGK4tvZEue 6G/ZkfDX1RIRl3C28jWI9lC/YYiYWY9pKA8fL6icdNbHPUlrOCutx+Ygn6pwFTfnLLPE cn9UbognILwmCSSghkPQtb6t21t6V+lR+fKFvEezDguARIc7lvcG4nYH/ARsO4IClN4U mB28pOPutQWfSVuOf8SLhHK3Ap+F8ukRUmhsyqf80A6W/pekNg69ba2TCxLzKU+QVvLi /vvw==
X-Received: by 10.194.92.115 with SMTP id cl19mr4567093wjb.29.1406141467991; Wed, 23 Jul 2014 11:51:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.217.122.65 with HTTP; Wed, 23 Jul 2014 11:50:47 -0700 (PDT)
In-Reply-To: <53CFF7CF.7040705@jitsi.org>
References: <53CFC899.6010307@jitsi.org>  <53CFF7CF.7040705@jitsi.org>
From: Bernard Aboba 
Date: Wed, 23 Jul 2014 14:50:47 -0400
Message-ID: 
To: Emil Ivov 
Content-Type: multipart/alternative; boundary=047d7bfcf88eb4261504fee0d2b7
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Ge_Thj0mcshVLds2GEUCEymIX9g
Cc: RTCWEB 
Subject: Re: [rtcweb] Efficient crypto for conferences
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 18:51:12 -0000

--047d7bfcf88eb4261504fee0d2b7
Content-Type: text/plain; charset=UTF-8

Emil said:

"While not providing CloudSFU with the keys makes it easier for
SuperCollaboration to trust and use them, it does nothing to protect Alice
from SuperCollaboration performing MitM attacks on it."

[BA] I think there is also additional questions:
a. Do we trust SuperCollaboration not to add additional participants to the
conference, or to forward information about the conference to an
unauthorized party?  Meta-data about the conference can be valuable.  To
use Jonathan's example, knowing that BigCompany X and potential acquisition
Y are in a conference is valuable information, even with no knowledge of
the media.
b. Do we trust the IdP to authenticate the participants, so that we can
verify that they are authorized to join the conference before providing
them with the keys?



On Wed, Jul 23, 2014 at 1:58 PM, Emil Ivov  wrote:

> On 23.07.14, 10:54, Peter Thatcher wrote:
>
>> I'd be in favor of seeing if solving both is possible before in a good
>> way before committing to a "first step" which might end up a dead-end.
>>
>
> Let's look at the privacy challenge though. First let's agree on who we
> are protecting from whom. Most of the solutions that are currently being
> mentioned here and there are about making sure that an SFU will not have
> the possibility to decrypt. It never sees the keys.
>
> Well, while that does solve some part of the privacy concerns we should be
> aware that it does very little to guarantee privacy to end users.
>
> In other words, consider a scenario where Alice connects to a video
> conference at SuperCollaboration.com. SuperCollaboration rely on
> CloudSFU.com for the actual conference support.
>
> While not providing CloudSFU with the keys makes it easier for
> SuperCollaboration to trust and use them, it does nothing to protect Alice
> from SuperCollaboration performing MitM attacks on it. That is a much
> harder problem to solve (if at all with WebRTC).
>
> On the other hand, making SFUs very lightweight (e.g., with EKT) would
> make it easier for Alice to deploy her own SFU on infrastructure that
> matches her security concerns, regardless of whether that means a VM she
> has root for, or a data center protected by her own private militia.
>
>
>  In terms of timeline and scope, I think this is out of scope for
>> WebRTC 1.0, so even a small "first step" might be quite a ways off.
>>
>
> The good thing about EKT is that it's already there, it's relatively
> straightforward and does not require a lot more spec work. It's primarily a
> matter of implementation. So it shouldn't be delaying anytihng.
>
> Emil
>
>
>
>> On Wed, Jul 23, 2014 at 7:37 AM, Emil Ivov  wrote:
>>
>>> Hey all,
>>>
>>> Lately, we have been working on SFU-based conferencing. SFUs and WebRTC
>>> go
>>> together quite well: SFUs scale beautifully and are very latency friendly
>>> which makes them great for cloud deployment.
>>>
>>> But!
>>>
>>> There is a glass ceiling currently that I was hoping we could discuss.
>>>
>>> Performance.
>>>
>>> Currently the only way an SFU can operate is by terminating DTLS/SRTP for
>>> every participant. This means decrypting and (worse) re-encrypting all
>>> traffic that traverses the SFU. This easily accounts for 90% of the CPU
>>> use
>>> on the SFU.
>>>
>>> This is not a difficult problem to solve and AVTCORE even has a WG
>>> document
>>> that addresses it. It removes the need for decrypting and allows SFUs to
>>> just forward packets.
>>>
>>> However, while chatting with many others in Toronto it appeared that
>>> most of
>>> us are focused on solving a slightly different problem:
>>>
>>> Privacy.
>>>
>>> Or in other words: making it impossible (as opposed to unnecessary) for
>>> SFUs
>>> to decrypt.
>>>
>>> While this is a notable effort, it is also much more complex and parts
>>> of it
>>> (i.e. not requiring end users to trust their web provider) would be
>>> arguably
>>> very hard to solve.
>>>
>>> Therefore, my question to the working group is: wouldn't it make sense to
>>> try and solve the efficiency issue as a first step and then worry about
>>> the
>>> privacy one on a later stage?
>>>
>>> Emil
>>>
>>> --
>>> https://jitsi.org
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>
>>
> --
> https://jitsi.org
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

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


Emil said:=C2=A0

"While not providing CloudSFU wi=
th the keys makes it easier for SuperCollaboration to trust and use them, i=
t does nothing to protect Alice from SuperCollaboration performing MitM att=
acks on it."




[BA] I think there is also additional questions:=C2=A0<=
/div>
a. Do we trust SuperCollaboration not to add additional participa=
nts to the conference, or to forward information about the conference to an=
 unauthorized party? =C2=A0Meta-data about the conference can be valuable. =
=C2=A0To use Jonathan's example, knowing that BigCompany X and potentia=
l acquisition Y are in a conference is valuable information, even with no k=
nowledge of the media.=C2=A0



b. Do we trust the IdP to authenticate the participants, so that we ca=
n verify that they are authorized to join the conference before providing t=
hem with the keys?=C2=A0





On Wed, Jul 23, 2014 at 1:58 PM, Emil Iv=
ov <emcho@jitsi.org> wrote:



On 23.07.14, 10:54, Peter Thatcher wrote:



I'd be in favor of seeing if solving both is possible before in a good<=
br>
way before committing to a "first step" which might end up a dead=
-end.





Let's look at the privacy challenge though. First let's agree on wh=
o we are protecting from whom. Most of the solutions that are currently bei=
ng mentioned here and there are about making sure that an SFU will not have=
 the possibility to decrypt. It never sees the keys.





Well, while that does solve some part of the privacy concerns we should be =
aware that it does very little to guarantee privacy to end users.



In other words, consider a scenario where Alice connects to a video confere=
nce at SuperCollaboration.com. SuperCollaboration rely on CloudSFU.com for =
the actual conference support.



While not providing CloudSFU with the keys makes it easier for SuperCollabo=
ration to trust and use them, it does nothing to protect Alice from SuperCo=
llaboration performing MitM attacks on it. That is a much harder problem to=
 solve (if at all with WebRTC).





On the other hand, making SFUs very lightweight (e.g., with EKT) would make=
 it easier for Alice to deploy her own SFU on infrastructure that matches h=
er security concerns, regardless of whether that means a VM she has root fo=
r, or a data center protected by her own private militia.








In terms of timeline and scope, I think this is out of scope for

WebRTC 1.0, so even a small "first step" might be quite a ways of=
f.





The good thing about EKT is that it's already there, it's relativel=
y straightforward and does not require a lot more spec work. It's prima=
rily a matter of implementation. So it shouldn't be delaying anytihng.<=
span class=3D"HOEnZb">





Emil








On Wed, Jul 23, 2014 at 7:37 AM, Emil Ivov <emcho@jitsi.org> wrote:



Hey all,



Lately, we have been working on SFU-based conferencing. SFUs and WebRTC go<=
br>
together quite well: SFUs scale beautifully and are very latency friendly
which makes them great for cloud deployment.



But!



There is a glass ceiling currently that I was hoping we could discuss.



Performance.



Currently the only way an SFU can operate is by terminating DTLS/SRTP for
every participant. This means decrypting and (worse) re-encrypting all

traffic that traverses the SFU. This easily accounts for 90% of the CPU use=


on the SFU.



This is not a difficult problem to solve and AVTCORE even has a WG document=


that addresses it. It removes the need for decrypting and allows SFUs to
just forward packets.



However, while chatting with many others in Toronto it appeared that most o=
f

us are focused on solving a slightly different problem:



Privacy.



Or in other words: making it impossible (as opposed to unnecessary) for SFU=
s

to decrypt.



While this is a notable effort, it is also much more complex and parts of i=
t

(i.e. not requiring end users to trust their web provider) would be arguabl=
y

very hard to solve.



Therefore, my question to the working group is: wouldn't it make sense =
to

try and solve the efficiency issue as a first step and then worry about the=


privacy one on a later stage?



Emil



--

https://jitsi.org



_______________________________________________

rtcweb mailing list

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









-- 

https://jitsi.org



_______________________________________________

rtcweb mailing list

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





--047d7bfcf88eb4261504fee0d2b7--


From nobody Wed Jul 23 11:54:05 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFC71A00E9 for ; Wed, 23 Jul 2014 11:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.902
X-Spam-Level: 
X-Spam-Status: No, score=-13.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9trpopLVEpdX for ; Wed, 23 Jul 2014 11:54:01 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5267C1A0347 for ; Wed, 23 Jul 2014 11:54:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4445; q=dns/txt; s=iport; t=1406141641; x=1407351241; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=eGEt9bD+7Jr09qg/zMxZv3rEnKtNZJKyl4/bNOTl7ec=; b=T36sXtuoQs73i6WPSJsCBWZbIGg7kCF215QwWGDG/Wvqb0v3pAqvobDc z31BI8VnSPdPw0Cu7ismEPeu0BWcDp1RznsUvUHXiXIRw+EkbRC58kwJ3 QWt08M5774kgWa/dFs8PmtuTBOJ/F2knyBct/T11Li55/S6ZJQ6MhOv/P U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhwFALYD0FOtJA2D/2dsb2JhbABQCYMOUlfHXwqGclMBgQsWdoQDAQEBAwEBAQE3LgYGBQULCw4KLicwBhMbiB8IDcAAF45pBwoBHTMHgy6BGAWbLYFShUuNI4NkIS+BBQcXBg
X-IronPort-AV: E=Sophos;i="5.01,718,1400025600"; d="scan'208";a="342281526"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP; 23 Jul 2014 18:54:00 +0000
Received: from [10.21.73.60] ([10.21.73.60]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6NIrsIE020527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Jul 2014 18:53:59 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Dan Wing 
In-Reply-To: <53CFF7CF.7040705@jitsi.org>
Date: Wed, 23 Jul 2014 14:54:13 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <15BF79BE-E535-4BF4-B357-F40FE949B859@cisco.com>
References: <53CFC899.6010307@jitsi.org>  <53CFF7CF.7040705@jitsi.org>
To: Emil Ivov 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_v6CenWmGRhi9c0tQ2C96Rtc2Gs
Cc: RTCWEB 
Subject: Re: [rtcweb] Efficient crypto for conferences
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 18:54:04 -0000

On Jul 23, 2014, at 1:58 PM, Emil Ivov  wrote:

> On 23.07.14, 10:54, Peter Thatcher wrote:
>> I'd be in favor of seeing if solving both is possible before in a =
good
>> way before committing to a "first step" which might end up a =
dead-end.
>=20
> Let's look at the privacy challenge though. First let's agree on who =
we are protecting from whom. Most of the solutions that are currently =
being mentioned here and there are about making sure that an SFU will =
not have the possibility to decrypt. It never sees the keys.
>=20
> Well, while that does solve some part of the privacy concerns we =
should be aware that it does very little to guarantee privacy to end =
users.
>=20
> In other words, consider a scenario where Alice connects to a video =
conference at SuperCollaboration.com. SuperCollaboration rely on =
CloudSFU.com for the actual conference support.
>=20
> While not providing CloudSFU with the keys makes it easier for =
SuperCollaboration to trust and use them, it does nothing to protect =
Alice from SuperCollaboration performing MitM attacks on it. That is a =
much harder problem to solve (if at all with WebRTC).

I believe the weakness is how identity is provided.  If =
SuperCollaboration.com provides identity over the a=3Dfingerprint's, it =
could be lying and if it provides the Javascript to do identity =
generation/validation, it is probably as weak as Javascript encrypting =
email.  Perhaps part of all of the identity generation/validation needs =
to be done by the browser (rather than Javascript) much like some of the =
ICE transaction is done by the browser (and inaccessible to Javascript) =
such as the ICE transaction-id.

-d


>=20
> On the other hand, making SFUs very lightweight (e.g., with EKT) would =
make it easier for Alice to deploy her own SFU on infrastructure that =
matches her security concerns, regardless of whether that means a VM she =
has root for, or a data center protected by her own private militia.
>=20
>> In terms of timeline and scope, I think this is out of scope for
>> WebRTC 1.0, so even a small "first step" might be quite a ways off.
>=20
> The good thing about EKT is that it's already there, it's relatively =
straightforward and does not require a lot more spec work. It's =
primarily a matter of implementation. So it shouldn't be delaying =
anytihng.
>=20
> Emil
>=20
>>=20
>> On Wed, Jul 23, 2014 at 7:37 AM, Emil Ivov  wrote:
>>> Hey all,
>>>=20
>>> Lately, we have been working on SFU-based conferencing. SFUs and =
WebRTC go
>>> together quite well: SFUs scale beautifully and are very latency =
friendly
>>> which makes them great for cloud deployment.
>>>=20
>>> But!
>>>=20
>>> There is a glass ceiling currently that I was hoping we could =
discuss.
>>>=20
>>> Performance.
>>>=20
>>> Currently the only way an SFU can operate is by terminating =
DTLS/SRTP for
>>> every participant. This means decrypting and (worse) re-encrypting =
all
>>> traffic that traverses the SFU. This easily accounts for 90% of the =
CPU use
>>> on the SFU.
>>>=20
>>> This is not a difficult problem to solve and AVTCORE even has a WG =
document
>>> that addresses it. It removes the need for decrypting and allows =
SFUs to
>>> just forward packets.
>>>=20
>>> However, while chatting with many others in Toronto it appeared that =
most of
>>> us are focused on solving a slightly different problem:
>>>=20
>>> Privacy.
>>>=20
>>> Or in other words: making it impossible (as opposed to unnecessary) =
for SFUs
>>> to decrypt.
>>>=20
>>> While this is a notable effort, it is also much more complex and =
parts of it
>>> (i.e. not requiring end users to trust their web provider) would be =
arguably
>>> very hard to solve.
>>>=20
>>> Therefore, my question to the working group is: wouldn't it make =
sense to
>>> try and solve the efficiency issue as a first step and then worry =
about the
>>> privacy one on a later stage?
>>>=20
>>> Emil
>>>=20
>>> --
>>> https://jitsi.org
>>>=20
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>=20
>=20
> --=20
> https://jitsi.org
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From nobody Wed Jul 23 12:36:08 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0001B2C94 for ; Wed, 23 Jul 2014 12:36:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opGDaO84n8Qp for ; Wed, 23 Jul 2014 12:36:05 -0700 (PDT)
Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB5DD1B2C98 for ; Wed, 23 Jul 2014 12:36:04 -0700 (PDT)
Received: by mail-ig0-f180.google.com with SMTP id l13so1830903iga.13 for ; Wed, 23 Jul 2014 12:36:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VjEwR3fD0dIMNEsw7tNDknWfDqS1Zfu9Unm+r4FdRfI=; b=Y87v58OsKPXPmtfa9CT3wOrKPOiLUNyeXoeos0yVQB9my01EzXkS2ce+KoXwqM+XRr d7HdyW2E15csugulYLe6Ysv2AjaSsQxgSLiJMNLZMqmIGUFOwwrlh5JSb4JIz7Juswdk DK6fwqBTL5Ifbs9EEW+6KTztp5WIRpyECyBikuTLcTAFkz4AIcgc0xdmUpyj34qQq8om snRlY+jGHrizx3v6pTFCG63shySPs2G0Utoegv1hLhGc5DxFBI9SedIhF9BayFTOwcqB NxNobZP6kx7h63e2Gm2ogvHGYPiSHjJiah34eJsBZP3vryrvb60r/++PkzV/xjZiqlht GyCQ==
MIME-Version: 1.0
X-Received: by 10.42.154.132 with SMTP id q4mr5995256icw.4.1406144164001; Wed, 23 Jul 2014 12:36:04 -0700 (PDT)
Received: by 10.43.154.80 with HTTP; Wed, 23 Jul 2014 12:36:03 -0700 (PDT)
In-Reply-To: <53CFF7CF.7040705@jitsi.org>
References: <53CFC899.6010307@jitsi.org>  <53CFF7CF.7040705@jitsi.org>
Date: Wed, 23 Jul 2014 15:36:03 -0400
Message-ID: 
From: Ted Hardie 
To: Emil Ivov 
Content-Type: multipart/alternative; boundary=90e6ba6e87a665fe8604fee173c4
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GV9IP5YRd88dc0F1Qf4jlWRMdbg
Cc: RTCWEB 
Subject: Re: [rtcweb] Efficient crypto for conferences
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 19:36:07 -0000

--90e6ba6e87a665fe8604fee173c4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 23, 2014 at 1:58 PM, Emil Ivov  wrote:

> On 23.07.14, 10:54, Peter Thatcher wrote:
>
>> I'd be in favor of seeing if solving both is possible before in a good
>> way before committing to a "first step" which might end up a dead-end.
>>
>
> Let's look at the privacy challenge though. First let's agree on who we
> are protecting from whom. Most of the solutions that are currently being
> mentioned here and there are about making sure that an SFU will not have
> the possibility to decrypt. It never sees the keys.
>
> Well, while that does solve some part of the privacy concerns we should b=
e
> aware that it does very little to guarantee privacy to end users.
>
> In other words, consider a scenario where Alice connects to a video
> conference at SuperCollaboration.com. SuperCollaboration rely on
> CloudSFU.com for the actual conference support.
>
> While not providing CloudSFU with the keys makes it easier for
> SuperCollaboration to trust and use them, it does nothing to protect Alic=
e
> from SuperCollaboration performing MitM attacks on

it. That is a much harder problem to solve (if at all with WebRTC).
>
>
=E2=80=8BSorry, what MitM attack are you looking at here?  In the example I=
 thought
you were giving, SuperCollaboration has the keys but CloudSFU is the entity
on path.  What am I getting wrong?

Ted=E2=80=8B



> On the other hand, making SFUs very lightweight (e.g., with EKT) would
> make it easier for Alice to deploy her own SFU on infrastructure that
> matches her security concerns, regardless of whether that means a VM she
> has root for, or a data center protected by her own private militia.
>
>
>  In terms of timeline and scope, I think this is out of scope for
>> WebRTC 1.0, so even a small "first step" might be quite a ways off.
>>
>
> The good thing about EKT is that it's already there, it's relatively
> straightforward and does not require a lot more spec work. It's primarily=
 a
> matter of implementation. So it shouldn't be delaying anytihng.
>
> Emil
>
>
>
>> On Wed, Jul 23, 2014 at 7:37 AM, Emil Ivov  wrote:
>>
>>> Hey all,
>>>
>>> Lately, we have been working on SFU-based conferencing. SFUs and WebRTC
>>> go
>>> together quite well: SFUs scale beautifully and are very latency friend=
ly
>>> which makes them great for cloud deployment.
>>>
>>> But!
>>>
>>> There is a glass ceiling currently that I was hoping we could discuss.
>>>
>>> Performance.
>>>
>>> Currently the only way an SFU can operate is by terminating DTLS/SRTP f=
or
>>> every participant. This means decrypting and (worse) re-encrypting all
>>> traffic that traverses the SFU. This easily accounts for 90% of the CPU
>>> use
>>> on the SFU.
>>>
>>> This is not a difficult problem to solve and AVTCORE even has a WG
>>> document
>>> that addresses it. It removes the need for decrypting and allows SFUs t=
o
>>> just forward packets.
>>>
>>> However, while chatting with many others in Toronto it appeared that
>>> most of
>>> us are focused on solving a slightly different problem:
>>>
>>> Privacy.
>>>
>>> Or in other words: making it impossible (as opposed to unnecessary) for
>>> SFUs
>>> to decrypt.
>>>
>>> While this is a notable effort, it is also much more complex and parts
>>> of it
>>> (i.e. not requiring end users to trust their web provider) would be
>>> arguably
>>> very hard to solve.
>>>
>>> Therefore, my question to the working group is: wouldn't it make sense =
to
>>> try and solve the efficiency issue as a first step and then worry about
>>> the
>>> privacy one on a later stage?
>>>
>>> Emil
>>>
>>> --
>>> https://jitsi.org
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>
>>
> --
> https://jitsi.org
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

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



On Wed, Jul 23=
, 2014 at 1:58 PM, Emil Ivov <emcho@jitsi.org> wrote:


O=
n 23.07.14, 10:54, Peter Thatcher wrote:



I'd be in favor of seeing if solving both is possible before in a good<=
br>
way before committing to a "first step" which might end up a dead=
-end.





Let's look at the privacy challenge though. First let's agree on wh=
o we are protecting from whom. Most of the solutions that are currently bei=
ng mentioned here and there are about making sure that an SFU will not have=
 the possibility to decrypt. It never sees the keys.




Well, while that does solve some part of the privacy concerns we should be =
aware that it does very little to guarantee privacy to end users.



In other words, consider a scenario where Alice connects to a video confere=
nce at SuperCollaboration.com. SuperCollaboration rely on CloudSFU.com for =
the actual conference support.



While not providing CloudSFU with the keys makes it easier for SuperCollabo=
ration to trust and use them, it does nothing to protect Alice from SuperCo=
llaboration performing MitM attacks on=C2=A0

it. That is a much harder problem to solve (if at all with WebRTC).



=E2=80=8BSorry, what MitM attack are you l=
ooking at here?=C2=A0 In the example I thought you were giving, SuperCollab=
oration has the keys but CloudSFU is the entity on path.=C2=A0 What am I ge=
tting wrong?


Ted=E2=80=8B

=C2=A0

On the other hand, making SFUs very lightweight (e.g., with EKT) would make=
 it easier for Alice to deploy her own SFU on infrastructure that matches h=
er security concerns, regardless of whether that means a VM she has root fo=
r, or a data center protected by her own private militia.







In terms of timeline and scope, I think this is out of scope for

WebRTC 1.0, so even a small "first step" might be quite a ways of=
f.





The good thing about EKT is that it's already there, it's relativel=
y straightforward and does not require a lot more spec work. It's prima=
rily a matter of implementation. So it shouldn't be delaying anytihng.<=
span class=3D"HOEnZb">




Emil








On Wed, Jul 23, 2014 at 7:37 AM, Emil Ivov <emcho@jitsi.org> wrote:



Hey all,



Lately, we have been working on SFU-based conferencing. SFUs and WebRTC go<=
br>
together quite well: SFUs scale beautifully and are very latency friendly
which makes them great for cloud deployment.



But!



There is a glass ceiling currently that I was hoping we could discuss.



Performance.



Currently the only way an SFU can operate is by terminating DTLS/SRTP for
every participant. This means decrypting and (worse) re-encrypting all

traffic that traverses the SFU. This easily accounts for 90% of the CPU use=


on the SFU.



This is not a difficult problem to solve and AVTCORE even has a WG document=


that addresses it. It removes the need for decrypting and allows SFUs to
just forward packets.



However, while chatting with many others in Toronto it appeared that most o=
f

us are focused on solving a slightly different problem:



Privacy.



Or in other words: making it impossible (as opposed to unnecessary) for SFU=
s

to decrypt.



While this is a notable effort, it is also much more complex and parts of i=
t

(i.e. not requiring end users to trust their web provider) would be arguabl=
y

very hard to solve.



Therefore, my question to the working group is: wouldn't it make sense =
to

try and solve the efficiency issue as a first step and then worry about the=


privacy one on a later stage?



Emil



--

https://jitsi.org



_______________________________________________

rtcweb mailing list

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









-- 

https://jitsi.org



_______________________________________________

rtcweb mailing list

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





--90e6ba6e87a665fe8604fee173c4--


From nobody Wed Jul 23 13:57:59 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 929F41A02D7 for ; Wed, 23 Jul 2014 13:57:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yQUktPxmBkH for ; Wed, 23 Jul 2014 13:57:56 -0700 (PDT)
Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D2881A0033 for ; Wed, 23 Jul 2014 13:57:56 -0700 (PDT)
Received: by mail-we0-f176.google.com with SMTP id q58so1751917wes.35 for ; Wed, 23 Jul 2014 13:57:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1kB09tmUJgCgQafTSD2P3RBWrv5nX+qK8C95AzR4Exs=; b=eWRODs87NAf0XrIsEQ3UNbn6JhACnW4Z3mhGZR2q2P8LtFfYCV5BmTqZJhGDUXwyZo 9puQjWB57A4gZpYr1TkuMPWCahm14VWM6RrhJRBHDzCBkVZpOPvOWLCqHk1W19CMkjYP Xiv9fjOqCwxVhRQQqs/AzhZMG+KvZ/WZCg25xMk8ODoIX+cc+HNlV7/1JKgIBJVJRYl6 uOWawaDYSyqCHpPZZD+qJfLdDM4f/MsNTzG5ZIsY0XWicmreGw0n7q9nXfsBcYgbLSG3 nEeX84kJyDQUpbV4nP3VRjeqEZUj+RsN2dfhf4JjYGsjyzRUeTyiG+F/oStJN3m5hLun 5RsQ==
X-Gm-Message-State: ALoCoQnQbEelLMvs1dNZB7P1EHH+Ot3U9+gB8LSHSkf+FlR2hxEwLpFT4kDGbfCPNfxcjQ1s0IWO
X-Received: by 10.194.6.10 with SMTP id w10mr5424526wjw.51.1406149074372; Wed, 23 Jul 2014 13:57:54 -0700 (PDT)
Received: from dhcp-97e2.meeting.ietf.org (dhcp-97e2.meeting.ietf.org. [31.133.151.226]) by mx.google.com with ESMTPSA id w10sm13507667wie.22.2014.07.23.13.57.52 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 13:57:53 -0700 (PDT)
Message-ID: <53D021CB.2080100@jitsi.org>
Date: Wed, 23 Jul 2014 16:57:47 -0400
From: Emil Ivov 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ted Hardie 
References: <53CFC899.6010307@jitsi.org>		<53CFF7CF.7040705@jitsi.org> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3m7cx82vuo-ha6nA2rcoXqw8sw4
Cc: RTCWEB 
Subject: Re: [rtcweb] Efficient crypto for conferences
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Jul 2014 20:57:58 -0000

On 23.07.14, 15:36, Ted Hardie wrote:
>
> On Wed, Jul 23, 2014 at 1:58 PM, Emil Ivov  > wrote:
>
>     On 23.07.14, 10:54, Peter Thatcher wrote:
>
>         I'd be in favor of seeing if solving both is possible before in
>         a good
>         way before committing to a "first step" which might end up a
>         dead-end.
>
>
>     Let's look at the privacy challenge though. First let's agree on who
>     we are protecting from whom. Most of the solutions that are
>     currently being mentioned here and there are about making sure that
>     an SFU will not have the possibility to decrypt. It never sees the keys.
>
>     Well, while that does solve some part of the privacy concerns we
>     should be aware that it does very little to guarantee privacy to end
>     users.
>
>     In other words, consider a scenario where Alice connects to a video
>     conference at SuperCollaboration.com. SuperCollaboration rely on
>     CloudSFU.com for the actual conference support.
>
>     While not providing CloudSFU with the keys makes it easier for
>     SuperCollaboration to trust and use them, it does nothing to protect
>     Alice from SuperCollaboration performing MitM attacks on
>
>     it. That is a much harder problem to solve (if at all with WebRTC).
>
>
> ​Sorry, what MitM attack are you looking at here?  In the example I
> thought you were giving, SuperCollaboration has the keys but CloudSFU is
> the entity on path.  What am I getting wrong?

I was referring to the fact that since SupperCollaboration controls the 
signalling, it can silently put itself on the path between the browser 
and CloudSFU and terminate encryption.

Emil

> Ted​
>
>     On the other hand, making SFUs very lightweight (e.g., with EKT)
>     would make it easier for Alice to deploy her own SFU on
>     infrastructure that matches her security concerns, regardless of
>     whether that means a VM she has root for, or a data center protected
>     by her own private militia.
>
>
>         In terms of timeline and scope, I think this is out of scope for
>         WebRTC 1.0, so even a small "first step" might be quite a ways off.
>
>
>     The good thing about EKT is that it's already there, it's relatively
>     straightforward and does not require a lot more spec work. It's
>     primarily a matter of implementation. So it shouldn't be delaying
>     anytihng.
>
>     Emil
>
>
>
>         On Wed, Jul 23, 2014 at 7:37 AM, Emil Ivov          > wrote:
>
>             Hey all,
>
>             Lately, we have been working on SFU-based conferencing. SFUs
>             and WebRTC go
>             together quite well: SFUs scale beautifully and are very
>             latency friendly
>             which makes them great for cloud deployment.
>
>             But!
>
>             There is a glass ceiling currently that I was hoping we
>             could discuss.
>
>             Performance.
>
>             Currently the only way an SFU can operate is by terminating
>             DTLS/SRTP for
>             every participant. This means decrypting and (worse)
>             re-encrypting all
>             traffic that traverses the SFU. This easily accounts for 90%
>             of the CPU use
>             on the SFU.
>
>             This is not a difficult problem to solve and AVTCORE even
>             has a WG document
>             that addresses it. It removes the need for decrypting and
>             allows SFUs to
>             just forward packets.
>
>             However, while chatting with many others in Toronto it
>             appeared that most of
>             us are focused on solving a slightly different problem:
>
>             Privacy.
>
>             Or in other words: making it impossible (as opposed to
>             unnecessary) for SFUs
>             to decrypt.
>
>             While this is a notable effort, it is also much more complex
>             and parts of it
>             (i.e. not requiring end users to trust their web provider)
>             would be arguably
>             very hard to solve.
>
>             Therefore, my question to the working group is: wouldn't it
>             make sense to
>             try and solve the efficiency issue as a first step and then
>             worry about the
>             privacy one on a later stage?
>
>             Emil
>
>             --
>             https://jitsi.org
>
>             _________________________________________________
>             rtcweb mailing list
>             rtcweb@ietf.org 
>             https://www.ietf.org/mailman/__listinfo/rtcweb
>             
>
>
>
>     --
>     https://jitsi.org
>
>     _________________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org 
>     https://www.ietf.org/mailman/__listinfo/rtcweb
>     
>
>

-- 
https://jitsi.org


From nobody Wed Jul 23 19:38:04 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A01A1A0151 for ; Wed, 23 Jul 2014 19:38:01 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mZpFvUt49Vp for ; Wed, 23 Jul 2014 19:37:57 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36BE91A0A9E for ; Wed, 23 Jul 2014 19:37:57 -0700 (PDT)
X-AuditID: c1b4fb3a-f79a36d000000ffa-27-53d071829881
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 81.DE.04090.28170D35; Thu, 24 Jul 2014 04:37:55 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Thu, 24 Jul 2014 04:37:54 +0200
From: Christer Holmberg 
To: "rtcweb@ietf.org" 
Thread-Topic: POF/PAN in JSEP?
Thread-Index: Ac+m55avcFNbGARHRFWSaqm+zzwndQ==
Date: Thu, 24 Jul 2014 02:37:53 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3D1B56@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D3D1B56ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+JvjW5z4YVgg9P/mS3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqVHu5gLDkpX7H/TzNbAOEWii5GTQ0LAROL0vFvMELaYxIV7 69lAbCGBo4wSe+bWdjFyAdmLGCUWfL0PlODgYBOwkOj+pw1SIyKgLnH54QV2EFtYQFLi9aMG Zoi4nMT131NYIWw9iYZzz1lAbBYBVYm/hyaygIzhFfCVuLBBCiTMCLT2+6k1TCA2s4C4xK0n 85kgzhGQWLLnPNRpohIvH/9jhbCVJNYe3s4CUZ8vceDaNrA4r4CgxMmZT1gmMArNQjJqFpKy WUjKIOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypG0eLU4uLcdCMjvdSizOTi4vw8vbzU kk2MwHg4uOW31Q7Gg88dDzEKcDAq8fA+2H8+WIg1say4MvcQozQHi5I478Jz84KFBNITS1Kz U1MLUovii0pzUosPMTJxcEo1MHJPDJv0vXLm/D6X00dWbehV+hNwes2UlshLm2/f8TPlk2kq sNp2p2CToGGOeILg6WPW/o/7Uru7DoU3un7cFdl6TU3lrsDD8D0zTmZr1J4prdUIDxbk/GJY KbJxpSjrtNk3lQIdtwbuyFfKU7aQTlpzu/Z5+N7eOfwMd6USLNO+Rez7tt5dV4mlOCPRUIu5 qDgRAAckPWNoAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zjNynWxxgXm4SoDSuUUT6by5VEw
Subject: [rtcweb] POF/PAN in JSEP?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 02:38:01 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1D3D1B56ESESSMB209erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
Are we still planning to incorporate support of POF/PAN (partial offers/ans=
wers) into JSEP?

AFAIK, the work on POF/PAN hasn't progressed. In addition, I believe (pleas=
e correct me if I'm wrong) it would have a major impact on the JSEP state m=
achine, as it currently is defined to deal with complete SDPs - not individ=
ual parts of SDP.
If JSEP will not support POF/PAN, perhaps it would be good to have explicit=
 text indicating that.

Thanks!
Regards,
Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D3D1B56ESESSMB209erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,




Are we still planning to incorporate support of POF/=
PAN (partial offers/answers) into JSEP?


 


AFAIK, the work on POF/PAN hasn’t progressed. =
In addition, I believe (please correct me if I’m wrong) it would have=
 a major impact on the JSEP state machine, as it currently is defined to de=
al with complete SDPs – not individual parts of
 SDP.




If JSEP will not support POF/PAN, perhaps it would b=
e good to have explicit text indicating that.


 


Thanks!




Regards,




Christer






--_000_7594FB04B1934943A5C02806D1A2204B1D3D1B56ESESSMB209erics_--


From nobody Wed Jul 23 20:50:28 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6520B1A0AA1 for ; Wed, 23 Jul 2014 20:50:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 PVtx3hEzoP5E for ; Wed, 23 Jul 2014 20:50:19 -0700 (PDT)
Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 668DB1A0AC6 for ; Wed, 23 Jul 2014 20:50:19 -0700 (PDT)
Received: by mail-vc0-f179.google.com with SMTP id hq11so3920702vcb.38 for ; Wed, 23 Jul 2014 20:50:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qdDuJYM3U8QKvduuyoEchVAdZHwxNmtSJ3+I34UtrrE=; b=Gkof8r6Y+WZVmvj8zmesZdZ6xFCj+KlZz+BxXEuGJPXiHtFuue/2BlQoICuesyAOn+ 8h6WvKGKKLDAarjhC0LPoK41Hetk1GpSqdbZ8U/YT3HLmoYd3XROusG8aXu54eBj/k82 lpkiepsb0jAQO76k35xguV6FX5IXKPrhh++CaW/HrHsxHLsfCg86+NITKp9vv3LhTh5w 1Rm5uYSSRpUoMTdFyR+Xpt4vdg4hMh/VhvLl7aQyDKqv8V5BG5JNuGptHjfZClj+vePt NsVKdjCMls0FbkyjbotClyC2LOURFyqBUHKgjUnomuRacBN5wiIrpYdu+Dp9UDYm6nuu iuFQ==
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:content-type; bh=qdDuJYM3U8QKvduuyoEchVAdZHwxNmtSJ3+I34UtrrE=; b=AZfJhthMnJLTN5JfWSBMAM+OTNsOyF++vinOXVYrRWQjfk8v9RMXMpeeyJqhgLrbdI vaX4AnTYXmglk7Du2vjfwrFQiBATwoGir6wDTNpVik+iJTJIF/FOE/zJqroTh3KiP+XA L+i702fQpUWj/HzBIP72CwaY8FPGLmTuseokB9laOGQrBtt/BVuRHbW8mhf03NakviA4 rwGNlGpE1kEYeIHZGd2LLjBaNfx5HcbXUDnYeVQRtDU7/Mh/coWE6buKZPECOGGXGjat Vyn8BZEVF+DRBABhj+mIc/sEKxw3p3ZkWudrcjiVFlFKhUG9wzQJ0fP5c8IsiDa+5XvJ j5Ig==
X-Gm-Message-State: ALoCoQmFoVFaquhtay6DZrH/SFqJUzZUMOnYENCyvQyO/mId558ISHbG4Fq+yCuDlpH36ChMFl1l
X-Received: by 10.52.135.133 with SMTP id ps5mr6596790vdb.33.1406173817584; Wed, 23 Jul 2014 20:50:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.4.70 with HTTP; Wed, 23 Jul 2014 20:49:57 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D3D1B56@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1D3D1B56@ESESSMB209.ericsson.se>
From: Justin Uberti 
Date: Wed, 23 Jul 2014 23:49:57 -0400
Message-ID: 
To: Christer Holmberg 
Content-Type: multipart/alternative; boundary=bcaec51a70a2e3e8aa04fee85abe
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QpEnnCB6Ays47xWI2xoOP9HEFmg
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] POF/PAN in JSEP?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 03:50:20 -0000

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

Not in 1.0.


On Wed, Jul 23, 2014 at 10:37 PM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

>  Hi,
>
>  Are we still planning to incorporate support of POF/PAN (partial
> offers/answers) into JSEP?
>
>
>
> AFAIK, the work on POF/PAN hasn=E2=80=99t progressed. In addition, I beli=
eve
> (please correct me if I=E2=80=99m wrong) it would have a major impact on =
the JSEP
> state machine, as it currently is defined to deal with complete SDPs =E2=
=80=93 not
> individual parts of SDP.
>
>  If JSEP will not support POF/PAN, perhaps it would be good to have
> explicit text indicating that.
>
>
>
> Thanks!
>
>  Regards,
>
>  Christer
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

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


Not in 1.0.


On Wed, Jul 23, 2014 at 10:37 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:














Hi,




Are we still planning to incorporate support of POF/=
PAN (partial offers/answers) into JSEP?


=C2=A0


AFAIK, the work on POF/PAN hasn=E2=80=99t progressed=
. In addition, I believe (please correct me if I=E2=80=99m wrong) it would =
have a major impact on the JSEP state machine, as it currently is defined t=
o deal with complete SDPs =E2=80=93 not individual parts of
 SDP.




If JSEP will not support POF/PAN, perhaps it would b=
e good to have explicit text indicating that.


=C2=A0


Thanks!




Regards,




Christer







_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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





--bcaec51a70a2e3e8aa04fee85abe--


From nobody Wed Jul 23 21:16:20 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D0E1B2798 for ; Wed, 23 Jul 2014 21:16:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.635
X-Spam-Level: 
X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, SPF_SOFTFAIL=0.665] autolearn=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 idaHJ014-j98 for ; Wed, 23 Jul 2014 21:16:16 -0700 (PDT)
Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 25FA61ABB90 for ; Wed, 23 Jul 2014 21:16:16 -0700 (PDT)
Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta12.westchester.pa.mail.comcast.net with comcast id W4B51o0051ap0As5C4GFaa; Thu, 24 Jul 2014 04:16:15 +0000
Received: from dhcp-90b7.meeting.ietf.org ([31.133.144.183]) by omta22.westchester.pa.mail.comcast.net with comcast id W4E31o00G3xdsjB3i4E5kd; Thu, 24 Jul 2014 04:14:12 +0000
Message-ID: <53D0880B.70401@alum.mit.edu>
Date: Thu, 24 Jul 2014 00:14:03 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Justin Uberti 
References:   <53CEFA2C.8040407@nteczone.com> <53CFA92F.5070306@alum.mit.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1406175375; bh=Q1BBesimaMygy+e+TQIiLVtshFsqIsdJrKfVXWUbjCw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DqKKhJzeWt/ywW6Y6OeWpXd/8nRKTB6m/hZWAI+PMKpjyBKe0UWxfBTFl8K7sWbEf Kb7cCO3Gywtm/XbOYQbtDnvI6kM67rd6bjEVj3z7h/dGwYBisJ56xj7ea4r6EWPd8w Jcn0cu7NYzgVmuEv4WTjqixmqLpEp+anSXJt0xs9DdbGhkrXrnGs1XA1eJPwENt9wY 1UdILuMeyc0yyM2BxO8Qx5UmEy9ZYhAAh1fs6FGIJ94pUlv01Dw121PQzHGeXy7IbP C21XAhaim+MCHWQY9dqndHJziMtgzSvCqkA4lEjJH/iyconMnVrM/3+qbizYVaR7Vx PBhoOtJwvs2VA==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Y-EALrrLTEQcgHLx9HGjDR15qgA
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 04:16:17 -0000

On 7/23/14 9:19 AM, Justin Uberti wrote:
>
>
>
> On Wed, Jul 23, 2014 at 8:23 AM, Paul Kyzivat  > wrote:
>
>     On 7/22/14 7:56 PM, Christian Groves wrote:
>
>         The browser would delay the establishment of media that are part
>         of the
>         "a=group:clue" group until a CLUE exchange has taken place and those
>         media have been selected via a CLUE configure message. I'm not
>         sure if
>         that fits your criteria for acting differently?
>
>
>     I haven't thought about it much, but I think there are a couple of
>     ways to deal with that. One is to simply hide those from the browser
>     until the desired time. Another is to mark them as inactive for the
>     browser until configured.
>
>     A more difficult problem is that CLUE uses one-way media streams,
>     while jsep forces opposite direction ones to be merged into a single
>     sendrecv m-line. I don't know how to fix that.
>
>
> If you can demonstrate a specific problem that this causes, we can
> re-evaluate this. But we need to ensure that a simple phone call ends up
> with a single m=audio line.

The fundamental problem with this is that AFAICT it makes it impossible 
to build a WebRTC client that can interop with a CLUE server. I guess it 
would be possible with a special purpose media gateway that demuxed the 
clue media from sendrecv m-lines to sendonly & recvonly m-lines.

As another clue person said today, CLUE chose to use sendonly and 
recvonly m-lines so we could use the sendonly ones to provide SDP 
descriptions of what is available to be *sent*. (With sendrecv m-lines 
this describes only what is desired to be received.) Clue use cases are 
likely to be highly asymmetric, so it is essential to be able to do this.

Clue does have a solution for the simple phone, but it probably isn't a 
solution that would be satisfactory to rtcweb. The first O/A on a CLUE 
session assumes it doesn't know what it might be connecting to, and so 
makes an offer that is likely to work with "legacy" devices. Generally 
this would be one sendrecv audio and one sendrecv video, though YMMV. 
There are a few other things in there that allow the two ends to 
discover if they both can do clue after the first O/A.

If both do clue, then there is another O/A that provides sendonly 
m-lines for the offerer. And there will be a 3rd that provides sendonly 
m-lines by the other end. We consider this tolerable for telepresence.

The first O/A will also include DTLS/SCTP m-line that is intended to 
carry the CLUE data channel. (Assumed to be rejected by a "legacy" 
device.) While we don't require it, bundling is very attractive for 
clue. So if ICE has succeeded for that m-line, the subsequent O/As can 
add all those sendonly m-lines in the same bundle, so no new ice will be 
required.

	Thanks,
	Paul


From nobody Thu Jul 24 04:08:56 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DF31A01EB for ; Thu, 24 Jul 2014 04:08:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxwGN08p8dX8 for ; Thu, 24 Jul 2014 04:08:50 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DED7F1A01EE for ; Thu, 24 Jul 2014 04:08:49 -0700 (PDT)
X-AuditID: c1b4fb25-f79da6d000004ad3-f0-53d0e93f1d39
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C7.C5.19155.F39E0D35; Thu, 24 Jul 2014 13:08:47 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Thu, 24 Jul 2014 13:08:47 +0200
From: Christer Holmberg 
To: Justin Uberti 
Thread-Topic: [rtcweb] POF/PAN in JSEP?
Thread-Index: Ac+m55avcFNbGARHRFWSaqm+zzwndf//8/eAgACcIdo=
Date: Thu, 24 Jul 2014 11:08:45 +0000
Message-ID: 
References: <7594FB04B1934943A5C02806D1A2204B1D3D1B56@ESESSMB209.ericsson.se>,  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_xvg7ft2mtvlt0ru40klvgh271406200125343emailandroidcom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvja79ywvBBrcfyllsnSpksfZfO7sD k8eCTaUeS5b8ZApgiuKySUnNySxLLdK3S+DK+PdkJ2PBX9mKq9NPsjQwfpLsYuTkkBAwkfh9 bCszhC0mceHeerYuRi4OIYGjjBLbp51ih3AWMUq8/XoNKMPBwSZgIdH9TxukQURATeLhrF2s IDazgLrEncXn2EFsYaB449SVjBA16hKfL09kBWkVEbCSuD9TEsRkEVCVaGn2BKngFXCTWLSr jxFi0yRGib+7HzCC1HAKBErsmBwBUsMIdNr3U2uYIDaJS9x6Mp8J4mQBiSV7zkOdLyrx8vE/ qGtyJHYf/MgEMV9Q4uTMJywTGEVmIWmfhaRsFpIyiLiBxPtz85khbG2JZQtfQ9n6Ehu/nGVE Fl/AyL6KUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzCeDm75rbqD8fIbx0OMAhyMSjy8D/af DxZiTSwrrsw9xCjNwaIkzrvw3LxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwqvzUrmxas aa64Ui+1VCfphWf3v227gnbduFV/dUGV2enOwupbTIc9svtXOz4TWGN2yXHy93sW6qHSNz3S lnc+3PlFxCYo53tDwefoZmmB6Rcvhdx8qyzYEb5f78S2p6GZBbFpXLUPLcLPPFVOOm75pP/I mZQ/l+MnHTXzqu6/fazMM1hsW6YSS3FGoqEWc1FxIgDJtII4iAIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/l9hnCbCRzIfndH6ZBgLCAxlXmdQ
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] POF/PAN in JSEP?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 11:08:54 -0000

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

I support that. But, do we have a WG decision on such approach? I would not=
 want this to pop up in the last minute, during WGLC etc...

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Justin Uberti  wrote:



Not in 1.0.


On Wed, Jul 23, 2014 at 10:37 PM, Christer Holmberg > wrote:
Hi,
Are we still planning to incorporate support of POF/PAN (partial offers/ans=
wers) into JSEP?

AFAIK, the work on POF/PAN hasn=92t progressed. In addition, I believe (ple=
ase correct me if I=92m wrong) it would have a major impact on the JSEP sta=
te machine, as it currently is defined to deal with complete SDPs =96 not i=
ndividual parts of SDP.
If JSEP will not support POF/PAN, perhaps it would be good to have explicit=
 text indicating that.

Thanks!
Regards,
Christer

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



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







I support that. But, do we have a WG decision on such approach?=
 I would not want this to pop up in the last minute, during WGLC etc...=0A=
=0A=
Regards,=0A=
=0A=
Christer=0A=
=0A=
Sent from my Sony Ericsson Xperia arc S=0A=
=0A=
Justin Uberti <juberti@google.com> wrote:=0A=
=0A=





Not in 1.0.







On Wed, Jul 23, 2014 at 10:37 PM, Christer Holmb=
erg 
<chr=
ister.holmberg@ericsson.com> wrote:








Hi,




Are we still planning to incorporate support of POF/=
PAN (partial offers/answers) into JSEP?


 


AFAIK, the work on POF/PAN hasn=92t progressed. In a=
ddition, I believe (please correct me if I=92m wrong) it would have a major=
 impact on the JSEP state machine, as it currently is defined to deal with =
complete SDPs =96 not individual parts of
 SDP.




If JSEP will not support POF/PAN, perhaps it would b=
e good to have explicit text indicating that.


 


Thanks!




Regards,




Christer







_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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
















--_000_xvg7ft2mtvlt0ru40klvgh271406200125343emailandroidcom_--


From nobody Thu Jul 24 05:12:49 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161A51A0202 for ; Thu, 24 Jul 2014 05:12:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.579
X-Spam-Level: 
X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7-J1tOl5F81 for ; Thu, 24 Jul 2014 05:12:41 -0700 (PDT)
Received: from mail-we0-f170.google.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by ietfa.amsl.com (Postfix) with SMTP id CEBDC1A0233 for ; Thu, 24 Jul 2014 05:12:39 -0700 (PDT)
Received: from mail-we0-f170.google.com ([74.125.82.170]) (using TLSv1) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKU9D4N6CFDUQLjTnV+4Toee3nuC0SDxN5@postini.com; Thu, 24 Jul 2014 05:12:40 PDT
Received: by mail-we0-f170.google.com with SMTP id w62so2694837wes.15 for ; Thu, 24 Jul 2014 05:12:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=WbbI6Z5gynVfRL7x02h2UTKaQn+5WkqHNWMv2m7ui9I=; b=VuafsmXvtj4cPFFrqSLXq4CJJ4drUbTMu1EZwYELrJ0V/mCg2cRH5jQBoxyHMac6p4 lnQxX0dIWxvUnaVofdiKXbVrDO1SftdEhvQcV5571MnY2ZeUWib00MgDR71rtDP7PsGv r3RG/mlWrkVj7JPcUeL12u9vizysNrFNh41oFHqfEaLGIVm9iad69qmdp0E9hgGEB/ji Uq0uivhHPA4xMNPxvwSlRLmvwO5kMr87qS40FtbSjJbAjzkgPVdcN2Pgk7EalJgH/nzs YzCilhy+fv3G2Ip/FaejeiUZBV+atsoHhu/lOMDUlmwOcoVtc9xYrFZjIa8YiLytEz7g LcTA==
X-Gm-Message-State: ALoCoQkv8IQgDE4TZ40yKgmUQFLMyRZ1Unl8hvw1ClfpJbe/KgCrhqr1rbg4Qwrx8XC2Q3aNmnMdsSINRJSQBCmw21polDdQWZ8aCugrlpuytdYz6+L6gU8y004l+dmynAKgsoNv/NjP
X-Received: by 10.180.86.7 with SMTP id l7mr12142599wiz.55.1406203958285; Thu, 24 Jul 2014 05:12:38 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.86.7 with SMTP id l7mr12142569wiz.55.1406203957955; Thu, 24 Jul 2014 05:12:37 -0700 (PDT)
Received: by 10.194.60.178 with HTTP; Thu, 24 Jul 2014 05:12:37 -0700 (PDT)
Date: Thu, 24 Jul 2014 08:12:37 -0400
Message-ID: 
From: Michael Procter 
To: "" , Martin Thomson 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IHmtIP-5ndc71kiuKTwk4GHkbWI
Subject: [rtcweb] Review of draft-ietf-rtcweb-alpn-00
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 12:12:47 -0000

As promised, here is my review of the alpn draft.  There is one issue
that is not editorial in nature.

The final paragraph in section 2 reads:

   Only one of these labels can be used for any given session.  A peer
   acting in the client role MUST NOT offer both identifiers.  A peer in
   the server role that receives a ClientHello containing both labels
   MUST reject the session, though it MAY accept the confidential option
   and protect content accordingly.

I'm not sure of the reason behind insisting that the client only
offers one of the identifiers.  Is the intent to invoke
confidentiality negotiated elsewhere (i.e. in SDP) or is this
essentially the negotiation?  I can't find such a negotiation in other
documents.

The use case I have in mind is when I am trying to create a simple
session.  I am happy to have confidentiality at my end (the JS I am
using has no plans to access the media), but I can't insist on
confidentiality at your end, because I don't know if I will reach you
on a browser, or via some legacy comms network to your mobile phone.
It would seem reasonable to offer both c-webrtc and webrtc, and allow
the remote end to pick either, hoping that sometimes I will get
confidentiality.


Editorial tweaks:
The one-sentence paragraph beginning "A more thorough definition" is duplicated.

The penultimate paragraph in section 2 reads:
   There is no functional difference between the identifiers except with
   respect to the promise that an endpoint makes with respect to the
   confidentiality of session content.  An endpoint negotiating
   "c-webrtc" makes a promise to preserve the confidentiality of the
   data it receives.

I found this slightly confusing.  I think the following wording is
simpler but still captures the intent of the paragraph:
   There is no functional difference between the identifiers except
   that an endpoint negotiating
   "c-webrtc" makes a promise to preserve the confidentiality of the
   data it receives.

Best regards,

Michael


From nobody Thu Jul 24 10:36:04 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9351ABB2B for ; Thu, 24 Jul 2014 10:36:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.779
X-Spam-Level: 
X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 41UB016EzKtO for ; Thu, 24 Jul 2014 10:36:01 -0700 (PDT)
Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DFF51ABB1D for ; Thu, 24 Jul 2014 10:36:01 -0700 (PDT)
Received: by mail-vc0-f173.google.com with SMTP id hy10so5431104vcb.4 for ; Thu, 24 Jul 2014 10:36:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=v+bgIJfwCx7JaKbDFRZ0xSJNLqvnR+0FcYJByfe3rfo=; b=iaO4tV/ajeoUuY+AjZ6E+/rWMdgGTx4cfqTgNd8yu90VautePIdnyfPtHhR50sTgE3 mThCvAoomWxrV8klj45Lp8rvES2vSX6/KpvbY5FbhPiZR0tGD93tT075Qqe+cJVCxJJw tvwmbGK6QDm0KHvFXqlOTlUzmZD4fjdcGmUyGtcF8jEgzoD6LHatIHb8ON6uVHS4wK1i XN49S4CyXi2cHS1CuxY0UEDKEn41nZLnk/3FR/o7y+6y6ha0wCfnpox7g1Q0hbyqRxmu KbrUapNjOS1+ELHRqEfJJk9gwMa8jpB7Dn4qyoCZZfCKYCNTgYJDnwKMjxfXFhqlJhEh xaMg==
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:content-type; bh=v+bgIJfwCx7JaKbDFRZ0xSJNLqvnR+0FcYJByfe3rfo=; b=UxIDNBOzpIMW4+yppSO2E3iFFj4wiHl0KV4bf9PVMZMx6vSmhlNedCZSUbAs6vPl9w sLO4mYJ18x+DR67EB+CMR+sURorwJWWeZH6G9QETqny6toMuUWmgPRjZVteMO35IG3mC dYuMeR4otyeVrw/W0z98fFUlrjPmzSt4hlsa26JI1owuhUK9131ACj1pbQq9KJncBCWL nHU0g6FAmEDI1Hd4BnlE6wyg136YB74RsgVxgX8ej6uxdWhHwruxrIf7kiSie2EZtG3+ 7zqSnLfgpo2oQUZOKeKDU9qHa/wN8BG2TMdECq6U2IyCEHX/SpZMWKKgxw5lZM+6SEr0 ofTQ==
X-Gm-Message-State: ALoCoQnJSfYsoLwFNcreyLBOtb2bBR5PdatSLbgvuTtDKLg23BfNgUwUccXjRWeYSsVRly9HEdGz
X-Received: by 10.221.42.135 with SMTP id ty7mr14778312vcb.14.1406223360311; Thu, 24 Jul 2014 10:36:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.4.70 with HTTP; Thu, 24 Jul 2014 10:35:40 -0700 (PDT)
In-Reply-To: <53D0880B.70401@alum.mit.edu>
References:   <53CEFA2C.8040407@nteczone.com> <53CFA92F.5070306@alum.mit.edu>  <53D0880B.70401@alum.mit.edu>
From: Justin Uberti 
Date: Thu, 24 Jul 2014 13:35:40 -0400
Message-ID: 
To: Paul Kyzivat 
Content-Type: multipart/alternative; boundary=001a11339974dde39704fef3e345
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cvkSC22MQsKEVkwISFZzrAm_ZPc
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 17:36:03 -0000

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

On Thu, Jul 24, 2014 at 12:14 AM, Paul Kyzivat 
wrote:

> On 7/23/14 9:19 AM, Justin Uberti wrote:
>
>>
>>
>>
>> On Wed, Jul 23, 2014 at 8:23 AM, Paul Kyzivat > > wrote:
>>
>>     On 7/22/14 7:56 PM, Christian Groves wrote:
>>
>>         The browser would delay the establishment of media that are part
>>         of the
>>         "a=group:clue" group until a CLUE exchange has taken place and
>> those
>>         media have been selected via a CLUE configure message. I'm not
>>         sure if
>>         that fits your criteria for acting differently?
>>
>>
>>     I haven't thought about it much, but I think there are a couple of
>>     ways to deal with that. One is to simply hide those from the browser
>>     until the desired time. Another is to mark them as inactive for the
>>     browser until configured.
>>
>>     A more difficult problem is that CLUE uses one-way media streams,
>>     while jsep forces opposite direction ones to be merged into a single
>>     sendrecv m-line. I don't know how to fix that.
>>
>>
>> If you can demonstrate a specific problem that this causes, we can
>> re-evaluate this. But we need to ensure that a simple phone call ends up
>> with a single m=audio line.
>>
>
> The fundamental problem with this is that AFAICT it makes it impossible to
> build a WebRTC client that can interop with a CLUE server. I guess it would
> be possible with a special purpose media gateway that demuxed the clue
> media from sendrecv m-lines to sendonly & recvonly m-lines.
>
> As another clue person said today, CLUE chose to use sendonly and recvonly
> m-lines so we could use the sendonly ones to provide SDP descriptions of
> what is available to be *sent*. (With sendrecv m-lines this describes only
> what is desired to be received.) Clue use cases are likely to be highly
> asymmetric, so it is essential to be able to do this.
>
> Clue does have a solution for the simple phone, but it probably isn't a
> solution that would be satisfactory to rtcweb. The first O/A on a CLUE
> session assumes it doesn't know what it might be connecting to, and so
> makes an offer that is likely to work with "legacy" devices. Generally this
> would be one sendrecv audio and one sendrecv video, though YMMV. There are
> a few other things in there that allow the two ends to discover if they
> both can do clue after the first O/A.
>
> If both do clue, then there is another O/A that provides sendonly m-lines
> for the offerer. And there will be a 3rd that provides sendonly m-lines by
> the other end. We consider this tolerable for telepresence.
>
> The first O/A will also include DTLS/SCTP m-line that is intended to carry
> the CLUE data channel. (Assumed to be rejected by a "legacy" device.) While
> we don't require it, bundling is very attractive for clue. So if ICE has
> succeeded for that m-line, the subsequent O/As can add all those sendonly
> m-lines in the same bundle, so no new ice will be required.
>

I think this would work fine with the new APIs being provided.

In the initial offer, sendrecv audio, video, and data m= line will be
offered, with the option to bundle.
In the second offer, the OfferToReceiveVideo:X option can be used to create
sendonly m= lines from the offerer.
In the third offer, the OfferToReceiveVideo:Y option can be used to create
sendonly m= lines from the answerer.

Did I overlook something?

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



=
On Thu, Jul 24, 2014 at 12:14 AM, Paul Kyzivat <pkyzivat@alum.mit.edu<=
/a>> wrote:



On 7/23/14 9:19 AM, Justin U=
berti wrote:









On Wed, Jul 23, 2014 at 8:23 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
<=
div class=3D"h5">
<mailto:pkyzi=
vat@alum.mit.edu>> wrote:



=C2=A0 =C2=A0 On 7/22/14 7:56 PM, Christian Groves wrote:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 The browser would delay the establishment of me=
dia that are part

=C2=A0 =C2=A0 =C2=A0 =C2=A0 of the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "a=3Dgroup:clue" group until a CLUE e=
xchange has taken place and those

=C2=A0 =C2=A0 =C2=A0 =C2=A0 media have been selected via a CLUE configure m=
essage. I'm not

=C2=A0 =C2=A0 =C2=A0 =C2=A0 sure if

=C2=A0 =C2=A0 =C2=A0 =C2=A0 that fits your criteria for acting differently?=






=C2=A0 =C2=A0 I haven't thought about it much, but I think there are a =
couple of

=C2=A0 =C2=A0 ways to deal with that. One is to simply hide those from the =
browser

=C2=A0 =C2=A0 until the desired time. Another is to mark them as inactive f=
or the

=C2=A0 =C2=A0 browser until configured.



=C2=A0 =C2=A0 A more difficult problem is that CLUE uses one-way media stre=
ams,

=C2=A0 =C2=A0 while jsep forces opposite direction ones to be merged into a=
 single

=C2=A0 =C2=A0 sendrecv m-line. I don't know how to fix that.





If you can demonstrate a specific problem that this causes, we can

re-evaluate this. But we need to ensure that a simple phone call ends up
with a single m=3Daudio line.





The fundamental problem with this is that AFAICT it makes it impossible to =
build a WebRTC client that can interop with a CLUE server. I guess it would=
 be possible with a special purpose media gateway that demuxed the clue med=
ia from sendrecv m-lines to sendonly & recvonly m-lines.





As another clue person said today, CLUE chose to use sendonly and recvonly =
m-lines so we could use the sendonly ones to provide SDP descriptions of wh=
at is available to be *sent*. (With sendrecv m-lines this describes only wh=
at is desired to be received.) Clue use cases are likely to be highly asymm=
etric, so it is essential to be able to do this.





Clue does have a solution for the simple phone, but it probably isn't a=
 solution that would be satisfactory to rtcweb. The first O/A on a CLUE ses=
sion assumes it doesn't know what it might be connecting to, and so mak=
es an offer that is likely to work with "legacy" devices. General=
ly this would be one sendrecv audio and one sendrecv video, though YMMV. Th=
ere are a few other things in there that allow the two ends to discover if =
they both can do clue after the first O/A.





If both do clue, then there is another O/A that provides sendonly m-lines f=
or the offerer. And there will be a 3rd that provides sendonly m-lines by t=
he other end. We consider this tolerable for telepresence.



The first O/A will also include DTLS/SCTP m-line that is intended to carry =
the CLUE data channel. (Assumed to be rejected by a "legacy" devi=
ce.) While we don't require it, bundling is very attractive for clue. S=
o if ICE has succeeded for that m-line, the subsequent O/As can add all tho=
se sendonly m-lines in the same bundle, so no new ice will be required.




I think this would work fine with the new =
APIs being provided.=C2=A0

In the initial offer, s=
endrecv audio, video, and data m=3D line will be offered, with the option t=
o bundle.



In the second offer, the OfferToReceiveVideo:X option can be used to c=
reate sendonly m=3D lines from the offerer.
In the third offer, t=
he OfferToReceiveVideo:Y option can be used to create sendonly m=3D lines f=
rom the answerer.




Did I overlook something?


--001a11339974dde39704fef3e345--


From nobody Thu Jul 24 10:38:25 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455311A8BB5 for ; Thu, 24 Jul 2014 10:38:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.779
X-Spam-Level: 
X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 Vd7L99vEwhJC for ; Thu, 24 Jul 2014 10:38:22 -0700 (PDT)
Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01F5F1A0A90 for ; Thu, 24 Jul 2014 10:38:21 -0700 (PDT)
Received: by mail-vc0-f170.google.com with SMTP id lf12so5429031vcb.29 for ; Thu, 24 Jul 2014 10:38:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SQXHCHksf8rTawQ8E6zkZBO+FS26LUMM8xaKd/l/5JE=; b=el9O8GSqAKFVlqAG9PHprnRUSawNC0OyGJ+S0huK0asYqFbLPVpRMrDyPoxMS73i6V d4SK3wddb2tRMJY1HQVz+BiIBgoE2Ale3mEkuJnp08vUEDEc5g3S6LwSnz+37cbQVNaH sSb7HILZWcXni0wCxAI0xwHubLiQjwI9lV0mQHTLQ5Hny1QeIe6zwMGZ8rT9qgzIT3n6 06H5apIZQ6WgO2t6uDWgWuLTnIbQqFAEBT68aUnk+qAzE8S1RP/qIx0H7bq303q6E3zS zp8WVYfE0lP34Mad7s8VB4tC/seKNsg3GDQC3x0JDM9IZ4/mBAGL3Zb4pBtK3Bvw8kiP mNrg==
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:content-type; bh=SQXHCHksf8rTawQ8E6zkZBO+FS26LUMM8xaKd/l/5JE=; b=f2Dj2hShNDpshU3dWJ+2NS3UMyYn7zG3mLihBZgj69BBKzhTNONANcrmsbuJCPyy6d OBZ3pb4Qfz5Btsl28Yu32KupPJHfulmLV95uLbbmdVQQ8aLc+a7zdjcyWUM/2er6oeky Kokp6dDL6ij/mx7mpCRDkDfjMXeGE5RnzLypllyNFEtE75K4a/joGzVZBjKnHzkj1hjT fDvLS4ijfMRcc9Q9BRkMIAfC2WPSFqLWqMkUnR28k60eztgnsckdp1s9TUjxG5RFZ1DD D1iODbDkHEtgHI1OsLTUvzG89aA68QzQK1733uAUyy7BNSSjhiaLBCkWbOEGSDYQWGsK AUhA==
X-Gm-Message-State: ALoCoQkMfPAJiP43PeaiCIVy6ixrTdZm/LsUEcJ5mgQmvrl1hpadqEB5KjJ6tsdxFyiAT93ggYVG
X-Received: by 10.52.136.196 with SMTP id qc4mr12338516vdb.22.1406223500989; Thu, 24 Jul 2014 10:38:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.4.70 with HTTP; Thu, 24 Jul 2014 10:38:00 -0700 (PDT)
In-Reply-To: 
References:  
From: Justin Uberti 
Date: Thu, 24 Jul 2014 13:38:00 -0400
Message-ID: 
To: "Makaraju, Maridi Raju (Raju)" 
Content-Type: multipart/alternative; boundary=bcaec51b12bd4087ca04fef3ec67
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ItVoMYbfJWYRMug8UI1XQ3bO5zg
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Sending of zero-length messages over data channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 17:38:23 -0000

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

Changing the send() API defeats the purpose of trying to provide full
WebSockets compatibility.

I think the PPID_EMPTY approach (probably PPID_EMPTY_TEXT and
PPID_EMPTY_BINARY, to be precise) is a simple and complete solution.


On Wed, Jul 23, 2014 at 8:00 AM, Makaraju, Maridi Raju (Raju) <
Raju.Makaraju@alcatel-lucent.com> wrote:

>
>
> In the existing data channel protocol, it's not possible to send
> zero-length messages, because SCTP prohibits it.
>
>
>
> While this may seem to be an academic point, it does represent a
> divergence from WebSockets, and this difference could be meaningful to
> applications who use empty messages for keepalives. Or maybe the Yo app.
>
>
>
> Since we can't send a zero-length SCTP message, I propose we add a
> PPID_EMPTY value or something similar to indicate a message with empty
> content.
>
> *[Raju] There is a genuine need for this and the proposal is good. *
>
> *However, I am thinking of an alternate proposal to achieve the same but
> in a generic way. *
>
> *Define a PPID_OOB (out of band) or something similar.*
>
> *Apps can use this to send a message of non-zero length. For the =E2=80=
=9CYo=E2=80=9D kind
> of app or empty stream-level heartbeat purpose, app can send a 1 byte
> length message, which other end=E2=80=99s app ignores.*
>
> *This approach involves bit more API work for webrtc to have a variation
> of send(data, oobFlag) and new data type in onmessage(). IMHO, this
> approach allows more possibilities in future and also the same approach c=
an
> be used by other SCTP use cases not involving webrtc.*
>
>
>
> *BR*
>
> *raju*
>

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


Changing the send() API defeats the purpose of trying to p=
rovide full WebSockets compatibility.

I think the PPID_E=
MPTY approach (probably PPID_EMPTY_TEXT and PPID_EMPTY_BINARY, to be precis=
e) is a simple and complete solution.





On Wed,=
 Jul 23, 2014 at 8:00 AM, Makaraju, Maridi Raju (Raju) &l=
t;Raj=
u.Makaraju@alcatel-lucent.com> wrote:
















=C2=A0




In the existing data channel protocol, it's not =
possible to send zero-length messages, because SCTP prohibits it.=





=C2=A0






While this may seem to be an academic point, it does=
 represent a divergence from WebSockets, and this difference could be meani=
ngful to applications who use empty messages for keepalives. Or maybe the Y=
o app.








=C2=A0






Since we can't send a zero-length SCTP message, =
I propose we add a PPID_EMPTY value or something similar to indicate a mess=
age with empty content.


[Raju] There =
is a genuine need for this and the proposal is good.



However, I am think=
ing of an alternate proposal to achieve the same but in a generic way.



Define a PPID_OOB (=
out of band) or something similar.


Apps can use this t=
o send a message of non-zero length. For the =E2=80=9CYo=E2=80=9D kind of a=
pp or empty stream-level heartbeat purpose, app can send a 1 byte length
 message, which other end=E2=80=99s app ignores.


This approach invol=
ves bit more API work for webrtc to have a variation of send(data, oobFlag)=
 and new data type in onmessage(). IMHO, this approach allows
 more possibilities in future and also the same approach can be used by oth=
er SCTP use cases not involving webrtc.


=C2=A0


BR

raju=



















--bcaec51b12bd4087ca04fef3ec67--


From nobody Thu Jul 24 10:42:45 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701CF1A0A88 for ; Thu, 24 Jul 2014 10:42:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A968jrwJPGGO for ; Thu, 24 Jul 2014 10:42:43 -0700 (PDT)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D2901A0016 for ; Thu, 24 Jul 2014 10:42:42 -0700 (PDT)
Received: by mail-wg0-f51.google.com with SMTP id b13so3019989wgh.22 for ; Thu, 24 Jul 2014 10:42:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E+n2Og3IrPj2U1k9QR54jaqr0YiHBM5ZOz1qgZRgNns=; b=NZLDCPj2TM3qOZtgN0OEruMzdLYERVwphxmGaHTjcIUV0qcXwBId20ow1DOcyYhjpx uzPhAhEHLw2UimZPo4DgTlVEphzKDfxpdcIGO+VNxQE0j3OtL7IwSnYEAxGugRhSTkpO DoXncvOcgskOIkIrAVhrL4PdbIty6fQ+SqwBFppgNyLWouBshfShQ0wB7mMQ0ZOtBybd 6XSyNqk2dbki7Vr2JQEs7rh+H6/7knM19+OFtxiOiPUpVDpZm3YEVm16ylkko+tjXlhj VxXaGUYtcp/EugtPGWqINi66+YdLGKnsr14HJum+g/HgT9zzefezSD1RB0HIAAETkofx KEMw==
MIME-Version: 1.0
X-Received: by 10.194.143.49 with SMTP id sb17mr14054528wjb.25.1406223759132;  Thu, 24 Jul 2014 10:42:39 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Thu, 24 Jul 2014 10:42:39 -0700 (PDT)
In-Reply-To: 
References: 
Date: Thu, 24 Jul 2014 10:42:39 -0700
Message-ID: 
From: Martin Thomson 
To: Michael Procter 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/h7CroyLHms9UN1JCF71AfQUjzbk
Cc: "" 
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-alpn-00
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 17:42:44 -0000

On 24 July 2014 05:12, Michael Procter  wrote:
> As promised, here is my review of the alpn draft.  There is one issue
> that is not editorial in nature.
>
> The final paragraph in section 2 reads:
>
>    Only one of these labels can be used for any given session.  A peer
>    acting in the client role MUST NOT offer both identifiers.  A peer in
>    the server role that receives a ClientHello containing both labels
>    MUST reject the session, though it MAY accept the confidential option
>    and protect content accordingly.
>
> I'm not sure of the reason behind insisting that the client only
> offers one of the identifiers.  Is the intent to invoke
> confidentiality negotiated elsewhere (i.e. in SDP) or is this
> essentially the negotiation?  I can't find such a negotiation in other
> documents.

That's an error on my part.

I wrote that before I implemented it.  The code that I have permits
both tokens to be configured into clients. This is in fact necessary
in the case where a peer doesn't know whether confidentiality is
required, which is the default case.

Thanks for the editorial tweaks.


From nobody Thu Jul 24 11:11:19 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0B61A01F9 for ; Thu, 24 Jul 2014 11:11:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKxPGjqjrDCA for ; Thu, 24 Jul 2014 11:11:06 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C51C1A028B for ; Thu, 24 Jul 2014 11:10:55 -0700 (PDT)
Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s6OIArH3020861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Jul 2014 13:10:53 -0500 (CDT)
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s6OIAqrl007961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jul 2014 14:10:53 -0400
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Thu, 24 Jul 2014 14:10:52 -0400
From: "Makaraju, Maridi Raju (Raju)" 
To: Justin Uberti 
Thread-Topic: [rtcweb] Sending of zero-length messages over data channels
Thread-Index: AQHPpipfEWtPO6jXOES6Y6R7CwNaxJutiTxggAI5gwD//74D0A==
Date: Thu, 24 Jul 2014 18:10:51 +0000
Deferred-Delivery: Thu, 24 Jul 2014 18:10:00 +0000
Message-ID: 
References:   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.18]
Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E4C5974US70UWXCHMBA02z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6fv8eoz3ZoRUhp8R7Lt9MQXMboU
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Sending of zero-length messages over data channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 18:11:15 -0000

--_000_E1FE4C082A89A246A11D7F32A95A17828E4C5974US70UWXCHMBA02z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQoNCkNoYW5naW5nIHRoZSBzZW5kKCkgQVBJIGRlZmVhdHMgdGhlIHB1cnBvc2Ugb2YgdHJ5aW5n
IHRvIHByb3ZpZGUgZnVsbCBXZWJTb2NrZXRzIGNvbXBhdGliaWxpdHkuDQo8UmFqdT4gSSB1bmRl
cnN0YW5kIHRoZSBkZXNpcmUgdG8gbWFrZSB0aGUgQVBJIGNvbXBhdGlibGUgdG8gd2Vic29ja2V0
IEFQSS4gQnV0LCB1bmxpa2Ugd2Vic29ja2V0IFRDUCB0cmFuc3BvcnQsIHRoZSBkYXRhIGNoYW5u
ZWxzIHRoZSB1bmRlcmx5aW5nIHRyYW5zcG9ydCAoU0NUUCkgaGFzIHRoZSBmbGV4aWJpbGl0eSBm
b3IgUFBJRCwgd2hpY2ggY2FuIGJlIHV0aWxpemVkIHRvIGFjaGlldmUgdGhlIHNhbWUgZ29hbCwg
d2l0aCB0aGUgYWRkZWQgYWR2YW50YWdlIG9mIHVzaW5nIHRoZSBzYW1lIGFwcHJvYWNoIGZvciBv
dGhlciB1c2UgY2FzZXMgKGxpa2UgT09CIGRhdGEgZGVsaXZlcnkpLg0KDQpJSE1PLCBQUElEX0VN
UFRZIGFwcHJvYWNoIGlzIG5vdCBzdHJhaWdodCBmb3J3YXJkIGVpdGhlciBhcyBhdCBTQ1RQIGxl
dmVsIHlvdSBzdGlsbCBoYXZlIHRvIHNlbmQgc29tZSBkdW1teSBkYXRhICh1bmxlc3MgU0NUUCBp
cyBlbmhhbmNlZCkgb2Ygc29tZSBzaXplICg9MSBvciBpbXBsZW1lbnRhdGlvbiBkZXBlbmRlbnQ/
KSwgd2hpY2ggaXMgbm90IG9idmlvdXMgdG8gdGhlIHVzZXIuIFdpbGwgdGhlIOKAmGJ1ZmZlcmVk
QW1vdW504oCZIGJlIGluY3JlYXNlZCBhcHByb3ByaWF0ZWx5IHdpdGggdGhlIGR1bW15IGRhdGEg
c2VudD8gRXZlbiBpZiBpdCBpcyBhY2NvdW50ZWQgZm9yLCB0aGUgYXBwbGljYXRpb24gaGFzIHRv
IGtub3cgdGhpcyBhbmQgYmUgbWluZGZ1bCBvZiB0aGUg4oCcbXlzdGVyaW91c+KAnSBpbmNyZWFz
ZSAoMSBieXRlIG9yIG4gYnl0ZXM/KSBpbiDigJhidWZmZXJlZEFtb3VudOKAmSwgc29tZXRoaW5n
IHZlcnkgdW5pcXVlIHRvIFNDVFAuDQoNClBQSURfT09CIGFwcHJvYWNoIGlzIHRyYW5zcGFyZW50
IHRvIHRoZSB1c2VyIGFzIHVzZXIgc2VuZHMgdGhlIGRhdGEsIHNvIGl0IGlzIGF1dG9tYXRpY2Fs
bHkgYWNjb3VudGVkIGluIOKAmGJ1ZmZlcmVkQW1vdW504oCZLg0KDQo8L1JhanU+DQoNCkkgdGhp
bmsgdGhlIFBQSURfRU1QVFkgYXBwcm9hY2ggKHByb2JhYmx5IFBQSURfRU1QVFlfVEVYVCBhbmQg
UFBJRF9FTVBUWV9CSU5BUlksIHRvIGJlIHByZWNpc2UpIGlzIGEgc2ltcGxlIGFuZCBjb21wbGV0
ZSBzb2x1dGlvbi4NCg==

--_000_E1FE4C082A89A246A11D7F32A95A17828E4C5974US70UWXCHMBA02z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi
O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw
YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y
OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uaG9lbnpiDQoJe21z
by1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K
CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0
LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp
bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y
ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd
LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+
DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht
bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2
bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7
cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Q2hhbmdpbmcgdGhlIHNlbmQoKSBBUEkgZGVmZWF0cyB0aGUgcHVycG9zZSBvZiB0cnlpbmcgdG8g
cHJvdmlkZSBmdWxsIFdlYlNvY2tldHMgY29tcGF0aWJpbGl0eS48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj4mbHQ7UmFqdSZndDsgSSB1bmRlcnN0YW5kIHRoZSBkZXNpcmUgdG8gbWFrZSB0
aGUgQVBJIGNvbXBhdGlibGUgdG8gd2Vic29ja2V0IEFQSS4gQnV0LCB1bmxpa2Ugd2Vic29ja2V0
IFRDUCB0cmFuc3BvcnQsIHRoZSBkYXRhIGNoYW5uZWxzIHRoZSB1bmRlcmx5aW5nIHRyYW5zcG9y
dA0KIChTQ1RQKSBoYXMgdGhlIGZsZXhpYmlsaXR5IGZvciBQUElELCB3aGljaCBjYW4gYmUgdXRp
bGl6ZWQgdG8gYWNoaWV2ZSB0aGUgc2FtZSBnb2FsLCB3aXRoIHRoZSBhZGRlZCBhZHZhbnRhZ2Ug
b2YgdXNpbmcgdGhlIHNhbWUgYXBwcm9hY2ggZm9yIG90aGVyIHVzZSBjYXNlcyAobGlrZSBPT0Ig
ZGF0YSBkZWxpdmVyeSkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J
SE1PLCBQUElEX0VNUFRZIGFwcHJvYWNoIGlzIG5vdCBzdHJhaWdodCBmb3J3YXJkIGVpdGhlciBh
cyBhdCBTQ1RQIGxldmVsIHlvdSBzdGlsbCBoYXZlIHRvIHNlbmQgc29tZSBkdW1teSBkYXRhICh1
bmxlc3MgU0NUUCBpcyBlbmhhbmNlZCkgb2Ygc29tZSBzaXplDQogKD0xIG9yIGltcGxlbWVudGF0
aW9uIGRlcGVuZGVudD8pLCB3aGljaCBpcyBub3Qgb2J2aW91cyB0byB0aGUgdXNlci4gV2lsbCB0
aGUg4oCYYnVmZmVyZWRBbW91bnTigJkgYmUgaW5jcmVhc2VkIGFwcHJvcHJpYXRlbHkgd2l0aCB0
aGUgZHVtbXkgZGF0YSBzZW50PyBFdmVuIGlmIGl0IGlzIGFjY291bnRlZCBmb3IsIHRoZSBhcHBs
aWNhdGlvbiBoYXMgdG8ga25vdyB0aGlzIGFuZCBiZSBtaW5kZnVsIG9mIHRoZSDigJxteXN0ZXJp
b3Vz4oCdIGluY3JlYXNlICgxDQogYnl0ZSBvciBuIGJ5dGVzPykgaW4g4oCYYnVmZmVyZWRBbW91
bnTigJksIHNvbWV0aGluZyB2ZXJ5IHVuaXF1ZSB0byBTQ1RQLjxvOnA+PC9vOnA+PC9zcGFuPjwv
aT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPlBQSURfT09CIGFwcHJvYWNoIGlzIHRyYW5zcGFyZW50IHRvIHRo
ZSB1c2VyIGFzIHVzZXIgc2VuZHMgdGhlIGRhdGEsIHNvIGl0IGlzIGF1dG9tYXRpY2FsbHkgYWNj
b3VudGVkIGluIOKAmGJ1ZmZlcmVkQW1vdW504oCZLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPiZsdDsvUmFqdSZndDs8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGUgUFBJRF9FTVBUWSBhcHByb2FjaCAo
cHJvYmFibHkgUFBJRF9FTVBUWV9URVhUIGFuZCBQUElEX0VNUFRZX0JJTkFSWSwgdG8gYmUgcHJl
Y2lzZSkgaXMgYSBzaW1wbGUgYW5kIGNvbXBsZXRlIHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_E1FE4C082A89A246A11D7F32A95A17828E4C5974US70UWXCHMBA02z_--


From nobody Thu Jul 24 11:16:47 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861231A0AD9 for ; Thu, 24 Jul 2014 11:16:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 k0S7Vn52BrzC for ; Thu, 24 Jul 2014 11:16:44 -0700 (PDT)
Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63B301A0A90 for ; Thu, 24 Jul 2014 11:16:44 -0700 (PDT)
Received: by mail-vc0-f176.google.com with SMTP id id10so5459804vcb.21 for ; Thu, 24 Jul 2014 11:16:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=foniZGxQpwLE2fcHQuMQijDQO1JFYPQ0UibyuI8tg60=; b=cBrt207qrqwd6rTx2rEG5cPQFCUFGHZjw3FyA9Ruv/ULAMLg541FORjcS9BkteEaBD XDXiVr3fC5ZIFxLRZK6XaG6hB/ldzwWu2GbIIxygSoLtCC6J7QiLlhVuqpHFn2Y0NDD3 wuWuKoAZ/6ICcfZLLQ+3vtWajXtbqgZtnS5fqT1kavjHXoMrPIxMpZZXS/wp2K7WB4zD lm3Hv2FS2dZOgLUS2uIdIyMrfWpA3QeK4V3SBO6dJM8iPowaI2Q2AZN5h9lpvykJBYFa iY5++RY7zUxoG2Xrs5sYJm6FekNVgLfbIYTsm9EakTeQyQY9h+hzvluyupYfQ0SQJDmF hLtA==
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:content-type; bh=foniZGxQpwLE2fcHQuMQijDQO1JFYPQ0UibyuI8tg60=; b=BRjHqY66a8nq8V1FdMA1u19XEMWSGODJ0IjVuJjLKCafEuk8wk3hSXMGF5dJ8HjfQU Oa/TD7FGh85sUj8Z56yg/PY5duxlLIPYIqDEghCffqsWtTMy14FOsOJdRxKIIxLbowUZ cmTi9npPDyC8n2NrtWyM4tL59qJKQq3yP9ziQP2f1Ghhi5eDrwaqQq1cViuovzCk1Qqf QbOmbdjsr+pZqeNEUXsJGTAlUCl/nq/ez046e+VQ+iyQQOdUvJFkfoDjt4o1+9H4Ofrr KlACrFIx4IqLXXBhOpbNlfRqiepEQObfotM7Uf/1FHV1OA//AsiOe9I3/v6yiYR7nZa0 MpbQ==
X-Gm-Message-State: ALoCoQmDF+COPPBunQChg/ycNfLt9WJguzztVlHf48eUiAH3sDzSOetYoRGyUNmozeqdZ81VAyoC
X-Received: by 10.221.41.135 with SMTP id tu7mr14938574vcb.70.1406225802937; Thu, 24 Jul 2014 11:16:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.4.70 with HTTP; Thu, 24 Jul 2014 11:16:22 -0700 (PDT)
In-Reply-To: 
References:    
From: Justin Uberti 
Date: Thu, 24 Jul 2014 14:16:22 -0400
Message-ID: 
To: "Makaraju, Maridi Raju (Raju)" 
Content-Type: multipart/alternative; boundary=001a1133901c75685a04fef4755a
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Abqpblox3kmWwIemHoiiI2mm6Xw
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Sending of zero-length messages over data channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 18:16:45 -0000

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

On Thu, Jul 24, 2014 at 2:10 PM, Makaraju, Maridi Raju (Raju) <
Raju.Makaraju@alcatel-lucent.com> wrote:

>
>
>
>
> Changing the send() API defeats the purpose of trying to provide full
> WebSockets compatibility.
>
> * I understand the desire to make the API compatible to websocket
> API. But, unlike websocket TCP transport, the data channels the underlyin=
g
> transport (SCTP) has the flexibility for PPID, which can be utilized to
> achieve the same goal, with the added advantage of using the same approac=
h
> for other use cases (like OOB data delivery). *
>
>
>
> *IHMO, PPID_EMPTY approach is not straight forward either as at SCTP leve=
l
> you still have to send some dummy data (unless SCTP is enhanced) of some
> size (=3D1 or implementation dependent?), which is not obvious to the use=
r.
> Will the =E2=80=98bufferedAmount=E2=80=99 be increased appropriately with=
 the dummy data
> sent? Even if it is accounted for, the application has to know this and b=
e
> mindful of the =E2=80=9Cmysterious=E2=80=9D increase (1 byte or n bytes?)=
 in
> =E2=80=98bufferedAmount=E2=80=99, something very unique to SCTP.*
>

We will send 1 byte, and this will not be reflected in bufferedAmount, same
as WebSockets.

>
>
> *PPID_OOB approach is transparent to the user as user sends the data, so
> it is automatically accounted in =E2=80=98bufferedAmount=E2=80=99.*
>
>
>
> **
>
>
>
> I think the PPID_EMPTY approach (probably PPID_EMPTY_TEXT and
> PPID_EMPTY_BINARY, to be precise) is a simple and complete solution.
>

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





On Thu, Jul 24, 2014 at 2:10 PM, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:














=C2=A0


=C2=A0






Changing the send() API defeats the purpose of tryin=
g to provide full WebSockets compatibility.


<Raju> =
I understand the desire to make the API compatible to websocket API. But, u=
nlike websocket TCP transport, the data channels the underlying transport
 (SCTP) has the flexibility for PPID, which can be utilized to achieve the =
same goal, with the added advantage of using the same approach for other us=
e cases (like OOB data delivery).



=C2=A0


IHMO, PPID_EMPTY ap=
proach is not straight forward either as at SCTP level you still have to se=
nd some dummy data (unless SCTP is enhanced) of some size
 (=3D1 or implementation dependent?), which is not obvious to the user. Wil=
l the =E2=80=98bufferedAmount=E2=80=99 be increased appropriately with the =
dummy data sent? Even if it is accounted for, the application has to know t=
his and be mindful of the =E2=80=9Cmysterious=E2=80=9D increase (1
 byte or n bytes?) in =E2=80=98bufferedAmount=E2=80=99, something very uniq=
ue to SCTP.
We will send 1 byte, and this will not be reflected in buffered=
Amount, same as WebSockets.=C2=A0






=



=C2=A0


PPID_OOB approach i=
s transparent to the user as user sends the data, so it is automatically ac=
counted in =E2=80=98bufferedAmount=E2=80=99.




=C2=A0


</Raju>







=C2=A0






I think the PPID_EMPTY approach (probably PPID_EMPTY=
_TEXT and PPID_EMPTY_BINARY, to be precise) is a simple and complete soluti=
on.
















--001a1133901c75685a04fef4755a--


From nobody Thu Jul 24 11:23:59 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DB31A0353 for ; Thu, 24 Jul 2014 11:23:57 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOsgc59lN3O8 for ; Thu, 24 Jul 2014 11:23:52 -0700 (PDT)
Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) (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 24EEC1A00DC for ; Thu, 24 Jul 2014 11:23:51 -0700 (PDT)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTPS; Thu, 24 Jul 2014 20:23:36 +0200 (CEST)
Received: from [192.168.43.175] (2.70.205.140.mobile.tre.se [2.70.205.140]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-10-01.atm.binero.net (Postfix) with ESMTPA id 41C0A3A142; Thu, 24 Jul 2014 20:23:38 +0200 (CEST)
Message-ID: <53D14F29.3040809@omnitor.se>
Date: Thu, 24 Jul 2014 20:23:37 +0200
From: Gunnar Hellstrom 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Michael Tuexen 
References:  <53B71B6E.2010604@omnitor.se> <470AD025-E40B-43BD-B141-599489FB892C@lurchi.franken.de> <53B797C1.3080609@omnitor.se> <596034E6-7D76-4F82-AFD3-521B8C0217B8@lurchi.franken.de>
In-Reply-To: <596034E6-7D76-4F82-AFD3-521B8C0217B8@lurchi.franken.de>
Content-Type: multipart/alternative; boundary="------------030700020305010202000101"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hchVAQr8jWEgag-y9i0lX8LrBTo
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] WGLC for data channel drafts rtcweb-data-channel and rtcweb-data-protocol - missing descriptions of error situations
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 18:23:57 -0000

This is a multi-part message in MIME format.
--------------030700020305010202000101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Michael said below:
"So I think the only thing not covered is what to do if the SCTP 
association fails, but it is obvious to me that all channels are gone. 
Do we need to state that explicitly? What do others think?"

I have not seen any response. I think it belongs to a complete 
specification to cover error situations.
You say that all channels are gone in an error situation. How do you 
define "gone". Who will get an indication and what cleaning up is needed?

I still think a good chapter on error handling is needed, both in the 
API speciifcation and in the data-channel specification. Even if there 
are mechanisms for part of this error handling in SCTP, I think that the 
data-channel specification should tell how the error situations 
influence rtcweb data channels..

I have seen developers wondering in discussion groups why the WebRTC 
channels often get disconnected when they should be reliable. But that 
is in the definition of "reliable", that when all (about 5)  retries are 
done  or any of the timeout mechanisms expire, the association breaks up 
and channels disappear. And from your answers, I get that also the 
partially reliable type of channels will be gone if either the 
association watchdog or the ICE connectivity check fails but not if just 
the configured retransmission limit is reached. I cannot find any 
summary of these mechanisms, so it is just from your responses that I 
have learnt to know them vaguely.

I have earlier proposed some wordings for the data-channel draft. Can it 
be picked up, corrected and inserted into the specification?   ( same 
for the API, and it would be good to coordinate the additions. )

Regards

Gunnar










------------------------------------------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2014-07-07 22:00, Michael Tuexen wrote:
> On 05 Jul 2014, at 08:14, Gunnar Hellstrom  wrote:
>
>> On 2014-07-04 23:34, Michael Tuexen wrote:
>>> On 04 Jul 2014, at 23:23, Gunnar Hellstrom  wrote:
>>>
>>>> I cannot find that what happens in transmission error situations is described in any of these drafts.
>>>>
>>>> Both reliable and partially reliable transmission can fail, and the application designer need to know what happens.
>>> I don't understand the notion of "reliable and partially reliable transmission can fail"...
>>> If a user message gets abandoned (so the stack gives up transmitting/retransmitting it, but
>>> the association stays alive), I don't think it is signalled via the JS API, but that might
>>> be an issue of W3C. If the association fails, all data channel fail. This is signalled.
>>> However, this is something for the W3C document.
>> The W3C mechanism makes use of the rtcweb-data-channel.
>> The rtcweb-data-channel should tell what happens in error situations and if that is possible to be signaled to higher layers.
>> The higher layers should have specified the requirements on the data-channel.
>> If no requirements can be found, we should either propose behavior in error situations or request to get requirements stated from upper layers.
> SCTP tells the user if the association has failed. At that point all data channels
> must be closed. But I think this is something which needs to be stated in the
> W3C document...
>>>> We discussed it earlier, and came to the conclusion that
>>>> A failing reliable channel will tear down the connection and some indication will be provided if possible to the application.
>>>> A failing partially reliable channel will enable transmission of next data item. ( I do not remember if the application will get any error indication or if it needs to have its own sequence checking if it is interested in knowing if there are no gaps. )
>>>>
>>>> I suggest that a section on failure handling is added. I get the impression that it is in the data-channel draft it would be best suited.
>>> But this is about the API. So it should go into the W3C document.
>> The API can only provide the functions provided by the mechanisms it has underneath.
>>
>> There was a mail discussion in webRTC about the error situations.
>> A conclusion was that if a reliable channel reaches its retry limit ( that is usually only about 5 for WebRTC) or some other indication that the channel failed to convey the data, then the channel shall be broken (by the channel) and indications provided to both sides if possible. (another reasons mentioned was missed heartbeats for the whole association, setting a retry time limit of - what was it - - - 15 seconds?)
> A reliable channel doesn't have a limit. The association has. If the association breaks,
> all data channels are gone.
>> If the retries or retransmission time is exceeded for a partially reliable channel, the conclusion was that communication can continue with next data item. I am not sure if the applications were to
> It will continue. It is not a stop and wait...
>> get any notification about that or if they need to introduce sequence number checking themselves if they are interested to know.
> I don't think so. I don't see anything in the JS API.
>>
>>
>> I cannot see how we can avoid describing the mechanisms needed and what happens to the channel.
>>
>>
>> I found a sentence about this  in section 6.6 of the data-channel-11 draft.
>>
>> "
>>
>> If a message with an unsupported PPID is received or some error is
>>   detected by the receiver (for example, illegal ordering), the
>>   receiver SHOULD close the corresponding data channel."
>>
>>
>> This paragraph could be extended to tell more about error situations in open channels.
>> I suggest to move this sentence to a new section and add description of other situations. The sentence only tells about errors detected at the receiving end. But it can also be the transmitting end that detects the problem. It should be stated what shall be done then.T
>>
>> Something like this ( with my questions in paranthesis).
>> -------------------------------------------------------Proposed error handling section in rtcweb-data-channel---------------------------------------------------------------------------
>> 6.7 Transmission failure and error handling
>> Failures can occur when a data channel is open.
>>
>> If transmission in a reliable channel fails, the channel shall be closed by the party detecting the failure and an error indication provided.      ( what does STCP do in this situation? )
> This can't happen. Only the association can fail and in this case all data channels are gone...
>> If a watchdog times out, the channel shall be closed with an error indication.         ( if this is part of the channel mechanisms, I have not seen where it is defined.)
> If you think about SCTP HEARTBEATs, it is like the above. But it is more likely
> that ICE will detect it first.
>> If retransmissions or transmission time is exceeded in a partially reliable channel, the transmission SHALL be allowed to continue with next data item.
> It is not stop and wait... next item might be transmitted before the message is abandoned.
>> If reception out-of order is detected from an SCTP channel for which ordered transmission is requested, the receiver SHALL close the data channel.
> This is covered by the text cited above.
>> If a message with an unsupported PPID is received or some logical error is detected by the receiver, the receiver SHALL close the corresponding data channel.
> This is covered by the text cited above.
>
> So I think the only thing not covered is what to do if the SCTP association fails,
> but it is obvious to me that all channels are gone. Do we need to state that
> explicitly? What do others think?
>
> Best regards
> Michael
>> --------------------End of proposed section on failure handling---------------------------------------------------------------------------------------------------------------------------
>>
>>
>>
>> Regards
>>
>> /Gunnar
>>
>>> Best regards
>>> Michael
>>>> Regards
>>>>
>>>> Gunnar
>>>> Gunnar Hellström
>>>> Omnitor
>>>> gunnar.hellstrom@omnitor.se
>>>> On 2014-06-10 20:52, Ted Hardie wrote:
>>>>> Dear WG,
>>>>>
>>>>> This starts a working group last call for our core Data Channel drafts:
>>>>>
>>>>> draft-ietf-rtcweb-data-protocol-06.txt
>>>>> draft-ietf-rtcweb-data-channel-10.txt
>>>>>
>>>>> Please review them in detail, especially for areas which may be of concern to the broader IETF community.  This WGLC will end on June 27, 2014.
>>>>>
>>>>> Ted, Sean, Cullen
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>


--------------030700020305010202000101
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Michael said below:

      "So I think the only thing not covered is what to do if the SCTP
      association fails,
      but it is obvious to me that all channels are gone. Do we need to
      state that
      explicitly? What do others think?"

      

      I have not seen any response. I think it belongs to a complete
      specification to cover error situations.

      You say that all channels are gone in an error situation. How do
      you define "gone". Who will get an indication and what cleaning up
      is needed?

      

      I still think a good chapter on error handling is needed, both in
      the API speciifcation and in the data-channel specification. Even
      if there are mechanisms for part of this error handling in SCTP, I
      think that the data-channel specification should tell how the
      error situations influence rtcweb data channels..

      

      I have seen developers wondering in discussion groups why the
      WebRTC channels often get disconnected when they should be
      reliable. But that is in the definition of "reliable", that when
      all (about 5)  retries are done  or any of the timeout mechanisms
      expire, the association breaks up and channels disappear. And from
      your answers, I get that also the partially reliable type of
      channels will be gone if either the association watchdog or the
      ICE connectivity check fails but not if just the configured
      retransmission limit is reached. I cannot find any summary of
      these mechanisms, so it is just from your responses that I have
      learnt to know them vaguely.

      

      I have earlier proposed some wordings for the data-channel draft.
      Can it be picked up, corrected and inserted into the
      specification?   ( same for the API, and it would be good to
      coordinate the additions. ) 

      

      Regards

      

      Gunnar

      

      

      

      

          

      

      

      

      

      

      

        

        Gunnar Hellström

        Omnitor

        gunnar.hellstrom@omnitor.se

        +46708204288

      

      On 2014-07-07 22:00, Michael Tuexen wrote:

    

    

      
On 05 Jul 2014, at 08:14, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote:



      

        
On 2014-07-04 23:34, Michael Tuexen wrote:


        

          
On 04 Jul 2014, at 23:23, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote:



          

            
I cannot find that what happens in transmission error situations is described in any of these drafts.

Both reliable and partially reliable transmission can fail, and the application designer need to know what happens.


          

          
I don't understand the notion of "reliable and partially reliable transmission can fail"...
If a user message gets abandoned (so the stack gives up transmitting/retransmitting it, but
the association stays alive), I don't think it is signalled via the JS API, but that might
be an issue of W3C. If the association fails, all data channel fail. This is signalled.
However, this is something for the W3C document.


        

        
The W3C mechanism makes use of the rtcweb-data-channel.
The rtcweb-data-channel should tell what happens in error situations and if that is possible to be signaled to higher layers.
The higher layers should have specified the requirements on the data-channel.
If no requirements can be found, we should either propose behavior in error situations or request to get requirements stated from upper layers.


      

      
SCTP tells the user if the association has failed. At that point all data channels
must be closed. But I think this is something which needs to be stated in the
W3C document...


      

        

          

            
We discussed it earlier, and came to the conclusion that
A failing reliable channel will tear down the connection and some indication will be provided if possible to the application.
A failing partially reliable channel will enable transmission of next data item. ( I do not remember if the application will get any error indication or if it needs to have its own sequence checking if it is interested in knowing if there are no gaps. )

I suggest that a section on failure handling is added. I get the impression that it is in the data-channel draft it would be best suited.


          

          
But this is about the API. So it should go into the W3C document.


        

        
The API can only provide the functions provided by the mechanisms it has underneath.

There was a mail discussion in webRTC about the error situations.
A conclusion was that if a reliable channel reaches its retry limit ( that is usually only about 5 for WebRTC) or some other indication that the channel failed to convey the data, then the channel shall be broken (by the channel) and indications provided to both sides if possible. (another reasons mentioned was missed heartbeats for the whole association, setting a retry time limit of - what was it - - - 15 seconds?)


      

      
A reliable channel doesn't have a limit. The association has. If the association breaks,
all data channels are gone.


      

        
If the retries or retransmission time is exceeded for a partially reliable channel, the conclusion was that communication can continue with next data item. I am not sure if the applications were to 


      

      
It will continue. It is not a stop and wait...


      

        
get any notification about that or if they need to introduce sequence number checking themselves if they are interested to know.


      

      
I don't think so. I don't see anything in the JS API.


      

        


I cannot see how we can avoid describing the mechanisms needed and what happens to the channel.


I found a sentence about this  in section 6.6 of the data-channel-11 draft.

"

If a message with an unsupported PPID is received or some error is
 detected by the receiver (for example, illegal ordering), the
 receiver SHOULD close the corresponding data channel."


This paragraph could be extended to tell more about error situations in open channels.
I suggest to move this sentence to a new section and add description of other situations. The sentence only tells about errors detected at the receiving end. But it can also be the transmitting end that detects the problem. It should be stated what shall be done then.T

Something like this ( with my questions in paranthesis).
-------------------------------------------------------Proposed error handling section in rtcweb-data-channel---------------------------------------------------------------------------
6.7 Transmission failure and error handling
Failures can occur when a data channel is open.

If transmission in a reliable channel fails, the channel shall be closed by the party detecting the failure and an error indication provided.      ( what does STCP do in this situation? )


      

      
This can't happen. Only the association can fail and in this case all data channels are gone...


      

        
If a watchdog times out, the channel shall be closed with an error indication.         ( if this is part of the channel mechanisms, I have not seen where it is defined.)


      

      
If you think about SCTP HEARTBEATs, it is like the above. But it is more likely
that ICE will detect it first.


      

        
If retransmissions or transmission time is exceeded in a partially reliable channel, the transmission SHALL be allowed to continue with next data item.


      

      
It is not stop and wait... next item might be transmitted before the message is abandoned.


      

        
If reception out-of order is detected from an SCTP channel for which ordered transmission is requested, the receiver SHALL close the data channel.


      

      
This is covered by the text cited above.


      

        
If a message with an unsupported PPID is received or some logical error is detected by the receiver, the receiver SHALL close the corresponding data channel.


      

      
This is covered by the text cited above.

So I think the only thing not covered is what to do if the SCTP association fails,
but it is obvious to me that all channels are gone. Do we need to state that
explicitly? What do others think?

Best regards
Michael


      

        
--------------------End of proposed section on failure handling---------------------------------------------------------------------------------------------------------------------------



Regards

/Gunnar



        

          
Best regards
Michael


          

            
Regards

Gunnar
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
On 2014-06-10 20:52, Ted Hardie wrote:


            

              
Dear WG,

This starts a working group last call for our core Data Channel drafts:

draft-ietf-rtcweb-data-protocol-06.txt
draft-ietf-rtcweb-data-channel-10.txt

Please review them in detail, especially for areas which may be of concern to the broader IETF community.  This WGLC will end on June 27, 2014.

Ted, Sean, Cullen


_______________________________________________
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


          

        

        



      

      

    

    

  


--------------030700020305010202000101--


From nobody Thu Jul 24 11:47:15 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849171A0417 for ; Thu, 24 Jul 2014 11:47:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uzZeTlxHinj for ; Thu, 24 Jul 2014 11:47:11 -0700 (PDT)
Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 065871A03E4 for ; Thu, 24 Jul 2014 11:47:10 -0700 (PDT)
Received: by mail-wg0-f49.google.com with SMTP id k14so3183837wgh.20 for ; Thu, 24 Jul 2014 11:47:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=oJEyWO0NaSsCh68md3/rt6cllJBYkcWVzVS/e1hsGes=; b=PtLRZPReKBXms8Hv8QDt8raOFRyuiQFw7kG8Jr2nf8SPukfFs6UmBYVU6HYhRA5NSc IpFuaAP5q73L9GejcNdGH6RAwjKE00QkZQjMa9HBMk4dzbOXVipY99ru+6i4VxqCiBjF irGYik1yZQEUFJ69rDtwEcjOG2Q1PDAJzHnQNwnsr5bn2zM6wiMGLtP0Nqtz5nl0w+K3 tBp3V02XD2APsDTHb4k1bMamsrfaJNuw9agb3jRarc1dufX1Prdx52CfdnzJFRqTvZyi 6e04tKJ0VCCkwoYzIs7oPjl21fb7e7CHyUim/FAZ9SV2EPRHxaQroHl2c9dEGfWGG0n5 WVPQ==
MIME-Version: 1.0
X-Received: by 10.194.91.228 with SMTP id ch4mr14820915wjb.59.1406227629527; Thu, 24 Jul 2014 11:47:09 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Thu, 24 Jul 2014 11:47:09 -0700 (PDT)
Date: Thu, 24 Jul 2014 11:47:09 -0700
Message-ID: 
From: Martin Thomson 
To: "rtcweb@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3EXt0KkcZ5RKe8pC1Lxnq1_KD2M
Subject: [rtcweb] Confidentiality for data channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 18:47:12 -0000

One issue that I neglected to mention yesterday in the ALPN discussion is this:

What do we do with data channels?

After discussions with Michael Procter, I have reached something of a
conclusion on the subject and wanted to share and get more feedback.

There are two approaches that immediately spring to mind:

1. forbid the use of data channels (at least in their present form)
when the RTCPeerConnection is in a confidential mode

2. permit the use of data channels and note that their contents are
not, and cannot ever be, confidential, since they innately require
that applications create and consume their contents

I think that the latter option is closer to reality, though it makes
me a little sad about the potential to do things like confidential
file sharing or confidential text chat, even if we have no current
desire to provide these features (and the necessary widgets) in
browsers.

So I think that we have a third option (which I now believe was
previously mentioned by someone else in the past), which is to allow
for the creation of this feature in the future.  This is option 2, but
we note that maybe something else can be built later if we want this
feature.  That something else could be a new SCTP PPID that marks
confidential data separate to the current set of two (and maybe 3 or
4) PPIDs that are not confidential.


From nobody Thu Jul 24 12:19:51 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0DA1B2803 for ; Thu, 24 Jul 2014 12:19:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C28cRT7TShdW for ; Thu, 24 Jul 2014 12:19:48 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 488CA1B27F9 for ; Thu, 24 Jul 2014 12:19:48 -0700 (PDT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s6OJJi1d011595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Jul 2014 14:19:45 -0500 (CDT)
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s6OJJicV015662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jul 2014 15:19:44 -0400
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Thu, 24 Jul 2014 15:19:44 -0400
From: "Makaraju, Maridi Raju (Raju)" 
To: Justin Uberti 
Thread-Topic: [rtcweb] Sending of zero-length messages over data channels
Thread-Index: AQHPpipfEWtPO6jXOES6Y6R7CwNaxJutiTxggAI5gwD//74D0IAATLYA///AneA=
Date: Thu, 24 Jul 2014 19:19:44 +0000
Message-ID: 
References:     
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.18]
Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E4C5E94US70UWXCHMBA02z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/LUsYQdyt0HSNvimmZA2hMDzqQQo
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Sending of zero-length messages over data channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 19:19:50 -0000

--_000_E1FE4C082A89A246A11D7F32A95A17828E4C5E94US70UWXCHMBA02z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

PldlIHdpbGwgc2VuZCAxIGJ5dGUsIGFuZCB0aGlzIHdpbGwgbm90IGJlIHJlZmxlY3RlZCBpbiBi
dWZmZXJlZEFtb3VudCwgc2FtZSBhcyBXZWJTb2NrZXRzLg0KPFJhanU+IEkgY291bGQgYmUgd3Jv
bmcsIGJ1dCBJIGFtIG5vdCBzdXJlIGhvdyAxIGR1bW15IGJ5dGUgY2FuIGJlIHNlbnQgb3ZlciBX
ZWJzb2NrZXRzPyEgSSBkbyBub3Qgc2VlIGFueSBzcGVjaWFsIGZyYW1lIHR5cGUgZGVmaW5lZCBh
dCBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3dlYnNvY2tldC93ZWJzb2NrZXQueG1s
IGZvciB0aGlzIGR1bW15IGJ5dGUgcHVycG9zZTsgd2l0aG91dCB0aGF0IGhvdyBkb2VzIHRoZSBv
dGhlciBlbmQga25vdyB0byBpZ25vcmUgaXQ/IE15IHVuZGVyc3RhbmRpbmcgaXMgV2Vic29ja2V0
IHByb3RvY29sIGFsbG93cyB6ZXJvLWxlbmd0aCBmcmFtZXMgYnkgZGVmYXVsdC4NCkFsc28sIHRo
ZSB3ZWJraXQgYnVnIGZpeCBmb3Igd2Vic29ja2V0IGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3No
b3dfYnVnLmNnaT9pZD02NTU5MiB0YWxrcyBhYm91dCBoYW5kbGluZyB6ZXJvIGxlbmd0aCBwYXls
b2FkIGFzIG9wcG9zZWQgdG8gc2VuZGluZyBhIGR1bW15IGJ5dGUuDQoNCkluIGNvbmNsdXNpb24s
IEkgdGhpbmsgd2Vic29ja2V0IEFQSSBzdXBwb3J0cyB6ZXJvIGxlbmd0aCBiZWNhdXNlIHdlYnNv
Y2tldCBwcm90b2NvbCBzdXBwb3J0cyB6ZXJvLWxlbmd0aCBkYXRhIGZyYW1lcy4gU28sIGl0IGRv
ZXMgbm90IGhhdmUgdGhlIGlzc3VlIG9mIOKAmGJ1ZmZlcmVkQW1vdW504oCZIGRpc2NyZXBhbmN5
Lg0KDQoNCjwvUmFqdT4NCkJSDQpSYWp1DQoNCg0K

--_000_E1FE4C082A89A246A11D7F32A95A17828E4C5E94US70UWXCHMBA02z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi
O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw
YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y
OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uaG9lbnpiDQoJe21z
by1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K
CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0
LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp
bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y
ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd
LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+
DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht
bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2
bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2IHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAw
aW4gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48L3NwYW4+PC9pPjwvYj48c3Bh
biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5XZSB3aWxsIHNlbmQgMSBieXRlLCBh
bmQgdGhpcyB3aWxsIG5vdCBiZSByZWZsZWN0ZWQgaW4gYnVmZmVyZWRBbW91bnQsIHNhbWUgYXMg
V2ViU29ja2V0cy4mbmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZsdDtSYWp1Jmd0OyBJIGNvdWxkIGJlIHdyb25nLCBi
dXQgSSBhbSBub3Qgc3VyZSBob3cgMSBkdW1teSBieXRlIGNhbiBiZSBzZW50IG92ZXIgV2Vic29j
a2V0cz8hIEkgZG8gbm90IHNlZSBhbnkgc3BlY2lhbCBmcmFtZSB0eXBlIGRlZmluZWQgYXQNCjxh
IGhyZWY9Imh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvd2Vic29ja2V0L3dlYnNvY2tl
dC54bWwiPmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvd2Vic29ja2V0L3dlYnNvY2tl
dC54bWw8L2E+IGZvciB0aGlzIGR1bW15IGJ5dGUgcHVycG9zZTsgd2l0aG91dCB0aGF0IGhvdyBk
b2VzIHRoZSBvdGhlciBlbmQga25vdyB0byBpZ25vcmUgaXQ/IE15IHVuZGVyc3RhbmRpbmcgaXMg
V2Vic29ja2V0IHByb3RvY29sIGFsbG93cyB6ZXJvLWxlbmd0aA0KIGZyYW1lcyBieSBkZWZhdWx0
LjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+
PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFsc28sIHRoZSB3
ZWJraXQgYnVnIGZpeCBmb3Igd2Vic29ja2V0PC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0KPGEgaHJlZj0iaHR0cHM6Ly9idWdzLndlYmtp
dC5vcmcvc2hvd19idWcuY2dpP2lkPTY1NTkyIj5odHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93
X2J1Zy5jZ2k/aWQ9NjU1OTI8L2E+DQo8Yj48aT50YWxrcyBhYm91dCBoYW5kbGluZyB6ZXJvIGxl
bmd0aCBwYXlsb2FkIGFzIG9wcG9zZWQgdG8gc2VuZGluZyBhIGR1bW15IGJ5dGUuPG86cD48L286
cD48L2k+PC9iPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPkluIGNvbmNsdXNpb24sIEkgdGhpbmsgd2Vic29ja2V0IEFQSSBzdXBw
b3J0cyB6ZXJvIGxlbmd0aCBiZWNhdXNlIHdlYnNvY2tldCBwcm90b2NvbCBzdXBwb3J0cyB6ZXJv
LWxlbmd0aCBkYXRhIGZyYW1lcy4gU28sIGl0IGRvZXMgbm90IGhhdmUgdGhlIGlzc3VlDQogb2Yg
4oCYYnVmZmVyZWRBbW91bnTigJkgZGlzY3JlcGFuY3kuIDxvOnA+PC9vOnA+PC9zcGFuPjwvaT48
L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPiZsdDsvUmFqdSZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj5CUjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PlJhanU8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o
dG1sPg0K

--_000_E1FE4C082A89A246A11D7F32A95A17828E4C5E94US70UWXCHMBA02z_--


From nobody Thu Jul 24 12:28:21 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E331B280E for ; Thu, 24 Jul 2014 12:28:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 PO8yFn7QVbKF for ; Thu, 24 Jul 2014 12:28:19 -0700 (PDT)
Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2871B27F9 for ; Thu, 24 Jul 2014 12:28:18 -0700 (PDT)
Received: by mail-vc0-f175.google.com with SMTP id hu12so5715971vcb.20 for ; Thu, 24 Jul 2014 12:28:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VAdn+CMDhCyGPEeCyqBB97W5+ralRlndNoFenViq0/Y=; b=GCF7MM3dQKC6Z3er5vmpzj7UAQwl3qBc7160LNKRjNvSYysfTF1hSv5jZIVGvuEEWf NCsG1gnkev1fMwnRazQx4weHgbRibxeU6TFz4y3DHm1MCYTPVm7Y0RAIaNPd/Z5IAGJ7 c0vK2lABAPxl5C0bc1gFuZwpwldS3dA2nDw44pMV0gw1L5mqLYxczP+opXGDKrjl+a5K wioFZGQvGmIc7PFkj5KzPjUuYQLMg5oF3xKttna+6X7653wDDPRmfmnH1Vo06faiHasw cqBFN41gdwMu4mI8udvUzHb+P7A8VGLvuEzSBhK8O5ZZFm6x8PQ1euOwDnX4POAvX1FS DVwg==
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:content-type; bh=VAdn+CMDhCyGPEeCyqBB97W5+ralRlndNoFenViq0/Y=; b=ZYN7MzX9wNK6AqT1Wv2jbqZyckKEDAlgcpLsjpYP9j5BA+2t9bNMhls/QKHqzY2Rqa pj14KTzOPHsZyA8oD4tiBmHN1GeLyS1T3QTbJnFpoZQZI21dOx6fM2wEB2DOZ4YC5Ew5 Hb6RxfqJvGAnp1ZZvXNdDM7VIuXDgSUleakAzbjhKHABGU2ygoX3glYuHgoVWNkxh5e3 sRrzO5YcGWI7OAtsXPtlvBM0rxu6+02qHfYjs3aTGh2nJiFdguSi+Sq4Izrd+2e7nt6t WYa7RbmCHrdIyb4zMK7wPL8Ijksny1KVVeqq2T0i1KAFi0lV3IMOe36gkuF5+onfUHcx 1O3g==
X-Gm-Message-State: ALoCoQnPH9SO26/6m/P53s0xNP7DT82gYrrzYyx/JVHV9AEpe3PMpxJ2AowDB6VPoQX18Bf3AYo6
X-Received: by 10.220.49.10 with SMTP id t10mr15712569vcf.34.1406230095957; Thu, 24 Jul 2014 12:28:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.4.70 with HTTP; Thu, 24 Jul 2014 12:27:55 -0700 (PDT)
In-Reply-To: 
References:      
From: Justin Uberti 
Date: Thu, 24 Jul 2014 15:27:55 -0400
Message-ID: 
To: "Makaraju, Maridi Raju (Raju)" 
Content-Type: multipart/alternative; boundary=089e0163412c57b47404fef575a4
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/efEfS2xW8M3bBeZp3oleQMp9r9A
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Sending of zero-length messages over data channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 19:28:20 -0000

--089e0163412c57b47404fef575a4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 24, 2014 at 3:19 PM, Makaraju, Maridi Raju (Raju) <
Raju.Makaraju@alcatel-lucent.com> wrote:

>     >We will send 1 byte, and this will not be reflected in
> bufferedAmount, same as WebSockets.
>
> * I could be wrong, but I am not sure how 1 dummy byte can be sent
> over Websockets?! I do not see any special frame type defined at
> http://www.iana.org/assignments/websocket/websocket.xml
>  for this dummy
> byte purpose; without that how does the other end know to ignore it? My
> understanding is Websocket protocol allows zero-length frames by default.=
*
>
> *Also, the webkit bug fix for websocket*
> https://bugs.webkit.org/show_bug.cgi?id=3D65592 *talks about handling zer=
o
> length payload as opposed to sending a dummy byte.*
>
>
>
> *In conclusion, I think websocket API supports zero length because
> websocket protocol supports zero-length data frames. So, it does not have
> the issue of =E2=80=98bufferedAmount=E2=80=99 discrepancy. *
>
>
>

Yes, that is what I meant.

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





On Thu, Jul 24, 2014 at 3:19 PM, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:
























<=
span style=3D"color:#1f497d">>We will send 1 byte, and this will =
not be reflected in bufferedAmount, same as WebSockets.=C2=A0




<Raju> =
I could be wrong, but I am not sure how 1 dummy byte can be sent over Webso=
ckets?! I do not see any special frame type defined at
http://www.iana.org/assignments/websocket/websocket.xml for=
 this dummy byte purpose; without that how does the other end know to ignor=
e it? My understanding is Websocket protocol allows zero-length
 frames by default.


Also, the webkit bu=
g fix for websocket
https://bugs.webkit.org/show_bug.cgi?id=3D65592
talks about handling zero length payload as opposed to sending a dumm=
y byte.


=C2=A0


In conclusion, I th=
ink websocket API supports zero length because websocket protocol supports =
zero-length data frames. So, it does not have the issue
 of =E2=80=98bufferedAmount=E2=80=99 discrepancy. =



=C2=A0



Yes, that is what I meant.=C2=A0


--089e0163412c57b47404fef575a4--


From nobody Thu Jul 24 12:51:28 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5BF1A0AC8 for ; Thu, 24 Jul 2014 12:51:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.332
X-Spam-Level: 
X-Spam-Status: No, score=0.332 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 bAEQxxflyvg5 for ; Thu, 24 Jul 2014 12:51:23 -0700 (PDT)
Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.41.248.28]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1689A1A0AC7 for ; Thu, 24 Jul 2014 12:51:23 -0700 (PDT)
Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id 6328DEC22C873; Thu, 24 Jul 2014 14:51:22 -0500 (CDT)
Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway03.websitewelcome.com (Postfix) with ESMTP id 7243EEC226E7F for ; Thu, 24 Jul 2014 14:51:00 -0500 (CDT)
Received: from [31.133.164.43] (port=52167 helo=dhcp-a42b.meeting.ietf.org) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XAP2Z-00025t-Rj for rtcweb@ietf.org; Thu, 24 Jul 2014 14:51:00 -0500
From: Sean Turner 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <2184C33E-F1E0-4B31-BC59-6AA11260E1EF@ieca.com>
Date: Thu, 24 Jul 2014 15:50:53 -0400
To: rtcweb@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator3286.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source-IP: 31.133.164.43
X-Exim-ID: 1XAP2Z-00025t-Rj
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (dhcp-a42b.meeting.ietf.org) [31.133.164.43]:52167
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 3
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/83_BfU_x_-I0pCw8-948ZoqniHk
Subject: [rtcweb] call for adoption: draft-draft-proust-rtcweb-audio-codecs-for-interop
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 19:51:24 -0000

At the RTCWEB session on Thursday there was support for adoption of =
draft-proust-rtcweb-audio-codecs-for-interop as an informational WG =
draft.  If you do not support adoption of this draft as a WG draft =
please respond to this email by August 1st.  Please also indicate why =
you do not support WG adoption.

spt=


From nobody Thu Jul 24 13:12:35 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3291A0AC6 for ; Thu, 24 Jul 2014 13:12:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 uehcBIEBs38D for ; Thu, 24 Jul 2014 13:12:32 -0700 (PDT)
Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F2411A01D6 for ; Thu, 24 Jul 2014 13:12:32 -0700 (PDT)
Received: by mail-vc0-f178.google.com with SMTP id la4so5861366vcb.9 for ; Thu, 24 Jul 2014 13:12:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=jZ2ojzyCVHSDpbPB0+4bdwA3/u1bMh8wLSrCMKisaLY=; b=cZVQExOryyOiFIdv7iKWk7tO/8jgnCFA6Ew8/5BvLuWxqTfm1vcP7KdXxw5iJO0c8o WPW0aJie5BQeeFhBGfQRfB3n9bbrAS08tBoWagLo5cwy9orXygc3Y/j5llw9bTU8bTmJ TjjUSaSxyMnlSBublyF6+arltbSjljkkQ2Ip7ecJk4ss5rfz3XkONJL/wPiBgNa3oEmU 0fPrKjX8AizDSfb79DY8WURk81fFpt6lbusQn10J+SpgCbSshrrF3t7thYfo8EZ6gkiz cc+BqUftRFZ+OIIcelP/gA70QMlGeLaqiuBo/AuaA3yS2ZR/GaqrLy7XjbMNDrX1lxzB bBuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=jZ2ojzyCVHSDpbPB0+4bdwA3/u1bMh8wLSrCMKisaLY=; b=fOj2rVlftIr+O3lb1yqDpujrfK2w/pbUTSNcuuY7fZVJIr6UUJZiVeO2mGEu42uOsJ 8YRW0r8UnRQldFWiT6b2gblkB0BzBSpQjbESRGdm5UEHx4m4iiR9Sv1QSpYwVB62JCly MWb3DU2d2n4ogPC9KudkD7zEUa1auaC5/Gq+kKeCH06MZTq++UjZZUJ46cMPrk+f7mNp nAfVg6c/VOBnIi1kRzzFW9Mh2lWWVEe73PdE1C2dNhTiKa6cP6bfrdmRCDKj/xcH7GH5 t3M7qXvz6CGqU0cbuNzEQcqFj8tL7jpkvyC0y2NH6Vm7o21JbA1b2kU4dsz8wTQNicaX xfmA==
X-Gm-Message-State: ALoCoQktTBnIz2/8Ul8TP6lMvhJrso5Lmn8bU/wL3wqAMef0E37ccTMl0f74Eo1g7GcI42qyWCuH
X-Received: by 10.221.44.69 with SMTP id uf5mr16214798vcb.4.1406232750330; Thu, 24 Jul 2014 13:12:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.4.70 with HTTP; Thu, 24 Jul 2014 13:12:10 -0700 (PDT)
From: Justin Uberti 
Date: Thu, 24 Jul 2014 16:12:10 -0400
Message-ID: 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11339e888e338a04fef613e3
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/WNywQw_frFz6sg75bSb3GG5rMwU
Subject: [rtcweb] Suggestion of text to handle zero-length message issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 20:12:34 -0000

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

In http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-11#section-6.6,
I suggest the following text:

   The SCTP Payload Protocol Identifiers (PPIDs) are used to signal the
   interpretation of the "Payload data", indicating whether it contains a
   string or binary data. Also, because SCTP does not permit
   zero-length messages, they must be handled specially.

   For normal messages, of nonzero length, the PPID "WebRTC String"
   MUST be used to indicate a JavaScript string encoded in UTF-8, and the
   PPID "WebRTC Binary" MUST be used to indicate JavaScript binary data
   (ArrayBuffer or Blob).

   For zero-length messages, the PPID "WebRTC String Empty" MUST
   be used to indicate an empty Javascript string, and the PPID
   "WebRTC Binary Empty" MUST be used to indicate zero-length binary data.
   In either case, a payload consisting of a single (dummy) zero byte MUST
   be supplied to the SCTP layer on the sending side, and regardless of
   any received payload, these messages must be interpreted as
   empty strings or zero-length binary data, as appropriate, on the
receiving side.

   See Section 8 for details on the exact PPID values.

And in Section 8:

        WebRTC String Empty                      55
        WebRTC Binary Empty                     56

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


In=C2=A0http://tools.ietf.org/html/draft-ietf-rt=
cweb-data-channel-11#section-6.6, I suggest the following text:



=C2=A0 =C2=A0The SCTP Payload Protocol Identifiers (PPIDs) are used to=
 signal the
=C2=A0 =C2=A0interpretation of the "Payload data=
", indicating whether it contains a=C2=A0
=C2=A0 =C2=A0strin=
g or binary data. Also, because SCTP does not permit



=C2=A0 =C2=A0zero-length messages, they must be handled specially.=C2=
=A0

=C2=A0 =C2=A0For normal messages, of nonzero l=
ength, the PPID "WebRTC String"
=C2=A0 =C2=A0MUST be us=
ed to indicate a JavaScript string encoded in UTF-8, and the



=C2=A0 =C2=A0PPID "WebRTC Binary" MUST be used to indicate J=
avaScript binary data
=C2=A0 =C2=A0(ArrayBuffer or Blob).

=C2=A0 =C2=A0For zero-length messages, the PPID "Web=
RTC String Empty" MUST



=C2=A0 =C2=A0be used to indicate an empty Javascript string, and the P=
PID=C2=A0
=C2=A0 =C2=A0"WebRTC Binary Empty" MUST be us=
ed to indicate zero-length binary data.
=C2=A0 =C2=A0In either ca=
se, a payload consisting of a single (dummy) zero byte MUST=C2=A0



=C2=A0 =C2=A0be supplied to the SCTP layer on the sending side, and re=
gardless of
=C2=A0 =C2=A0any received payload, these messages mus=
t be interpreted as=C2=A0
=C2=A0 =C2=A0empty strings or zero-leng=
th binary data, as appropriate, on the receiving side.




=C2=A0 =C2=A0See Section 8 for details on the exact PPI=
D values.

And in Section 8:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 WebRTC String Empty =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A055
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 WebRTC Binary Empty =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 56



=C2=A0 =C2=A0 =C2=A0=C2=A0







--001a11339e888e338a04fef613e3--


From nobody Thu Jul 24 13:18:46 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2471ABB2E for ; Thu, 24 Jul 2014 13:18:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNlWqHd4Kin1 for ; Thu, 24 Jul 2014 13:18:44 -0700 (PDT)
Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 353FE1ADDC7 for ; Thu, 24 Jul 2014 13:18:37 -0700 (PDT)
Received: by mail-we0-f179.google.com with SMTP id u57so3308371wes.24 for ; Thu, 24 Jul 2014 13:18:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ovsQbaUDma+rWVp/rC2tbAgl4Oql739GHT9Fw+260Fg=; b=hu3oh1K3hlCGHp1ZANiS0yCCO6MF8vXHJjzSmyP/zwNa630OdDY4NM710XV0/jDDzL pIlunx65wYagILBF3O28G27w7bYYs2lUcXsK8Zt4SIyfmkXEBsKXd0h+XaMacCT9q1ql FJsZ/cDhsbxS6iSzNDU0PZZJn4NO84k+WkUtG+rdMPCUYMoGb9T0z18Ju+ahJsIyaYuN BrF9ZtrhIwIpa3hlKtDDuq2Ox/hJ5gmpNjRkna034ZkhyuXc3GjHQCswLTiSr92gFKx6 D+KgmeINqV6KmcnZwzMQJ2qiOUWi6AaFoH5qnH/zXatimHoOHAdiMjEzRISQZIDpR3ZA NUUw==
X-Received: by 10.194.123.105 with SMTP id lz9mr15911564wjb.122.1406233115558;  Thu, 24 Jul 2014 13:18:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.217.122.65 with HTTP; Thu, 24 Jul 2014 13:18:15 -0700 (PDT)
In-Reply-To: <2184C33E-F1E0-4B31-BC59-6AA11260E1EF@ieca.com>
References: <2184C33E-F1E0-4B31-BC59-6AA11260E1EF@ieca.com>
From: Bernard Aboba 
Date: Thu, 24 Jul 2014 16:18:15 -0400
Message-ID: 
To: Sean Turner 
Content-Type: multipart/alternative; boundary=089e01177699530b8504fef62973
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/CngAZ3D8crvBV_yntcx9t7A6tlQ
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-audio-codecs-for-interop
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 20:18:45 -0000

--089e01177699530b8504fef62973
Content-Type: text/plain; charset=UTF-8

I do not support adoption of the draft in its current form, for the
following reasons:

a. The draft only currently covers AMR-WB, AMR and G.722.  Since the AMR
codecs generally are accessible only through a proprietary "blackbox" API
that does not permit WebRTC use without a separate license, these codecs
are not currently practical to support in browsers, even in operating
systems that support AMR-WB/AMR for other uses.

b. The remaining codec (G.722) does not have these issues, and so it could
be implemented in browsers.  However, the useful text in this portion of
the document is so small that it does not justify creation of yet another
document, even a separate one.


On Thu, Jul 24, 2014 at 3:50 PM, Sean Turner  wrote:

> At the RTCWEB session on Thursday there was support for adoption of
> draft-proust-rtcweb-audio-codecs-for-interop as an informational WG draft.
>  If you do not support adoption of this draft as a WG draft please respond
> to this email by August 1st.  Please also indicate why you do not support
> WG adoption.
>
> spt
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

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


I do not support adoption of the draft in its current form=
, for the following reasons:=C2=A0

a. The draft only cur=
rently covers AMR-WB, AMR and G.722. =C2=A0Since the AMR codecs generally a=
re accessible only through a proprietary "blackbox" API that does=
 not permit WebRTC use without a separate license, these codecs are not cur=
rently practical to support in browsers, even in operating systems that sup=
port AMR-WB/AMR for other uses.




b. The remaining codec (G.722) does not have these issu=
es, and so it could be implemented in browsers. =C2=A0However, the useful t=
ext in this portion of the document is so small that it does not justify cr=
eation of yet another document, even a separate one.=C2=A0





On Thu,=
 Jul 24, 2014 at 3:50 PM, Sean Turner <TurnerS@ieca.com> wrot=
e:



At the RTCWEB session on Thursday there was =
support for adoption of draft-proust-rtcweb-audio-codecs-for-interop as an =
informational WG draft. =C2=A0If you do not support adoption of this draft =
as a WG draft please respond to this email by August 1st. =C2=A0Please also=
 indicate why you do not support WG adoption.





spt

_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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





--089e01177699530b8504fef62973--


From nobody Thu Jul 24 13:22:51 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2415F1B2844 for ; Thu, 24 Jul 2014 13:22:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 9MPZ1-2NggpI for ; Thu, 24 Jul 2014 13:22:48 -0700 (PDT)
Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 100121B2835 for ; Thu, 24 Jul 2014 13:22:47 -0700 (PDT)
Received: by mail-vc0-f181.google.com with SMTP id lf12so5863715vcb.26 for ; Thu, 24 Jul 2014 13:22:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VzvZzsMK3ox0FeWbds2bnwEJaNDREgSBYPtaQ2CF76E=; b=ROpHDcGr1Pabkpun+NbOhp/SOf1IX74yiA9nAs57dTP2BGGTM309n3yu7mInO3XdrB srRFWW1ciSNqtkABy1j1f/A4VwR1TInPkhFLRs5OfTFlLvU0b96fdcie/DCNZunRzy0y DK01KRy3MwNPrb65+ACUZnOjGCvwFH0FCK9ddgbpXpAmm4Lg8U6LVU2gAcyvg67xvh2V XwWjd0Mizv1O9FL+0BaCzRHdZAWn76Q4B/SdVWZjRG43JIjp3COR1CBs5wmf3TISWG/L 5zdgEPzGmHAfnhr/qS4xgzu1/uBve5PJn/hMc0XpXsfRYD8YK1hZ8PHiU1G6xj/RDugW XrLg==
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:content-type; bh=VzvZzsMK3ox0FeWbds2bnwEJaNDREgSBYPtaQ2CF76E=; b=cCK165OW2TS4nIYaUsFifiFC1n8qoX7s2oZjLsIMARSn0ZIO1u0vw/zyduwzCw6KEQ irIlBpz7SKjuaq7nK/2WfE2Mb5WE2ffyC7BuOpM+vrWV3bS0O3LKo8Q1JZKCSiq/U094 Gqa+pdG9ZbvTAUAj7LOL95n6PKXmfk4ScjXdAMP4LAmwuyydt8b9uXqgkakHiCHts+0j NzwM33542NfaTbVckd2wV3kkpak7ZD2DcJnHYlGubM4tQ7nhCAnK40hjPkOhuVrw3jnj 1FwVBPyymJ6LczOL2d8lRz7cXNmCg7yXWALkA/pVQwQRKXWm3cYu73kof78sPOcXSA23 8xEw==
X-Gm-Message-State: ALoCoQn7CZMKDMa6hTtglLhJkYcrkI9KWSraK1oei3/9NK2ELwJiosJRxKTxOd9H72hBQCIEYjnd
X-Received: by 10.52.231.226 with SMTP id tj2mr13665150vdc.16.1406233367224; Thu, 24 Jul 2014 13:22:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.47.238 with HTTP; Thu, 24 Jul 2014 13:22:06 -0700 (PDT)
In-Reply-To: 
References: 
From: Peter Thatcher 
Date: Thu, 24 Jul 2014 16:22:06 -0400
Message-ID: 
To: Justin Uberti 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vwnDJia8C-eP2jcJ1DS97C8WbLA
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Suggestion of text to handle zero-length message issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 20:22:49 -0000

Looks good to me.

On Thu, Jul 24, 2014 at 4:12 PM, Justin Uberti  wrote:
> In http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-11#section-6.6,
> I suggest the following text:
>
>    The SCTP Payload Protocol Identifiers (PPIDs) are used to signal the
>    interpretation of the "Payload data", indicating whether it contains a
>    string or binary data. Also, because SCTP does not permit
>    zero-length messages, they must be handled specially.
>
>    For normal messages, of nonzero length, the PPID "WebRTC String"
>    MUST be used to indicate a JavaScript string encoded in UTF-8, and the
>    PPID "WebRTC Binary" MUST be used to indicate JavaScript binary data
>    (ArrayBuffer or Blob).
>
>    For zero-length messages, the PPID "WebRTC String Empty" MUST
>    be used to indicate an empty Javascript string, and the PPID
>    "WebRTC Binary Empty" MUST be used to indicate zero-length binary data.
>    In either case, a payload consisting of a single (dummy) zero byte MUST
>    be supplied to the SCTP layer on the sending side, and regardless of
>    any received payload, these messages must be interpreted as
>    empty strings or zero-length binary data, as appropriate, on the
> receiving side.
>
>    See Section 8 for details on the exact PPID values.
>
> And in Section 8:
>
>         WebRTC String Empty                      55
>         WebRTC Binary Empty                     56
>
>
>
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>


From nobody Thu Jul 24 13:25:45 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F061ABB35 for ; Thu, 24 Jul 2014 13:25:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXSA1-_4cSqE for ; Thu, 24 Jul 2014 13:25:39 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C91F1B285F for ; Thu, 24 Jul 2014 13:25:39 -0700 (PDT)
Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s6OKPbb8001116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Jul 2014 15:25:37 -0500 (CDT)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s6OKPbpW023667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jul 2014 16:25:37 -0400
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Thu, 24 Jul 2014 16:25:37 -0400
From: "Makaraju, Maridi Raju (Raju)" 
To: Justin Uberti 
Thread-Topic: [rtcweb] Sending of zero-length messages over data channels
Thread-Index: AQHPpipfEWtPO6jXOES6Y6R7CwNaxJutiTxggAI5gwD//74D0IAATLYA///AneCAAFNggP//xY3g
Date: Thu, 24 Jul 2014 20:25:37 +0000
Message-ID: 
References:       
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.18]
Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E4C61A5US70UWXCHMBA02z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QdH96ZMhL4FuTgzlqVZ-ovbxBrU
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Sending of zero-length messages over data channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 20:25:43 -0000

--_000_E1FE4C082A89A246A11D7F32A95A17828E4C61A5US70UWXCHMBA02z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SW4gY29uY2x1c2lvbiwgSSB0aGluayB3ZWJzb2NrZXQgQVBJIHN1cHBvcnRzIHplcm8gbGVuZ3Ro
IGJlY2F1c2Ugd2Vic29ja2V0IHByb3RvY29sIHN1cHBvcnRzIHplcm8tbGVuZ3RoIGRhdGEgZnJh
bWVzLiBTbywgaXQgZG9lcyBub3QgaGF2ZSB0aGUgaXNzdWUgb2Yg4oCYYnVmZmVyZWRBbW91bnTi
gJkgZGlzY3JlcGFuY3kuDQoNCg0KWWVzLCB0aGF0IGlzIHdoYXQgSSBtZWFudC4NCjxSYWp1Pg0K
T2ssIGdvb2QuIFdlYnNvY2tldCBpcyBub3Qgc2VuZGluZyBhbnkgZHVtbXkgYnl0ZXMsIHNvIGJ1
ZmZlcmVkQW1vdW50IGlzIGFsd2F5cyBhY2N1cmF0ZS4NCkkgYW0gc3RpbGwgbm90IGNvbnZpbmNl
ZCB0aGF0IHRvIGtlZXAgZGF0YSBjaGFubmVsIEFQSSBjb25zaXN0ZW50IHdpdGggd2Vic29ja2V0
IEFQSSB3ZSBuZWVkIHRvIGludHJvZHVjZSBvZiBkdW1teSBieXRlIT8NCkhvdyBhYm91dCBrZWVw
aW5nIGNvbnNpc3RlbmN5IG9mIHdoYXQgZ29lcyBvbiB3aXJlIHZzLiB3aGF0IHVzZXIgc2VudD8g
d2Vic29ja2V0IHByZXNlcnZlcyB0aGF0LCB3aGVyZSBhcyBkYXRhIGNoYW5uZWwgd29u4oCZdC4N
CklNSE8gb3Bpbmlvbiwgc2VuZGluZyBzdWNoIGEgZHVtbXkgYnl0ZSBtYXkgaGF2ZSBvdGhlciBj
b25zZXF1ZW5jZXM6DQoNCjEuICAgICAgIEFwcCBpcyBub3QgYXdhcmUgb2Ygd2hhdOKAmXMgZ29p
bmcgb24/IHNlbmQoKSBwcm9iYWJseSBtZWFudCB0byBiZSBjYWxsZWQgd2l0aCBub24tZW1wdHkg
ZGF0YSwgYnV0IHNvbWUgZXJyb3IgbGVnIGNvdWxkIGhhdmUgY2F1c2VkIGl0IGJlY29tZSBlbXB0
eSwgYnV0IHN0aWxsIGEgYnl0ZSB3aWxsIGJlIHNlbnQgb3V0ISENCg0KMi4gICAgICAgRGVidWdn
aW5nIGJlY29tZXMgYml0IG1vcmUgY29tcGxleCBhbmQgbm90IGludHVpdGl2ZS4gV2ViUlRDIGlz
IGFscmVhZHkgY29tcGxleCwgd2h5IGFkZCBtb3JlIGNvbXBsZXhpdHk/DQoNCjMuICAgICAgIElu
dGVyb3AgaXNzdWVzLiBUaGUgbW9yZSB0aGUgZXhjZXB0aW9ucyB0aGUgbW9yZSB0aGUgaW50ZXJv
cCBpc3N1ZXMgeW91IHNlZSBhcyBzb21lIGltcGxlbWVudGF0aW9ucyBtYXkgb3Zlcmxvb2sgdGhl
c2Ugb3IgaW1wbGVtZW50IHRoZW0gbGF0ZXIuDQoNCkl04oCZcyB1c3VhbGx5IGEgYmFkIGlkZWEg
dG8gc2VuZCBhIGR1bW15IGJ5dGUgb24gd2lyZSwgd2l0aG91dCB0aGUgYXBwbGljYXRpb24gZGly
ZWN0IGludm9sdmVtZW50Lg0KSU1ITywgaWYgZG9pbmcgUFBJRF9PT0IgaXMgbW9yZSBlZmZvcnQg
YW5kIGNhbuKAmXQgZml0IGluIHdlYnJ0YyAxLjAgdGhlbiBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8g
ZGVsYXkgYW5kIGRvIGl0IGluIG1vcmUgcHJvcGVyIHdheSB0aGFuIHRha2luZyBhIHNob3J0Y3V0
IHdpdGggUFBJRF9FTVBUWS4gV2l0aCBQUElEX09PQiBhcHByb2FjaCB1bmRlcmx5aW5nIHNpZ25h
bGluZyBwcm90b2NvbCBjYW4gbmVnb3RpYXRlIE9PQiBiZWZvcmUgdXNpbmcgaXQ7IHRob3VnaCBz
dWNoIG5lZ290aWF0aW9uIGlzIG5vdCBtYW5kYXRvcnksIGJ1dCB0aGlzIGFwcHJvYWNoIGFsbG93
cyBzdWNoIHBvc3NpYmlsaXR5Lg0KDQpJIHRoZW4sIHJlc3QgbXkgY2FzZSEg4pi6DQoNCjwvUmFq
dT4NCg==

--_000_E1FE4C082A89A246A11D7F32A95A17828E4C61A5US70UWXCHMBA02z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N
CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5N
c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw
aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJp
Z2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdp
bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l
cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5
cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN
Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y
dC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn
aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv
cmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlz
dC1pZDoxNzY2NDE0NTE4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBs
YXRlLWlkczotMTU2NDg0OTA5MiA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2
NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDps
ZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBp
bjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z
byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg
Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs
YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8
L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF
Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv
bjEiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw
dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx
LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj5JbiBjb25jbHVzaW9uLCBJIHRoaW5rIHdlYnNvY2tldCBBUEkg
c3VwcG9ydHMgemVybyBsZW5ndGggYmVjYXVzZSB3ZWJzb2NrZXQgcHJvdG9jb2wgc3VwcG9ydHMN
CiB6ZXJvLWxlbmd0aCBkYXRhIGZyYW1lcy4gU28sIGl0IGRvZXMgbm90IGhhdmUgdGhlIGlzc3Vl
IG9mIOKAmGJ1ZmZlcmVkQW1vdW504oCZIGRpc2NyZXBhbmN5Lg0KPC9zcGFuPjwvaT48L2I+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9pPjwvYj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCB0aGF0IGlzIHdoYXQg
SSBtZWFudC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxp
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7UmFqdSZndDs8
bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxp
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PaywgZ29vZC4gV2Vi
c29ja2V0IGlzIG5vdCBzZW5kaW5nIGFueSBkdW1teSBieXRlcywgc28NCjwvc3Bhbj48L2k+PC9i
PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5idWZmZXJl
ZEFtb3VudCBpcyBhbHdheXMgYWNjdXJhdGUuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+SSBhbSBzdGlsbCBub3QgY29udmluY2VkIHRoYXQgdG8ga2VlcCBkYXRh
IGNoYW5uZWwgQVBJIGNvbnNpc3RlbnQgd2l0aCB3ZWJzb2NrZXQgQVBJIHdlIG5lZWQgdG8gaW50
cm9kdWNlIG9mIGR1bW15IGJ5dGUhPzxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPkhvdyBhYm91dCBrZWVwaW5nIGNvbnNpc3RlbmN5IG9mIHdoYXQgZ29lcyBvbiB3
aXJlIHZzLiB3aGF0IHVzZXIgc2VudD8gd2Vic29ja2V0IHByZXNlcnZlcyB0aGF0LCB3aGVyZSBh
cyBkYXRhIGNoYW5uZWwgd29u4oCZdC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPklNSE8gb3Bpbmlvbiwgc2VuZGluZyBzdWNoIGEgZHVtbXkgYnl0ZSBtYXkg
aGF2ZSBvdGhlciBjb25zZXF1ZW5jZXM6PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8
cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28t
bGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PGI+PGk+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ
Z25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1
b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+
PC9zcGFuPjwvaT48L2I+PCFbZW5kaWZdPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj5BcHAgaXMgbm90IGF3YXJlIG9mIHdoYXTigJlzIGdvaW5nIG9uPyBz
ZW5kKCkgcHJvYmFibHkgbWVhbnQgdG8gYmUgY2FsbGVkIHdpdGggbm9uLWVtcHR5IGRhdGEsIGJ1
dCBzb21lIGVycm9yIGxlZyBjb3VsZCBoYXZlIGNhdXNlZCBpdA0KIGJlY29tZSBlbXB0eSwgYnV0
IHN0aWxsIGEgYnl0ZSB3aWxsIGJlIHNlbnQgb3V0ISE8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9i
PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4y
NWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48Yj48aT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1z
by1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg
Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu
Pjwvc3Bhbj48L3NwYW4+PC9pPjwvYj48IVtlbmRpZl0+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRlYnVnZ2luZyBiZWNvbWVzIGJpdCBtb3JlIGNvbXBs
ZXggYW5kIG5vdCBpbnR1aXRpdmUuIFdlYlJUQyBpcyBhbHJlYWR5IGNvbXBsZXgsIHdoeSBhZGQg
bW9yZSBjb21wbGV4aXR5PzxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9
Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAg
bGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4z
LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48
L2k+PC9iPjwhW2VuZGlmXT48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+SW50ZXJvcCBpc3N1ZXMuIFRoZSBtb3JlIHRoZSBleGNlcHRpb25zIHRoZSBtb3Jl
IHRoZSBpbnRlcm9wIGlzc3VlcyB5b3Ugc2VlIGFzIHNvbWUgaW1wbGVtZW50YXRpb25zIG1heSBv
dmVybG9vayB0aGVzZSBvciBpbXBsZW1lbnQNCiB0aGVtIGxhdGVyLjxvOnA+PC9vOnA+PC9zcGFu
PjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48
L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkl04oCZcyB1c3VhbGx5IGEgYmFkIGlkZWEgdG8gc2VuZCBh
IGR1bW15IGJ5dGUgb24gd2lyZSwgd2l0aG91dCB0aGUgYXBwbGljYXRpb24gZGlyZWN0IGludm9s
dmVtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklNSE8s
IGlmIGRvaW5nIFBQSURfT09CIGlzIG1vcmUgZWZmb3J0IGFuZCBjYW7igJl0IGZpdCBpbiB3ZWJy
dGMgMS4wIHRoZW4gaXQgd291bGQgYmUgYmV0dGVyIHRvIGRlbGF5IGFuZCBkbyBpdCBpbiBtb3Jl
IHByb3BlciB3YXkgdGhhbiB0YWtpbmcgYSBzaG9ydGN1dA0KIHdpdGggUFBJRF9FTVBUWS4gV2l0
aCBQUElEX09PQiBhcHByb2FjaCB1bmRlcmx5aW5nIHNpZ25hbGluZyBwcm90b2NvbCBjYW4gbmVn
b3RpYXRlIE9PQiBiZWZvcmUgdXNpbmcgaXQ7IHRob3VnaCBzdWNoIG5lZ290aWF0aW9uIGlzIG5v
dCBtYW5kYXRvcnksIGJ1dCB0aGlzIGFwcHJvYWNoIGFsbG93cyBzdWNoIHBvc3NpYmlsaXR5Ljxv
OnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhlbiwgcmVzdCBteSBjYXNl
IQ0KPC9zcGFuPjwvaT48L2I+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPko8L3NwYW4+PC9pPjwvYj48Yj48aT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3Nw
YW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9p
PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmx0Oy9SYWp1Jmd0Ozwvc3Bhbj48L2k+PC9iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv
ZHk+DQo8L2h0bWw+DQo=

--_000_E1FE4C082A89A246A11D7F32A95A17828E4C61A5US70UWXCHMBA02z_--


From nobody Thu Jul 24 14:02:57 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716A41A0A9D for ; Thu, 24 Jul 2014 14:02:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 WejI_VZGbBlg for ; Thu, 24 Jul 2014 14:02:48 -0700 (PDT)
Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A69BD1A0880 for ; Thu, 24 Jul 2014 14:02:48 -0700 (PDT)
Received: by mail-vc0-f174.google.com with SMTP id la4so5941443vcb.33 for ; Thu, 24 Jul 2014 14:02:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2alixEgZlYBS10iGG3JUI0o1kNZUi1Q1N2ooU0r6iV8=; b=oCZuGE9FJmg9KQ5ntJodyGL8Lpx683OmiIFOzll6dIvD4QOGJ6mCg3lDdg2FoO/6VJ I+pZdi/fVNEEZN3OAg04qzEDm/rBZkOI0naRCHVyHI97u++cgCwNqgmKvOmoof3K5/iJ iRjCtIpOIzyDO5NriccvhGVP5JJaMjQ7OJbts+tR7Q3BRjjIkWwBuX1R36QzLWaY6+Rn OPkv4/TjcsqfQFxmYvHb9jfcgI7+omiHA3fLFBElJ6zlQpffof5VHMbhUZ2RcEnvx8LA wm6DvwkGPScp7rBXAixeZ9NqsMi4gU8jaRrnpVA8kAXNKhn1mH13pLacFhs/udvXJ+UO JK9A==
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:content-type; bh=2alixEgZlYBS10iGG3JUI0o1kNZUi1Q1N2ooU0r6iV8=; b=JZdR87K2+EawflmizJJqfd38805SkCCOnZfm7AlOUTK/aesOjlEBZzCO4+Zu3QWZk2 1fMU49U7H80iBV/xVKBbbMZDsKIVIuG+SK6ySw6I5dsYRlmKX52xaYuft4xg8Lkj6YH/ MS5e/lChEjAUMvYlsOdpV62PiFFUNuEbkvrLXd4SyCgSpSEcinitCNoRLrB11evS0VnR BoFnoVHBWP86GhsqLBY55ZpJ8csALX9810HkHC5Eg6WUTL6sbrgCUGcOR+zjGVSydzoH KqmPVWxwnZnFVukmPyQ4ZZkAnnb+DTDqM++mEZbagWqpdMzEkEsz33IAKPFORR2j6LE8 99Zg==
X-Gm-Message-State: ALoCoQkXffpgz5rtkbiqjtTd9PSOweEtamKFem0t64D6C5zz8FK2jzJBzZlhKs0Ksd5kahFaErvW
X-Received: by 10.52.66.227 with SMTP id i3mr13418077vdt.48.1406235767539; Thu, 24 Jul 2014 14:02:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.4.70 with HTTP; Thu, 24 Jul 2014 14:02:27 -0700 (PDT)
In-Reply-To: 
References: <2184C33E-F1E0-4B31-BC59-6AA11260E1EF@ieca.com> 
From: Justin Uberti 
Date: Thu, 24 Jul 2014 17:02:27 -0400
Message-ID: 
To: Bernard Aboba 
Content-Type: multipart/alternative; boundary=20cf307d021e66213a04fef6c7d9
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bJRkBT5P7dheQerddrMDX-qU5wQ
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-audio-codecs-for-interop
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 21:02:50 -0000

--20cf307d021e66213a04fef6c7d9
Content-Type: text/plain; charset=UTF-8

I agree that it is currently impractical to support AMR/AMR-WB in browsers,
and therefore a document that recommends support of these codecs without
addressing the associated issues is not suitable for adoption.

I have no issues with the recommendation of G.722.


On Thu, Jul 24, 2014 at 4:18 PM, Bernard Aboba 
wrote:

> I do not support adoption of the draft in its current form, for the
> following reasons:
>
> a. The draft only currently covers AMR-WB, AMR and G.722.  Since the AMR
> codecs generally are accessible only through a proprietary "blackbox" API
> that does not permit WebRTC use without a separate license, these codecs
> are not currently practical to support in browsers, even in operating
> systems that support AMR-WB/AMR for other uses.
>
> b. The remaining codec (G.722) does not have these issues, and so it could
> be implemented in browsers.  However, the useful text in this portion of
> the document is so small that it does not justify creation of yet another
> document, even a separate one.
>
>
> On Thu, Jul 24, 2014 at 3:50 PM, Sean Turner  wrote:
>
>> At the RTCWEB session on Thursday there was support for adoption of
>> draft-proust-rtcweb-audio-codecs-for-interop as an informational WG draft.
>>  If you do not support adoption of this draft as a WG draft please respond
>> to this email by August 1st.  Please also indicate why you do not support
>> WG adoption.
>>
>> spt
>> _______________________________________________
>> 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
>
>

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


I agree that it is currently impractical to support AMR/AM=
R-WB in browsers, and therefore a document that recommends support of these=
 codecs without addressing the associated issues is not suitable for adopti=
on.



I have no issues with the recommendation of G.722.


On Thu, Jul=
 24, 2014 at 4:18 PM, Bernard Aboba <bernard.aboba@gmail.com>=
 wrote:



I do not support adoption o=
f the draft in its current form, for the following reasons:=C2=A0

<=
/div>


a. The draft only currently covers AMR-WB, AMR and G.722. =C2=A0Since the A=
MR codecs generally are accessible only through a proprietary "blackbo=
x" API that does not permit WebRTC use without a separate license, the=
se codecs are not currently practical to support in browsers, even in opera=
ting systems that support AMR-WB/AMR for other uses.






b. The remaining codec (G.722) does not have these issu=
es, and so it could be implemented in browsers. =C2=A0However, the useful t=
ext in this portion of the document is so small that it does not justify cr=
eation of yet another document, even a separate one.=C2=A0






On Thu, Jul 24, 2014 at 3:50 PM, Sean Turn=
er <TurnerS@ieca.com> wrote:





At the RTCWEB session on Thursday there was =
support for adoption of draft-proust-rtcweb-audio-codecs-for-interop as an =
informational WG draft. =C2=A0If you do not support adoption of this draft =
as a WG draft please respond to this email by August 1st. =C2=A0Please also=
 indicate why you do not support WG adoption.







spt

_______________________________________________

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





--20cf307d021e66213a04fef6c7d9--


From nobody Thu Jul 24 14:10:41 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91391ABB32 for ; Thu, 24 Jul 2014 14:10:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDXpwShxEf59 for ; Thu, 24 Jul 2014 14:10:38 -0700 (PDT)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61D611A0AD3 for ; Thu, 24 Jul 2014 14:10:38 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id z12so3320062wgg.0 for ; Thu, 24 Jul 2014 14:10:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=A/vCXDFR3flR9NwxnOYdfqK0hHsT4GO/5Z2FH/SDYas=; b=fg7EGpxuy023zsSCQJ+39fpPFI5DdfpgamVN7TJm61WVu1g00EIMaHguEGidy+NozK llI0M0T4/JXBdctk99uDDd9HcTBLWbYQMCawdmxH3I2zH/P3USnSmjiGdhGR6LzTZbXL 4pK+bMzA0cVUXDHNpDS/ulHwhLwr8Ln79u21svZfmk/c/trxUC3JrRxhGoM24iJXpwoR 5U636lsxm0u8HjSkenlCuFgPheG0emg/Ha66UpA0bGGaIa8duKZc5My9qyIrkTRse6ow LO4HcCKCM3RCHINRp+Rz08fdARmFXu9StoJNOtGPvHx8BmdLSOKam+Z+i6f/fut11COf +u/g==
MIME-Version: 1.0
X-Received: by 10.194.185.238 with SMTP id ff14mr16205347wjc.9.1406236236879;  Thu, 24 Jul 2014 14:10:36 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Thu, 24 Jul 2014 14:10:36 -0700 (PDT)
In-Reply-To: <2184C33E-F1E0-4B31-BC59-6AA11260E1EF@ieca.com>
References: <2184C33E-F1E0-4B31-BC59-6AA11260E1EF@ieca.com>
Date: Thu, 24 Jul 2014 14:10:36 -0700
Message-ID: 
From: Martin Thomson 
To: Sean Turner 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QMsBCo-VM2sKTqtu51yf_PGiedk
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-audio-codecs-for-interop
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 21:10:39 -0000

On 24 July 2014 12:50, Sean Turner  wrote:
> At the RTCWEB session on Thursday there was support for adoption of draft=
-proust-rtcweb-audio-codecs-for-interop as an informational WG draft.  If y=
ou do not support adoption of this draft as a WG draft please respond to th=
is email by August 1st.  Please also indicate why you do not support WG ado=
ption.

Do we anticipate this draft having a material impact on what
people/implementations do?  Otherwise, I think that I'm against
spending working group time on this.


From nobody Thu Jul 24 14:29:07 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D693C1B288A for ; Thu, 24 Jul 2014 14:29:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exiAqsJ3QY58 for ; Thu, 24 Jul 2014 14:29:02 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 0753B1B2880 for ; Thu, 24 Jul 2014 14:29:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 1F3767C3DB3 for ; Thu, 24 Jul 2014 23:29:01 +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 4cA3PrqnDfGj for ; Thu, 24 Jul 2014 23:29:00 +0200 (CEST)
Received: from [172.19.7.45] (unknown [216.239.45.77]) by mork.alvestrand.no (Postfix) with ESMTPSA id 9CD317C3B86 for ; Thu, 24 Jul 2014 23:28:59 +0200 (CEST)
Message-ID: <53D17A99.8090702@alvestrand.no>
Date: Thu, 24 Jul 2014 14:28:57 -0700
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cQoDvS-ZnhVmxCjbaaWqS7_Ob-w
Subject: [rtcweb] Apologies for confusion: I had published my -05 version
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 21:29:06 -0000

It seems that I did publish the version of -transport that I described
at the meeting as not having published; it is -05.

Sorry for the confusion.

-- 
Surveillance is pervasive. Go Dark.


From nobody Thu Jul 24 18:16:46 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB131A0944 for ; Thu, 24 Jul 2014 18:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 Fpg4CQdJ8qRl for ; Thu, 24 Jul 2014 18:16:37 -0700 (PDT)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7021A0417 for ; Thu, 24 Jul 2014 18:16:37 -0700 (PDT)
Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta08.westchester.pa.mail.comcast.net with comcast id WQsT1o0051uE5Es58RGdBZ; Fri, 25 Jul 2014 01:16:37 +0000
Received: from dhcp-90b7.meeting.ietf.org ([31.133.144.183]) by omta16.westchester.pa.mail.comcast.net with comcast id WRES1o00U3xdsjB3cREUpW; Fri, 25 Jul 2014 01:14:35 +0000
Message-ID: <53D1AF71.2070003@alum.mit.edu>
Date: Thu, 24 Jul 2014 21:14:25 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Justin Uberti 
References:   <53CEFA2C.8040407@nteczone.com> <53CFA92F.5070306@alum.mit.edu>  <53D0880B.70401@alum.mit.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1406250997; bh=ZOzt09krCXF1Biufg2nYIl89HhIGq+021uWXQVHhvNA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=S9bIf8mNVvCFW0KI686DuHMARDdjhj+K0laHi03v9x/DWEsNh//vAEdJ25dmjhe9H sRVe7k1i7sORFf6wpRsWxaIfDgs6GC9sQfdZGKG+nRsa5kdOuBjihYWY8BRrMmv7kW n37uM+HW6MsDuPkvxJPnVRjIS3KYoVD5BXsAb14EptrFinjV6ipsVDqREAJRFt50EN uVQLdebW7fy5U5l50+OjqjbqFpIxHl83/aReAUqJRt9/NKAfjbZMYhGjL0t8pOLl5f wkZgg4uap0aQffAa1jagO+Zot3ptQRRIqdN0RN42MFOHSFP64vvWsWvDhe/ddc/uEg KbLnhJaOu3f2A==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/C-xb6PMTpvFzLOq6gLXlmpzSanQ
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 01:16:38 -0000

On 7/24/14 1:35 PM, Justin Uberti wrote:

>     The fundamental problem with this is that AFAICT it makes it
>     impossible to build a WebRTC client that can interop with a CLUE
>     server. I guess it would be possible with a special purpose media
>     gateway that demuxed the clue media from sendrecv m-lines to
>     sendonly & recvonly m-lines.
>
>     As another clue person said today, CLUE chose to use sendonly and
>     recvonly m-lines so we could use the sendonly ones to provide SDP
>     descriptions of what is available to be *sent*. (With sendrecv
>     m-lines this describes only what is desired to be received.) Clue
>     use cases are likely to be highly asymmetric, so it is essential to
>     be able to do this.
>
>     Clue does have a solution for the simple phone, but it probably
>     isn't a solution that would be satisfactory to rtcweb. The first O/A
>     on a CLUE session assumes it doesn't know what it might be
>     connecting to, and so makes an offer that is likely to work with
>     "legacy" devices. Generally this would be one sendrecv audio and one
>     sendrecv video, though YMMV. There are a few other things in there
>     that allow the two ends to discover if they both can do clue after
>     the first O/A.
>
>     If both do clue, then there is another O/A that provides sendonly
>     m-lines for the offerer. And there will be a 3rd that provides
>     sendonly m-lines by the other end. We consider this tolerable for
>     telepresence.
>
>     The first O/A will also include DTLS/SCTP m-line that is intended to
>     carry the CLUE data channel. (Assumed to be rejected by a "legacy"
>     device.) While we don't require it, bundling is very attractive for
>     clue. So if ICE has succeeded for that m-line, the subsequent O/As
>     can add all those sendonly m-lines in the same bundle, so no new ice
>     will be required.
>
> I think this would work fine with the new APIs being provided.

Which new APIs? Do they work with the m-line management rules in 
jsep-07? Do you mean just the ones that allow OfferToReceive with a number?

> In the initial offer, sendrecv audio, video, and data m= line will be
> offered, with the option to bundle.
> In the second offer, the OfferToReceiveVideo:X option can be used to
> create sendonly m= lines from the offerer.

Doesn't OfferToReceive generate *recvonly* m-lines. (It hardly makes 
sense for it to create *sendonly* lines.)

> In the third offer, the OfferToReceiveVideo:Y option can be used to
> create sendonly m= lines from the answerer.
>
> Did I overlook something?

I think so, or else I'm missing something.

	Thanks,
	Paul


From nobody Thu Jul 24 19:35:26 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8541A0AD5 for ; Thu, 24 Jul 2014 19:35:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 9vNsWkiezxU6 for ; Thu, 24 Jul 2014 19:35:22 -0700 (PDT)
Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C73C51A0AD3 for ; Thu, 24 Jul 2014 19:35:21 -0700 (PDT)
Received: by mail-vc0-f181.google.com with SMTP id lf12so6240668vcb.40 for ; Thu, 24 Jul 2014 19:35:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XJf+kkV4WLBZzz4AixfBbeEnnDpp785T7llPHPUZoU8=; b=LdVoO01YOSsHRIeepTI+JRE0sfauxv8/emDvzMJDzgEYZ+IgxgjmZEcU6Gg9PDWGfc fI6TFMra0i55nfMBY9f1Cnxos4jc2xH0o+5EVYENjVu0mUM25WxijN6AidhOP6/RI/So TyWdesWIrDafXWdj81axL4TPD3CwHjbvfr0JGCCJ6gdyUoomrCdh/D/PZlSesHiahViC 86pN36SChihh0KGe6Kf2gK6Feu7+ty4e9iMJREVZITQ13agqfwTbOXgNhC2M0gRk/bi/ ekm/r9dmHSPwXCdNynISPt+BlVERtXJBd3LRr9BiVvvN+aAWqUIgf3fVkEd9LGtCU4zn wDUg==
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:content-type; bh=XJf+kkV4WLBZzz4AixfBbeEnnDpp785T7llPHPUZoU8=; b=lJNO/LrVFFj/Pe7bC16OOlQRa+4BA7aLzlT0DmK0Dgec4ATA0UEMmLe+3MmpfC6Paf eWJvL9LNyBE62VdLQojdxKp0K4m2tBGVO2C6pZSUz7oB77BkOclfl0NWyCCPdCXUg7Ty TPi/LDBVJj5hxLTuydnxAMQdBxJ9DIIp6eg3xnzumS/7dOD2nc5dumZ0e3IP2eEpIqjM Y1nHnj8IWV7FbLcOMVeRiw6WSLz/iTWWNgFvercYhtGPtO6ZwC0+7qECnHKYHvocsl86 uPqLxN/UMj8+YcXPebZDJJV+lVYDO42DoXVtXPgPops4XvykW+OqQD3H8Qj27i3zxof6 oPGg==
X-Gm-Message-State: ALoCoQl05t2/rrfFTnHAk6hrsvnl8hmAsG29NTkcMhOY6p9Cus7UQ1fqquKCEqci5fhVnBPKfVOr
X-Received: by 10.52.38.105 with SMTP id f9mr14689743vdk.17.1406255720978; Thu, 24 Jul 2014 19:35:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.4.70 with HTTP; Thu, 24 Jul 2014 19:35:00 -0700 (PDT)
In-Reply-To: <53D1AF71.2070003@alum.mit.edu>
References:   <53CEFA2C.8040407@nteczone.com> <53CFA92F.5070306@alum.mit.edu>  <53D0880B.70401@alum.mit.edu>  <53D1AF71.2070003@alum.mit.edu>
From: Justin Uberti 
Date: Thu, 24 Jul 2014 22:35:00 -0400
Message-ID: 
To: Paul Kyzivat 
Content-Type: multipart/alternative; boundary=bcaec51ddbb9b67f9304fefb6c19
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/It_4TIC_Z08X1G_2L3L1w6G83sY
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 02:35:24 -0000

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

On Thu, Jul 24, 2014 at 9:14 PM, Paul Kyzivat  wrote:

> On 7/24/14 1:35 PM, Justin Uberti wrote:
>
>      The fundamental problem with this is that AFAICT it makes it
>>     impossible to build a WebRTC client that can interop with a CLUE
>>     server. I guess it would be possible with a special purpose media
>>     gateway that demuxed the clue media from sendrecv m-lines to
>>     sendonly & recvonly m-lines.
>>
>>     As another clue person said today, CLUE chose to use sendonly and
>>     recvonly m-lines so we could use the sendonly ones to provide SDP
>>     descriptions of what is available to be *sent*. (With sendrecv
>>     m-lines this describes only what is desired to be received.) Clue
>>     use cases are likely to be highly asymmetric, so it is essential to
>>     be able to do this.
>>
>>     Clue does have a solution for the simple phone, but it probably
>>     isn't a solution that would be satisfactory to rtcweb. The first O/A
>>     on a CLUE session assumes it doesn't know what it might be
>>     connecting to, and so makes an offer that is likely to work with
>>     "legacy" devices. Generally this would be one sendrecv audio and one
>>     sendrecv video, though YMMV. There are a few other things in there
>>     that allow the two ends to discover if they both can do clue after
>>     the first O/A.
>>
>>     If both do clue, then there is another O/A that provides sendonly
>>     m-lines for the offerer. And there will be a 3rd that provides
>>     sendonly m-lines by the other end. We consider this tolerable for
>>     telepresence.
>>
>>     The first O/A will also include DTLS/SCTP m-line that is intended to
>>     carry the CLUE data channel. (Assumed to be rejected by a "legacy"
>>     device.) While we don't require it, bundling is very attractive for
>>     clue. So if ICE has succeeded for that m-line, the subsequent O/As
>>     can add all those sendonly m-lines in the same bundle, so no new ice
>>     will be required.
>>
>> I think this would work fine with the new APIs being provided.
>>
>
> Which new APIs? Do they work with the m-line management rules in jsep-07?
> Do you mean just the ones that allow OfferToReceive with a number?


Yes, the OfferToReceiveX APIs.

>
>
>  In the initial offer, sendrecv audio, video, and data m= line will be
>> offered, with the option to bundle.
>> In the second offer, the OfferToReceiveVideo:X option can be used to
>> create sendonly m= lines from the offerer.
>>
>
> Doesn't OfferToReceive generate *recvonly* m-lines. (It hardly makes sense
> for it to create *sendonly* lines.)


It can do either, as Eric pointed out in the presentation on Wednesday. If
you specify a number to receive that is less than the expected number of
m-lines, then the remainder will be marked as sendonly.

>
>
>  In the third offer, the OfferToReceiveVideo:Y option can be used to
>> create sendonly m= lines from the answerer.
>>
>> Did I overlook something?
>>
>
> I think so, or else I'm missing something.
>
>         Thanks,
>         Paul
>

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





On Thu, Jul 24, 2014 at 9:14 PM, Paul Kyzivat <=
;pkyzivat@alum.m=
it.edu> wrote:



On 7=
/24/14 1:35 PM, Justin Uberti wrote:





=C2=A0 =C2=A0 The fundamental problem with this is that AFAICT it makes it<=
br>
=C2=A0 =C2=A0 impossible to build a WebRTC client that can interop with a C=
LUE

=C2=A0 =C2=A0 server. I guess it would be possible with a special purpose m=
edia

=C2=A0 =C2=A0 gateway that demuxed the clue media from sendrecv m-lines to<=
br>
=C2=A0 =C2=A0 sendonly & recvonly m-lines.



=C2=A0 =C2=A0 As another clue person said today, CLUE chose to use sendonly=
 and

=C2=A0 =C2=A0 recvonly m-lines so we could use the sendonly ones to provide=
 SDP

=C2=A0 =C2=A0 descriptions of what is available to be *sent*. (With sendrec=
v

=C2=A0 =C2=A0 m-lines this describes only what is desired to be received.) =
Clue

=C2=A0 =C2=A0 use cases are likely to be highly asymmetric, so it is essent=
ial to

=C2=A0 =C2=A0 be able to do this.



=C2=A0 =C2=A0 Clue does have a solution for the simple phone, but it probab=
ly

=C2=A0 =C2=A0 isn't a solution that would be satisfactory to rtcweb. Th=
e first O/A

=C2=A0 =C2=A0 on a CLUE session assumes it doesn't know what it might b=
e

=C2=A0 =C2=A0 connecting to, and so makes an offer that is likely to work w=
ith

=C2=A0 =C2=A0 "legacy" devices. Generally this would be one sendr=
ecv audio and one

=C2=A0 =C2=A0 sendrecv video, though YMMV. There are a few other things in =
there

=C2=A0 =C2=A0 that allow the two ends to discover if they both can do clue =
after

=C2=A0 =C2=A0 the first O/A.



=C2=A0 =C2=A0 If both do clue, then there is another O/A that provides send=
only

=C2=A0 =C2=A0 m-lines for the offerer. And there will be a 3rd that provide=
s

=C2=A0 =C2=A0 sendonly m-lines by the other end. We consider this tolerable=
 for

=C2=A0 =C2=A0 telepresence.



=C2=A0 =C2=A0 The first O/A will also include DTLS/SCTP m-line that is inte=
nded to

=C2=A0 =C2=A0 carry the CLUE data channel. (Assumed to be rejected by a &qu=
ot;legacy"

=C2=A0 =C2=A0 device.) While we don't require it, bundling is very attr=
active for

=C2=A0 =C2=A0 clue. So if ICE has succeeded for that m-line, the subsequent=
 O/As

=C2=A0 =C2=A0 can add all those sendonly m-lines in the same bundle, so no =
new ice

=C2=A0 =C2=A0 will be required.



I think this would work fine with the new APIs being provided.





Which new APIs? Do they work with the m-line management rules in jsep-07? D=
o you mean just the ones that allow OfferToReceive with a number?

Yes, the OfferToReceiveX APIs.=C2=A0









In the initial offer, sendrecv audio, video, and data m=3D line will be

offered, with the option to bundle.

In the second offer, the OfferToReceiveVideo:X option can be used to

create sendonly m=3D lines from the offerer.





Doesn't OfferToReceive generate *recvonly* m-lines. (It hardly makes se=
nse for it to create *sendonly* lines.)

It =
can do either, as Eric pointed out in the presentation on Wednesday. If you=
 specify a number to receive that is less than the expected number of m-lin=
es, then the remainder will be marked as sendonly.=C2=A0









In the third offer, the OfferToReceiveVideo:Y option can be used to

create sendonly m=3D lines from the answerer.



Did I overlook something?





I think so, or else I'm missing something.



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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul





--bcaec51ddbb9b67f9304fefb6c19--


From nobody Thu Jul 24 20:14:01 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F5D1A040D for ; Thu, 24 Jul 2014 20:13:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pllT3C7cQjSV for ; Thu, 24 Jul 2014 20:13:56 -0700 (PDT)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id B02AD1A026C for ; Thu, 24 Jul 2014 20:13:56 -0700 (PDT)
Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs210cnc.rim.net with ESMTP/TLS/AES128-SHA; 24 Jul 2014 23:13:53 -0400
Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT101CNC.rim.net ([fe80::9c22:d9c:c906:c488%16]) with mapi id 14.03.0174.001; Thu, 24 Jul 2014 23:13:52 -0400
From: Andrew Allen 
To: "martin.thomson@gmail.com" , "TurnerS@ieca.com" 
Thread-Topic: [rtcweb] call for adoption: draft-draft-proust-rtcweb-audio-codecs-for-interop
Thread-Index: AQHPp4O7RRt3DNdZ4E2+IDpgyWaWGpuwHeQ5
Date: Fri, 25 Jul 2014 03:13:52 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.160.251]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5XZKmX30ST6mBcCl9YjSMjdLIoc
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-audio-codecs-for-interop
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 03:13:59 -0000

I am with Martin on this.

Have it as an individual draft and AD sponsored. Its basically as I underst=
and it an informational summary of the reality in existing deployments. So =
this isn't reallly the work of the RTCweb WG - in fact is relevant (for as =
long as its information is up to date) also for work in RAI groups other th=
an RTCweb too.

Andrew

----- Original Message -----
From: Martin Thomson [mailto:martin.thomson@gmail.com]
Sent: Thursday, July 24, 2014 05:10 PM Eastern Standard Time=0A=
To: Sean Turner 
Cc: rtcweb@ietf.org 
Subject: Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-audio-co=
decs-for-interop

On 24 July 2014 12:50, Sean Turner  wrote:
> At the RTCWEB session on Thursday there was support for adoption of draft=
-proust-rtcweb-audio-codecs-for-interop as an informational WG draft.  If y=
ou do not support adoption of this draft as a WG draft please respond to th=
is email by August 1st.  Please also indicate why you do not support WG ado=
ption.

Do we anticipate this draft having a material impact on what
people/implementations do?  Otherwise, I think that I'm against
spending working group time on this.

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


From nobody Thu Jul 24 21:21:30 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9CB1A0ADA for ; Thu, 24 Jul 2014 21:21:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.258
X-Spam-Level: 
X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6dvYgtb_ld6 for ; Thu, 24 Jul 2014 21:21:23 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) (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 2CE9F1A0AD6 for ; Thu, 24 Jul 2014 21:21:23 -0700 (PDT)
Received: from [10.0.1.138] (unknown [199.119.128.122]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id E47F6F2024 for ; Thu, 24 Jul 2014 21:21:17 -0700 (PDT)
Message-ID: <53D1DB3C.3070704@mozilla.com>
Date: Thu, 24 Jul 2014 21:21:16 -0700
From: "Timothy B. Terriberry" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
CC: "rtcweb@ietf.org" 
References: <2184C33E-F1E0-4B31-BC59-6AA11260E1EF@ieca.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sw6pGkFLUGQEXXaWmu6Kfu3UXfM
Subject: Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-audio-codecs-for-interop
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 04:21:24 -0000

Bernard Aboba wrote:
> b. The remaining codec (G.722) does not have these issues, and so it
> could be implemented in browsers.  However, the useful text in this
> portion of the document is so small that it does not justify creation of
> yet another document, even a separate one.

+1

I also do not support the adoption of the draft.


From nobody Thu Jul 24 21:54:17 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B981A0AD6 for ; Thu, 24 Jul 2014 21:54:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.279
X-Spam-Level: 
X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IinSRHkDQz81 for ; Thu, 24 Jul 2014 21:54:13 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (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 E56CE1A0ABF for ; Thu, 24 Jul 2014 21:54:13 -0700 (PDT)
Received: from panoramix.jmvalin.ca (modemcable167.97-201-24.mc.videotron.ca [24.201.97.167]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 3570AF224D; Thu, 24 Jul 2014 21:54:12 -0700 (PDT)
Message-ID: <53D1E2F2.5060803@mozilla.com>
Date: Fri, 25 Jul 2014 00:54:10 -0400
From: Jean-Marc Valin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Bernard Aboba ,  Sean Turner 
References: <2184C33E-F1E0-4B31-BC59-6AA11260E1EF@ieca.com> 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wIRTRGc90badL8ouIZf65Cjvpxo
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-audio-codecs-for-interop
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 04:54:16 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I also do not support adoption of the draft. I agree with the reasons
stated by Bernard, but I also think that a separate codec document is
a bad idea in general, regardless of its content. As new codecs get
adopted and included in non-IETF contexts, the contents would soon be
outdated.

	Jean-Marc

On 24/07/14 04:18 PM, Bernard Aboba wrote:
> I do not support adoption of the draft in its current form, for
> the following reasons:
> 
> a. The draft only currently covers AMR-WB, AMR and G.722.  Since
> the AMR codecs generally are accessible only through a proprietary
> "blackbox" API that does not permit WebRTC use without a separate
> license, these codecs are not currently practical to support in
> browsers, even in operating systems that support AMR-WB/AMR for
> other uses.
> 
> b. The remaining codec (G.722) does not have these issues, and so
> it could be implemented in browsers.  However, the useful text in
> this portion of the document is so small that it does not justify
> creation of yet another document, even a separate one.
> 
> 
> On Thu, Jul 24, 2014 at 3:50 PM, Sean Turner  > wrote:
> 
> At the RTCWEB session on Thursday there was support for adoption
> of draft-proust-rtcweb-audio-codecs-for-interop as an informational
> WG draft.  If you do not support adoption of this draft as a WG
> draft please respond to this email by August 1st.  Please also
> indicate why you do not support WG adoption.
> 
> spt _______________________________________________ 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
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJT0eLuAAoJEJ6/8sItn9q9BVYH/jbxk53SF+IV/mGpGpnqUXM9
VSjlWSQcOBuJoSSUgjPlu3gIaJ+9uTypJXkq/vGYAOE8JSsNeZ3FkORqpsnR4CUX
PGjNEahtkJN+3XqEAqJLU3mPuy8tLtgE+MUgSOi9iQvMyalxGMjpDg8ksEFyQG6p
6/HzNGk7qtaA4v/LkuQvTV+OkGA4QfmtZKrwh9syZVZ7tHCBvM/J0dk3TOWoOrJ6
RelfzBfk8+SWOm1rHBxO9+gDrxx0S8YjqQuVHddWo0sTofJ4is2MS5q1zbn2sN1M
iauuVTkoePQbcnfUf9py1gYLofYsSkEupzoNstdmeAuJUYaIvLDVi09stNINgzk=
=bnqu
-----END PGP SIGNATURE-----


From nobody Fri Jul 25 00:13:38 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7841AD6B0 for ; Fri, 25 Jul 2014 00:13:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level: 
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFVgxp9RD9Qn for ; Fri, 25 Jul 2014 00:13:34 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A44C71ABB2D for ; Fri, 25 Jul 2014 00:13:33 -0700 (PDT)
X-AuditID: c1b4fb25-f79da6d000004ad3-2a-53d2039b340f
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A9.9D.19155.B9302D35; Fri, 25 Jul 2014 09:13:31 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0174.001; Fri, 25 Jul 2014 09:13:30 +0200
From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= 
To: Martin Thomson , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Confidentiality for data channels
Thread-Index: AQHPp2+y/8JuNzuSS0aj9ytYzJxEMw==
Date: Fri, 25 Jul 2014 07:13:29 +0000
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D0357FC@ESESSMB209.ericsson.se>
References: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.147]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvje5s5kvBBufnSFhcO/OP0WLtv3Z2 ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSuj7dpMloLfnBXnZq5kbmDs5Ohi5OSQEDCR OPHmPCuELSZx4d56NhBbSOAoo8SudUpdjFxA9iJGiTVrr7GAJNgEAiW27lsAViQiECJxpG06 WLOwgLnEpfYfjBBxC4m3Nz+zQth6Eku3f2cCsVkEVCVm/JkGNodXwFeidcJPFohlARK3/u8C m8kIdMT3U2vA6pkFxCVuPZnPBHGcgMSSPeeZIWxRiZeP/wHN5wCylSSmbU2DKNeTuDF1ChuE rS2xbOFrZohVghInZz5hmcAoMgvJ1FlIWmYhaZmFpGUBI8sqRtHi1OKk3HQjY73Uoszk4uL8 PL281JJNjMBoOLjlt+oOxstvHA8xCnAwKvHwPmi8GCzEmlhWXJl7iFGag0VJnHfhuXnBQgLp iSWp2ampBalF8UWlOanFhxiZODilGhgzRJZ/iTdr/rw4yvHnGmm3upUbt5UY7mx/+/TsoeMF D4t2r/D+v3WlyEHFq+c6zu9QEfeMcCkP2/erIbXtq4jsxplidWEeefrPn6rdvxnhw2ZtnD9j 80LNP9NOLtStOhFlrL1ml8tZu5b81RKh4jnzcgOvRS5l7T/5ubUwmH3N1q2zfaYXt/UqsRRn JBpqMRcVJwIARZMaX2cCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/R29Gez8dH5pBccneLDS2qfviqPY
Subject: Re: [rtcweb] Confidentiality for data channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 07:13:35 -0000

On 24/07/14 20:47, Martin Thomson wrote:=0A=
> One issue that I neglected to mention yesterday in the ALPN discussion is=
 this:=0A=
>=0A=
> What do we do with data channels?=0A=
>=0A=
> After discussions with Michael Procter, I have reached something of a=0A=
> conclusion on the subject and wanted to share and get more feedback.=0A=
>=0A=
> There are two approaches that immediately spring to mind:=0A=
>=0A=
> 1. forbid the use of data channels (at least in their present form)=0A=
> when the RTCPeerConnection is in a confidential mode=0A=
>=0A=
> 2. permit the use of data channels and note that their contents are=0A=
> not, and cannot ever be, confidential, since they innately require=0A=
> that applications create and consume their contents=0A=
>=0A=
> I think that the latter option is closer to reality, though it makes=0A=
> me a little sad about the potential to do things like confidential=0A=
> file sharing or confidential text chat, even if we have no current=0A=
> desire to provide these features (and the necessary widgets) in=0A=
> browsers.=0A=
=0A=
I think option 2 is the natural one for now. IMO there would be little =0A=
value in forbidding data channels if the app can send data using e.g. a =0A=
WebSocket.=0A=
=0A=


From nobody Fri Jul 25 05:14:54 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E644C1B281A for ; Fri, 25 Jul 2014 05:14:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 WZV7DY2MGZgp for ; Fri, 25 Jul 2014 05:14:51 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id CAD931B27F3 for ; Fri, 25 Jul 2014 05:14:49 -0700 (PDT)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta14.westchester.pa.mail.comcast.net with comcast id Wc5Z1o0040QuhwU5EcEpsG; Fri, 25 Jul 2014 12:14:49 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([206.47.221.210]) by omta02.westchester.pa.mail.comcast.net with comcast id WcCe1o00l4YyHWu3NcChWM; Fri, 25 Jul 2014 12:12:47 +0000
Message-ID: <53D249B6.7030806@alum.mit.edu>
Date: Fri, 25 Jul 2014 08:12:38 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Justin Uberti 
References:   <53CEFA2C.8040407@nteczone.com> <53CFA92F.5070306@alum.mit.edu>  <53D0880B.70401@alum.mit.edu>  <53D1AF71.2070003@alum.mit.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1406290489; bh=QcbXwh5ceyzUIThdFp3HnHJnh4p9CCqcPqXiXYgeAAM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fsp6LaXokX2w97vMiIeqUme82eXRogPZhJ3s8RgR8d3w8djLhnkm0DJmcWWxc74zx QxFatgRw5bXqq5p5r7OEO68Bu1o51JZO6mr9tmSiIAxmGpl7INAmWCJwG4/Mqgrlcd a8JndiNDwVsM+L6SnzIfVcww2f41VyHeusI5sZ3yh7XJ4uEFAPgIUJtMSO+PmkEQAP ltZxV1w7fpZWWBrrsmPt9tEshdD2R0fpWSdWMPC6hR7kSNaimgz4E6fTwDE1MFplwH 6NJA38+aVvhD/3zwyK0Y64LJEztnECCQnSYCGsZprbJ4oxJ/sM2p9YmkclA9ZIjy3F JU5GaeSKVC0bw==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/91EIpYlGpiQNh00fgIXRGl-feus
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 12:14:52 -0000

On 7/24/14 10:35 PM, Justin Uberti wrote:

> On Thu, Jul 24, 2014 at 9:14 PM, Paul Kyzivat  > wrote:

>              Clue does have a solution for the simple phone, but it probably
>              isn't a solution that would be satisfactory to rtcweb. The
>         first O/A
>              on a CLUE session assumes it doesn't know what it might be
>              connecting to, and so makes an offer that is likely to work
>         with
>              "legacy" devices. Generally this would be one sendrecv
>         audio and one
>              sendrecv video, though YMMV. There are a few other things
>         in there
>              that allow the two ends to discover if they both can do
>         clue after
>              the first O/A.
>
>              If both do clue, then there is another O/A that provides
>         sendonly
>              m-lines for the offerer. And there will be a 3rd that provides
>              sendonly m-lines by the other end. We consider this
>         tolerable for
>              telepresence.
>
>              The first O/A will also include DTLS/SCTP m-line that is
>         intended to
>              carry the CLUE data channel. (Assumed to be rejected by a
>         "legacy"
>              device.) While we don't require it, bundling is very
>         attractive for
>              clue. So if ICE has succeeded for that m-line, the
>         subsequent O/As
>              can add all those sendonly m-lines in the same bundle, so
>         no new ice
>              will be required.
>
>         I think this would work fine with the new APIs being provided.
>
>
>     Which new APIs? Do they work with the m-line management rules in
>     jsep-07? Do you mean just the ones that allow OfferToReceive with a
>     number?
>
> Yes, the OfferToReceiveX APIs.
>
>         In the initial offer, sendrecv audio, video, and data m= line
>         will be
>         offered, with the option to bundle.
>         In the second offer, the OfferToReceiveVideo:X option can be used to
>         create sendonly m= lines from the offerer.
>
>     Doesn't OfferToReceive generate *recvonly* m-lines. (It hardly makes
>     sense for it to create *sendonly* lines.)
>
> It can do either, as Eric pointed out in the presentation on Wednesday.
> If you specify a number to receive that is less than the expected number
> of m-lines, then the remainder will be marked as sendonly.

OK. I had seen that mentioned in JSEP, but it was new to me and I hadn't 
really grokked it. It does sound like it might work.

The whole point of using these is to describe the characteristics of 
media we are intending to send, which may not all be the same. So the 
client may need to do more editing of these m-lines to get them as 
desired. I think that is allowed.

It is also the case that there might be a lot of these, as 
*possibilities*, though in practice the other end will accept only a few 
of them. That of course assumes that the other end *can* choose which 
ones it wants to use. If the other end is an RTCWEB client I don't see 
how that will work. It can use OfferToReceiveVideo:X to cause recvonly 
lines, but not which of the sendonly lines are chosen.

This gets back to the other issue I raised about needing to consider 
codecs when matching MSTs to m-lines.

I guess at this point what we need are some carefully worked clue 
examples, tailored for what a WebRTC client might be expected to do.

	Thanks,
	Paul


From nobody Fri Jul 25 06:32:23 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281A81A02D2 for ; Fri, 25 Jul 2014 06:32:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vS3qoUxK2YV for ; Fri, 25 Jul 2014 06:32:19 -0700 (PDT)
Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31A0A1A024C for ; Fri, 25 Jul 2014 06:32:18 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 7/25/2014 9:32:13 AM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Primary: jonathan@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-80/SG:2 7/25/2014 9:32:06 AM
X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.907041 p=-0.975327 Source White
X-Signature-Violations: 0-0-0-3811-c
X-Note-419: 0 ms. Fail:0 Chk:1335 of 1335 total
X-Note: SCH-CT/SI:0-1335/SG:1 7/25/2014 9:32:07 AM
X-Note: Spam Tests Failed: 
X-Country-Path: ->UNITED STATES->
X-Note-Sending-IP: 162.209.16.213
X-Note-Reverse-DNS: mail1.vidyo.com
X-Note-Return-Path: jonathan@vidyo.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G335 G336 G337 G338 G342 G343 G453 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 115816424; Fri, 25 Jul 2014 09:32:13 -0400
Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Fri, 25 Jul 2014 08:32:12 -0500
From: Jonathan Lennox 
To: Paul Kyzivat 
Thread-Topic: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
Thread-Index: AQHPqAj10ymk4sXK9UywnNX9K2XcYpuxHWyA
Date: Fri, 25 Jul 2014 13:32:11 +0000
Message-ID: <0BD51883-7083-4966-AE4B-AA6E435A104E@vidyo.com>
References:   <53CEFA2C.8040407@nteczone.com> <53CFA92F.5070306@alum.mit.edu>  <53D0880B.70401@alum.mit.edu>  <53D1AF71.2070003@alum.mit.edu>  <53D249B6.7030806@alum.mit.edu>
In-Reply-To: <53D249B6.7030806@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [31.133.191.192]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/iYSmKBaJIkqRFh1Y6cqAOFPQ4cs
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 13:32:22 -0000

On Jul 25, 2014, at 8:12 AM, Paul Kyzivat  wrote:

> On 7/24/14 10:35 PM, Justin Uberti wrote:
>=20
>> On Thu, Jul 24, 2014 at 9:14 PM, Paul Kyzivat > > wrote:
>>=20
>>    Doesn't OfferToReceive generate *recvonly* m-lines. (It hardly makes
>>    sense for it to create *sendonly* lines.)
>>=20
>> It can do either, as Eric pointed out in the presentation on Wednesday.
>> If you specify a number to receive that is less than the expected number
>> of m-lines, then the remainder will be marked as sendonly.
>=20
> OK. I had seen that mentioned in JSEP, but it was new to me and I hadn't =
really grokked it. It does sound like it might work.

If I understood the JSEP presentation correctly, in the current APIs you ca=
n generate *either* sendonly or recvonly m-lines for an offer, but you can=
=92t generate *both*.  You either get sendrecv and recvonly, or sendrecv an=
d sendonly.  Is that correct?

(Presumably you could fake it by putting the sendrecv lines on hold, though=
?)

Also, is there any way to generate inactive m-lines?=


From nobody Fri Jul 25 09:05:03 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023AE1A03BD for ; Thu, 24 Jul 2014 17:59:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFKUzJ0GwU1m for ; Thu, 24 Jul 2014 17:59:17 -0700 (PDT)
Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9B61A0375 for ; Thu, 24 Jul 2014 17:59:16 -0700 (PDT)
Received: by mail-qg0-f53.google.com with SMTP id q107so4230627qgd.40 for ; Thu, 24 Jul 2014 17:59:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wl2AvQ2WC3mgQyb+qRukohRLuNx02qZ9RLVwk/RsodY=; b=OyhfjezQQ0aV2MDcrcx4LWtGqgCaru6zut0XldUzfC14fZ9iTbWfx8wUyOSHIx+0Aa d0jN4/P7zK2doRs0WDAKB0wzV6bp29nSIpd7fqdwLMPAg6snanWR8jCS/AV+TXS5MyoY uT0hX88KwnOL0g+w+XtKmmroBwvlbgS7KKuzHRi7Ld+88WpRGTsaxWXS0RN/mWa2Qlhu AQUS9KstG29M8Ka/UCoaH2HBdOXC8osW1E8g6hrhmozA7xISk+tem6yoz4D/pzVttk5b byXAO1cBilRi0BmM2NTr89Vzt3e/k1hxpdZAo9I5XojMkd67gRKNaaqoaNp8mdNEJUnm g5gw==
MIME-Version: 1.0
X-Received: by 10.224.130.5 with SMTP id q5mr21286895qas.72.1406249956127; Thu, 24 Jul 2014 17:59:16 -0700 (PDT)
Received: by 10.140.101.21 with HTTP; Thu, 24 Jul 2014 17:59:15 -0700 (PDT)
In-Reply-To: 
References: <0A.F9.03708.848DDC35@epcpsbgx1.samsung.com> 
Date: Fri, 25 Jul 2014 09:59:15 +0900
Message-ID: 
From: franklin blek 
To: "Makaraju, Maridi Raju (Raju)" 
Content-Type: multipart/related; boundary=001a11c2c45219f2b804fefa151c
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/X26mWFFnVB5CptNwg7EgQSHpFHM
X-Mailman-Approved-At: Fri, 25 Jul 2014 09:05:01 -0700
Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" , "kiran.guduru@samsung.com" 
Subject: Re: [rtcweb] New Version Notification for draft-guduru-rtcweb-codec-preferences-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 00:59:21 -0000

--001a11c2c45219f2b804fefa151c
Content-Type: multipart/alternative; boundary=001a11c2c45219f2b404fefa151b

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

As per my understanding, this API is useful.
I think it is good to be present in webrtc1.0. Instead of processing this
as a seperate draft it will be more good to merge with the
RTPSender/Receiver draft. So that all the consensus will be completed at
one point of time, with out delaying the delivery of WebRTC 1.0.


On Wed, Jul 23, 2014 at 9:20 PM, Makaraju, Maridi Raju (Raju) <
Raju.Makaraju@alcatel-lucent.com> wrote:

>   Kiran,
>
> Please see my inline comments marked between  and .
>
>
>
> >This seems like a pretty big hammer to solve a fairly small problem. Thi=
s
> proposal adds 6 new API points for the purpose of >changing the order of
> codecs in createOffer, which seems like a high cost-benefit ratio. And
> while the use cases listed here are >helpful, they seem somewhat contrive=
d
> to me, since it seems unlikely that the application can make better choic=
es
> about >bandwidth >or power consumption than the browser.
>
>
>
> [Raju] Per my understanding, the main object of this draft can be achieve=
d with no additional APIs and with just the proposed introduction of prefer=
redAudioCodecs and preferredVideoCodecs options to RTCOfferAnswerOptions co=
nstraint of createOffer()/createAnswer().
>
> So, IMO I don=E2=80=99t think getCodecPreferences()/setCodecPreferences()=
 add much value, so can be delayed or dropped.
>
>
>
> The need for getSupportedAudioCodecs()/getSupportedVideoCodecs() in 1.0 c=
an be questionable as the application can specify codecs order per known co=
decs (or get the list via a dummy createOffer() call).
>
>  [KIRAN] New API is added for this only because, it can be called on Peer=
connection irrespective of its state and the order of parsing is also easy =
when compared to parsing of whole SDP returned through createOffer/Answer.
>
> * I agree that it is easy. But, I also agree with that Justin that=
 given other must have work this may be lower priority; these small things =
do add up to delay webrtc 1.0 delivery.*
>
> **
>
>
>
> The draft talks about fulfilling A5 in [I-D.ietf-rtcweb-use-cases-and-req=
uirements], but I do not see any explicit mention of how codecs can be remo=
ved? preferredAudio/VideoCodecs constraint only specifies the order of pref=
erence. Don=E2=80=99t you need another constraint to exclude specified code=
cs? It=E2=80=99s probably a bad design to have codecs not in the preferred =
list be removed automatically.
>
>
>
>  [KIRAN] The removal of codecs is explained in section 6.
>
>   "*The offer / answer*
>
> *   SHOULD NOT contain audio codecs other than those specified by*
>
> *   JavaScript application and the order of preference SHOULD be with*
>
> *   high priority for the codecs first in the sequence."*
>
>   Perhaps this is in indirect way. I will modify the statement to directl=
y point this. I don't want to increase the constraints just for removal, wh=
ich can be achieved with this constraint. So I followed this design.
>
> * Sorry I missed that. But, the name =E2=80=9CpreferredCodecs=E2=
=80=9D does not convey the =E2=80=9Cremoval=E2=80=9D part clearly as prefer=
ence generally indicates reordering priority, but not removal. Such semanti=
cs may put additional burden on app to list all the codecs in preferredCode=
cs list where as user may just prefer a particular codec to be the 1st one =
and does not care about other codecs order, so they can keep their relative=
 order but they are needed in the list. IMO, removal of codecs requires ano=
ther separate constraint and not be mixed with preferredCodecs constraint. =
I am not wedded to having separate constraint for removal though, but I see=
k input from other members.*
>
>
>
> **
>
>
>
> *BR*
>
> *Raju*
>
>
>
>
>
> BR
>
> Raju
>
>
>
>
>
>
>
>
>
>

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


As per my understanding, this API is useful.
I think i=
t is good to be present in webrtc1.0. Instead of processing this as a seper=
ate draft it will be more good to merge with the RTPSender/Receiver draft. =
So that all the consensus will be completed at one point of time, with out =
delaying the delivery of WebRTC 1.0.




On Wed, Jul 2=
3, 2014 at 9:20 PM, Makaraju, Maridi Raju (Raju) <Raju.Maka=
raju@alcatel-lucent.com> wrote:















Kiran,


Please see my inline comm=
ents marked between <Raju2> and </Raju2>.<=
/p>


=C2=A0




>This seems like a pretty big hammer to solve a fairly small problem. T=
his proposal adds 6 new API points for the purpose of >changing
 the order of codecs in createOffer, which seems like a high cost-benefit r=
atio. And while the use cases listed here are >helpful, they seem somewh=
at contrived to me, since it seems unlikely that the application can make b=
etter choices about >bandwidth >or
 power consumption than the browser. 


=C2=A0


[Raju] Per my understanding, the main object of this draft c=
an be achieved with no additional APIs and with just the proposed introduct=
ion of preferredAudioCodecs and preferredVideoCodecs options to RTCOfferAns=
werOptions constraint of createOffer()/createAnswer(). 



So, IMO I don=E2=80=99t think getCodecPreferences()/setCodec=
Preferences() add much value, so can be delayed or dropped.



=C2=A0


The need for getSupportedAudioCodecs()/getSupportedVideoCode=
cs() in 1.0 can be questionable as the application can specify codecs order=
 per known codecs (or get the list via a dummy createOffer() call). =




=C2=A0[KIRAN] New API is added for this only because, it can=
 be called on Peerconnection irrespective of its state and the order of par=
sing is also easy when compared to parsing of whole SDP returned through cr=
eateOffer/Answer.



<Raju2> I agree that it i=
s easy. But, I also agree with that Justin that given other must have work =
this may be lower priority; these small things do add up to delay webrtc 1.=
0 delivery.



</Raju2>


=C2=A0


The draft talks about fulfilling A5 in [I-D.ietf-rtcweb-use-=
cases-and-requirements], but I do not see any explicit mention of how codec=
s can be removed? preferredAudio/VideoCodecs constraint only specifies the =
order of preference. Don=E2=80=99t you need another constraint to exclude s=
pecified codecs? It=E2=80=99s probably a bad design to have codecs not in t=
he preferred list be removed automatically.



=C2=A0


 [KIRAN] The removal of codecs is explained in section 6. 


=C2=A0=C2=A0"The offer / answer=




=C2=A0=C2=A0 SHOULD NOT contain audio codecs other than =
those specified by


=C2=A0=C2=A0 JavaScript application and the order of pre=
ference SHOULD be with


=C2=A0=C2=A0 high priority for the codecs first in the s=
equence."



 


Perhaps this is in in=
direct way. I will modify the statement to directly point this. I don't=
 want to increase the constraints just for removal, which can be achieved w=
ith this constraint. So I followed this design.



<Raju2> Sorry I missed th=
at. But, the name =E2=80=9CpreferredCodecs=E2=80=9D does not convey the =E2=
=80=9Cremoval=E2=80=9D part clearly as preference generally indicates reord=
ering priority, but not removal. Such semantics may put additional burden o=
n app to list all the codecs in preferredCodecs list where as user may just=
 prefer a particular codec to be the 1st one and does not care a=
bout other codecs order, so they can keep their relative order but they are=
 needed in the list. IMO, removal of codecs requires another separate const=
raint and not be mixed with preferredCodecs constraint. I am not wedded to =
having separate constraint for removal though, but I seek input from other =
members.



=C2=A0

</Raju2>


=C2=A0

BR


Raju

=C2=A0

=C2=A0


BR


Raju


=C2=A0


=C2=A0




=C2=A0


=C2=A0



























--001a11c2c45219f2b404fefa151b--
--001a11c2c45219f2b804fefa151c
Content-Type: image/gif; name="image001.gif"
Content-Disposition: inline; filename="image001.gif"
Content-Transfer-Encoding: base64
Content-ID: 
X-Attachment-Id: c39157e52c3c24d3_0.1

R0lGODlhCAKQAMQAAAAAAP///8k6OspMTNRiYtt0dOSOjumiovLExPfZ2fvt7f/+/uvr69TU1Lm5
uYyMjG9vb0dHRzMzMyoqKgICAv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEA
ABUALAAAAAAIApAAAAX/ICOOZGmeaKqubOu+cCzPdG3feK7vfO//uYBwSCwaj8ikcslsOp/QqHRK
rVqv2Kx2y+16v1YReEwum8/otHrNbhcX8Lh8Tq/b73al2M3v+/+AgYKDVniGh4h1egyEjY6PkJGS
k0OJlpd5SXsBDQ6engwNjFKilHoNSaVYqkisTK5CoUqdo02waLJMubGogg6Nt1S/a3IIeAoJmHAJ
CnTIipq1EBETFBERDRHDUdqmSQ8PSd1GENzbR+NN6UPgqRPYr+Hrae1MDhFE94MUfA3hRvOKlHPC
z8xAIXIG4EFQAJGBOQWMzWEIDckmIfqEBFR3zhuWgk82DhGJrmOAekcy/zJpR5IMSiUqA8T8A5LN
yyc1l+QEU9MSxUMKD/2cs6iIyggQKExAxSCCtVoBmlKgIC/pBEZSIzBw8I/ryWr/hDSYRjUpvq9U
ozpdGiBp2rZTyzUAO9BqLyHt3IZt22Cs03Jm0YbzS2HgA2sTfj0AixfxNqlsszLqtjgtuAfDMA+p
BlgpqgdJh82d8ACpZ7VPiUA4HNlp2tVKHVT7NbewWKUR9kpNy4Azvt6F8SGdIBg1W71C7CY/rTru
ycr/kiYlAm620+hxm4o9K5ax5Las+04gvTschL5kD8LFBmFCZ9twp8NlO6S21uJfE7dNygD6+kpx
NGTAAQMQkIwCBAxggP+AySTw0AEJPmTAAAU4SIABBiQDIYUKDCVHUflwd81JgJWomlz8UMMABCay
OFdyDzBAgXh3OTBjA1T1JsqNS5VG4lxbEVeaCEut1hQ+i/VHHDsPACkbEdrYuGNfFDggI41SXnml
jVbyiGWV7CDZYjnaXDmXP+CcNWOY/ly12En3xeLiiKDtZ+dISOLDIicpCucmPuTlFkBiMu61J47g
HZnoiFWK4KWPoDkppJuTKkmdVjomieiQ8uHl5o38DKkjW3Vu5gCOK5pIp1YuHpqiJzNeWV+VNjIi
ao+shkoplPLE6OWVbyLlKI04bpPQAgU0dICAByiQLLLGUDSAMQMkkMD/tAgMoICzCChQLbIHeBgH
iEMc9Ys+a8pIhBg2BiCoumsiqh8F/dUVVkYFaVPqaj6KIBsjvQCcGL0yCTcMfc8ByQmUnpzVTaj2
ZqTvQIntCw7F2/TLSLyvWgyOjEGG6O7BaBbB0rn4pFtTN/qw++pzBb8Y85KrrctIuwT7mHPKeNmr
8b8Lj7OU0HdFxUnF/7yMKJMFC1GQwA7sqV93GMmKKMtIhuPyyBKfw49KUHdzNckjDUYijKXKo5i9
AfQUh0IRLSBtM8tCK3dD3yazgEI/xd3ggOLCQS5GIqLc9lRTEWHfy2037jR4Lx6G+L1qasQV4jlS
E2N8TK01MOHuYp6x/3mFFR2lw7+EijlmqNej7+quP6b5xkN0DHuvNZdrsOU3ndw05isbvvjIMN9j
I+LanPXS8AWhC3pBkk8V4+ych474PaIPARnSj49TUzv4GpcYkDXFBNLL+rQz/OmWE/H1Wdsb3332
3QkaPVUvUba64wi9bbe0cKBI3CgCobjt7W5wiNuECECAcDWEDoNrWvucJxYiTO1l8MLK19xTjnoU
LXwj82BUQtGeqPiDXnsaGcH0MY6iqa8/BLNc1xonwq7FToSx0x4JiUMwdenrH58JB2jWpDviDYor
e4EZ1vhnOsNdkHjgS14stqK8vTyxeTz7HV6AOMKxECcUh2mKaIxYtP8U/rB7w/heOMJnxl9wUGQy
AVlU0Je1QSWNa6hznwTb6D0yKq5g/KpgPdQGs4XxLwDHGiDeAtgQRS6AGcs6wAH7hoBl0c2BFTnC
RSRIPBaucUlOs1WKOigcIZ5lPKgAmqBA57goXcVdoNEaVU4pv2KxSFH9QthlaDmShrVvg5NhneVe
VCxVYoY4xRpCzXxoSq69MjftkBEoQeejTSXRd56UyTSXmLOXRbFtnynHmkjjPlHCsi2lRKfjjLnM
WQqhYr/BVVQQJrYq1QNiJ1GjBJUGptAUgV4gs9/u0heObuKxfbWTYD250sFQxfMuhLqHwnLzoiex
7JkFxQgi/efIAkj/ckHgWsCyEkCAZgxokg+MyAEegiBMQjAaRilc03DklHO0xz30okY1UEFTIjpF
meOZJgi7cVNkIiZGQcWHjaiRG+BMY57UUM/HksqwGY5nRUFV6C+KutWstiWo26ApOXuKCqJm1XVJ
bNl4wNS7WQrPGmDqZdNuyh/KrBFJ71jTYsZjqPHwR6z4GM07+FdUPs2Oqr2JKlTdkw/EQPOOvckr
de76uKW+Y4072SuKnFJWwx0GNH7NqS+N+M7EnMWyTR3PTxPLWHYc9avjSc5sjFjYQV2FH4mMVkNI
ysCGZCtZAiJAAQy0AAZS0lvDxVDgFhDBJpzKCH0xSi22ApUidAIK/9eNxXMxcpfsnsRW3NluSoqm
BytxwiT5gIp342iErdyFutA1CcLGOwvylsu+0MVvfGsR3fyuq2i7sO5jxCtemXzQvutNCXbPUSrr
vte8reCpfjUJYbF05ML2ha+F84Ff71I3HIh4RhysVQyJLKBDzZgDig3RXI9MYTGHQa+Ln+CXGdsY
DIuR8Y2x0B+PiEAZQA6ykO/AJB0bYchITrIcFNAsJTs5yDvOgieiTGUt/BgTzLhElp9siS0X48R6
C7KXtZxiMSNgzGM2hIjn4OU1TyTMSXYzi1NRXezWeRBGhgkYaHNn66q3zyaUQp4DrQmeArrQTbgy
HB5yCAMmwtFcbv+0if13AEkKudJAxnSQfwtpSN/hIct19HIN0EAlg/qBiDiCP0grhZtoQTNLWJFO
qLATLYQqiSVhWBJm0oRaxxQmu3tCOXitSQYcS9KX8HSkM23pIGsaE89WRrQDNOk7BMUOyqZDtoF8
bUscwXeEaAkrk+BrJpT7CucuwjpIQmwstHvcUHhfoo29aAqJtECWJhBxC7DAZAyoQAcqAIfs1u9H
ChxDzoJDwkccoQSSesQLGoAkLYShBBQgxRlS1sQbfm9+N4jj1xJusx+ZoH0T6OKPLJBHi8FASTpr
4P82EG9XqiEKEcAYG5p4xCVEIQedWOASt9syJKTvBBT95SjHULX/Ir5Se9+bQxOqEEsFnvSij0sy
siGNaVqTGhY9JRtb7Q/pyDkfF1ZmbVWqTUOXovbupOUvZV9OpwqZNb7KvSDKGWJYq8GW3FhDI4ep
HPjsXh53WWUyilHKXlrmGsw00ysjeY7d10NFvnCiHE7VE3rgHrqnKtMasuE8a3RD75SfWebaIqnR
CYAsZT3kWXXD0AJkr9KLQ2j2BnBWQ4i7Ujk0sKV761YcstUsbWVrWxE5KUkPiOnfe9RbHZpWcZu1
8ptfa+SlrlvQq3/moMfh5seXPe2VdfGKR0T12Tp9t4xfLW9ZC1sCesjyRd1I8jurWeJ/fe6z9f5m
ydzk14IAFJF//60nUqhmJ7c0J2KCgGQCAWJkI76SMFfxJEPyJK7VCUJyH+QRKEg1PeEwPvSyGP6g
FRSYK5P1OEnSLpziUCHzJhbUTIXRFAXlgIJya0dUK4dCHCqyJ9pwJqhSRK7CQvyQOyg4gSyIFCxk
ODxoMFkyIyuoOLQSK/TigzE0QsfSe7NXaYwmSR2lW3vTIHDDEJZmINqCQLJ3cwzHSAfEcovmUrUn
Ug+hEJWGAKx3N1gIfnXIEMuXhUt2YtoHB5W2hye1DHnofin3PxoHLXdYSYwGOClFLQi0LXIThsPX
SF4YN3lDiT8RFH7zc5LEN3gDhog4LhyjRIajMlCUJlIEDkBTVv//oEsUUzIWmISziA2vZCXZNChg
xycnSEN3VE/npIs3gRU6k0opY4y+KDNWsjWr1DFsAzpbww/WsIsJdU/EsxVJ+DvgdVAj0w3qokc2
9IxWSGkDUI4SF21diEDXFoYGFBFBQRGq120/AUDF8EBz+IjFZTdyGC7mSCGaFhHZYo4RYY8jp2/P
EhT3CIjN5iHrOIqYplKWplL96IaQCI8JInBCh0Dp2JCOtIYKVCClBopreEAdyVznY4q/gzmdhBQw
JkSkcx7WMxWjwzuU1TRRgjlSVESuIZN9xDS+iEbzcz1t9Q5ZREHOw4rccTRwZUS2MzlFNDyJ4R7t
okfWmA7ZaJT/TIg6PZlQNrQ/U3SFlqYh+TaKjlSG3gItBnRzZfgTF8JoAZSHi1SPCklJ01eG+/gT
27KIeNkhBMlwyUCPCSlSC/lA69cMZ+lID1lJEamYy4BA+ohAaEiSJiZAl0gthqmJD8SJlYRymCaS
ZomZpKhBKElBQUMboAd6MANGQzNGPnlGtciN/nJalddCTNmLNtg4fUSby8MWWLlOPIOUVfNE3tgx
XFRETzQNuUEN/1RISuNL3AQ67NONv/CNXNk6xfmV/kNSzeBRy0eHZHmJklQ3b3gtuKd79VZt37Jy
3TaJyWAgdAkhjLaPXwiH1xJ91KIhcdgMpfaWCRSXnamfI6ct/+63cuLphYm5fAGoneBCl55JN5So
hulIoJbomJrZe8AnkhI6ioIjUKOZThZ1MDqYM2nyTlzxG1X4JtbkNK5IPHolTsOSPiZaL/lEHcN2
m/h0GHAyR2KXD0vCKOZRUD/6kwA1IwaFFDnagxhVRAYFYzaiHj9JQx0EAdnkI4LyVNGpLyYIjqgz
UWGhaMVVUqTGQIuWIMaQjvBIIenZLQxUagiiIIS5npPIQM2wnnTIQKeWQMZwfXAgnyf3LfqGhn1a
cy3ne3bKeggZniBZkHaacgKXDIjJhd0SpmgoqY4ZN8YVXBdSLfT3nYyaphSKp8jVll96po2qocxF
VvlUGm9VU/9G9FMlBDOIpVNSFVQu6SlX9VWXw1n5gSI06FeLVRM09VPWyFr80BS+ehNBVUKI8UrL
SjvtoFmwlRTZsFadBVtCpSehRSW+kkQ2ClUzog9LNSKClZXtIx05MR4zVFvYqXDClwCTJnyJsGJv
Boh0Y49uKQfuegd6WG2WsGJGBwfEdWLwCmZ1MLB1IGfLEGbyiggGm692sLAkFmQLewgLW7EG+1Ia
xgn4lbFOUGAF9hwfu2HlghUV1l/nxV35QGFLgGEwUQv0sg0vmwrdRV7olWCKM2FOwLGExgtLoBlL
oz0Vpjgd4aXLhgcQQiA4F5mXsFxAhiALUodFG7VSO7VAFgj/rlZly6lHWCsMs+SkUUC0VDsHcxhA
/IoI/+pkRtdkYbu2bNu2gTBlW4sE1xS3wnC1ULAJuxBgQgtdgIZEYJC3OGsEnxC0W6C3WsAKnTC4
h8azMPExXICNcFu4gdtegwYgIwZnbftIZXYMmMu5dUBiZbtpSztkz5Bmn7stnXuwqZsHm6ASxLZU
ACFj17AYXhsGHWQenNRr16CrWzBsSbkF6TAN1XANk/tuXwFai9uz2xCut6oJtUsOudsEItgKezEH
F5K5jwSpiDBtC4FqctCZTwandRAuIwlklEkH9wotTKtwDzJyLNa64fW7WwQFPjJPlduxSZluSAAS
DZYF+msF//NgvL9Gbr1AhFNglSKCa3A0awe8SkbwEvg6XNibmMu2XNy7ttu2tN47B+K7vo55CSNU
RNQEHaMxPdLDF150EAjzXP5BGEMUWGSBHWwBFhczjZjnFPfhd3HyONBZQtAha2qhlHKRHusxFkIM
eKlRH3y3efAReFMjwilceJmHGjvcNqNQCt8hFVGaGLJhG3vVCyrBEiWkHIyhHFpcxHLBGUhcxYOi
HW7XJJO3UQppABIRc+5qaZUUB/8omAnickD3UX8zc/wGcCSnIA7XQAdgccD1cwPXpiA1YirHhYV8
cS9HXCRlyODij3KKLFlIyC93jgxkcfVGXHZ8sBHCIJdcfv89R2oVV6dB53Ozd8mVtnGG7CAH9yHw
W0SagkLn4SpcA1AJVQQycipLISU4glSdkCMhuCsiCA7FpCcm8nZ7wb/itIxSeCZnw4FNSCW+xIFt
0ysWpBjacM1nwiUDXCupwotGMiJ7kkLJQVHKNCa9wRWvxIFzsTmcVIOKwcw9siu3BILd7IHfHIwY
UQ6vdESo4iKWW1xGx2iwVyGc2GyaJoclRZ6yR56KpADm53rTd3/Bx2TNIoAgRYADYp7ft36fGFIe
VTe953yf6H+vl9IPjXskR1LFJ1IldXszjb7UZ4krx53YIqAAKXHo94gQkrYd3UD8Z4iCk8sjjIJa
czOvMhP/mRUxleNMMEI0BNU46MJT0ji/tXMNO+U4FlMzFLUkxpNH7yMzOgPWFdQfOTkxJHrO8CPV
VpyjqEijp4GKK1QyyhhsMmENOsXDWh1sS9HXXG2LeJFFL1EzNaOMO2q5y4cgeAqZhanHliafBySJ
2eKQ2ssQ3mmAa6hpqjefZ1mGdUOIbUiSEyfaqAuXHolzMu2FnE2JD2ogJZkQ9YqWrY1SeBrajvjb
GreHK0WXTV0LrltHP7k+o1U70xXZwNlKo5UmorPV8naS0DPNnxDM9yNMRog8M/Q+GUFBLyE512BD
/xDAp3UWzPM8KtleewI8hwQ+OElasuEJd5Evw8A+O1kl/zkh3utN1lb0DowVExAcQBRSqog5IN47
0YK5p5MMmhQM2oTpn2OY2f24hkPxE+BLUivnLL8XkOUYl3EDvo6UyrYtdAPphXTwjpbo4ZldqQJI
kJREQC5F4ZV93Eqsy3fUDmQ31b+bDrFk1YQ93apaQdatjXMk4FqrtSJUKMSREbH5SwXzmtmtxMaI
3gglwhlxRc9TH+UCSqSJCs0ji3Vt3/Kr3ySajQtT5olt5W49F58gb3F04AuKACd14gpSkDHu4JEp
4Z8dEbB9qKIN4Y3p4pWokAf0l/yGuqS2l7H94KC5nymelqD9wcdGmYwehzL+E8GtvhoX2jiekSFc
O71gP/89XlDmFJ1hjhXjcxU6MlSwggryFOt1JG8ceuXBrLXG5C7NGE7h/TsrquvapBFx7QlGdWEB
ftc4WqUeOk1xVSeC8qGwdE/hhOZGAD2BJW/1K1rndN3D7tZE+DDDEk2o4D+q3ZECt7m919kOjtpw
E56JWJaOmtKCWZ8BIkneuXKPvKftmdI3x5cnddr4Gekm7oXw/ph1g9G0DWf8boloCEA13n7uyXre
MuOSXu90aQyl7ilMZSupHq2ixWvtcR2y5R6VJ91Zh/Ksxas+blqGtSbEfkg8bK2N0QuLwVlWBfN7
xaxubVvuAfPEw1V0ffJ/5Vgxfw42ElQAA1e0cVb/kPP/a9Iew8BrT7NWpumABJ7GsWVb6cP0TP5O
d1En0PpZ7QCI3qstHZnakJwsmq0QYToh0bfIBLIsBrqmc6qQBGKO3SdwebqmDb6mKX1yDXQtwxWe
wvUtminpoxj32vLoCoEgZOrZ+Ar4imhzknSpv72mjAb43TcgiC+nDMpcm+RetjC5FlY0NhtT6yVe
HlZhOksKOkYLFlGylRuy6YVdAEaz+PWxrl+zFYb7SPD7KCuyUWH7VGCyJosJg7hkoZuw+ApnEctm
z+8MZxYHCPtInSuvHRJm7rq5WgZn1z98q8tkKrb98DqxI/auZeawy/D8ktTxjSDAdFv/9n8EhkBq
4I+9//wPAos4kqV5oql4KKr7wqlyLAHDBLm+873/A4M5xkNoPCKTyiWz6XxCo9Kd65CIYbPaLbfr
/YJdNkZYlGiV0yTEtYSInU8JBLocV8feWb25ruKLAOJxCboUqtxxJZosdi3GCR6eFNo05DQ44EA5
TD01aB4xWOrcpB3QDJYZEKAuHLwNxBQUKgwUtH0l0MymjryexGYFr7Se/A6LIPcKwxxn8cYYlECT
/FJ7nVbTKMcqSKso1zhE2FBEjD5RdDo9FCGN75Quz2td84bvFZgWL1974ae4R2+gCH+pAE57Y3BL
NhP4EOgDZyIAPHhS1K3L6MPiEDK+BhC4oqCArRYGDv+AnIMKwaldKAu0eGkA14IEBAZ8K7DKFyp9
NkvWvPltxE9pKEOuSIkTaNESM0/d3IVzgYGUrqoiOAkSwc03I0G+IsBqJlWrUFk5ZSq04EtXKX8i
1XcWVVWkZatqW1DgZZ2jCZbC1Ot2ajWrXwNrJcB1wJvEixUS08tXcNnAcHWl1HfYpF8SM7/aTTq1
6q1VBsj69bs34kgSe20V3Fn3yoECYmlkW5pT72ird8NRJBeBAoQh5GyQazCBeI7j7XYQN4dDOYUJ
DR5wCoA9AITq6LR3d0C9OMUJE9x1t679QQRNED4Nb29jOYTjHYmGPECAqrTTevef9hdbubn0lwII
MEb/AisKoMVYX6jEspdkCywo4QgLVsiCCCOxMIBLFLJgYUEsEXDgfvrpApN+rgRWgD62zaCPfwIG
OIt+M5xYIoLVwKQTiAxuU+BeQLK4QCw37libiSx6gwyBE244pIcTxjLAGaHZpAuA/Unj4n8x6vVi
ibUZGdmUEh7ZozRoKSklf296SeYINso1lJFXJvAXAggqMBIb+ZU45CxIHWAnThwaSYeSKyJ54jYG
IHpkfjBxxSReJQSnnXo5qPdAcecxcF4AGD2nAwVFRFCEqOx5yul1EzDgwAQ7sIcDqKkGMIEDDlBA
RHuyrgdBEcpxVxwExhYXgX1j+PLNNlcIaGEsitUy/8M2xBQqgmL4BaKPMg1FSAO0+y0AEbflvgiI
QK5YQa65c7IEIbpQ5tfTG9mY22e5R+6SFSqKgeuaV392Wya7er0hEpn8JkNvArwIyJPBDY048bVW
1lSNs3fWFOG9NJjLC77emlkyLwcu0AKYAmEc7RvvjkimviO03PC7Nm7Myyz+bUvzFeYGYyHA8ub2
M8kh//twwsBVtOyxue46a6akupMD1TbYUKs6wArrqg7PARscsRQFgGuu12FHTqsUWMKAOr1qt6w8
B9NcNzRHniTXtew2RM27QJcQsE1oITiA4RHNO689sBBT+OECBxyyHjbae7C5P5F08CzQUN4wvCP8
Tf+y5vfe5CXDZZJkOGN35xUMxQhbXKZ+17w+jMeWp4t77K5fSztIXrJs98uIIzzSgtUQwPrN8QqM
cJbcFBz05MzLvjfgIau+uh5Mk8NRAMo1sPVx8Fxtag7PPVCdsme3OhwF72e3HkXvvx+B9+7D347b
ZXNC//uj5sB7c2vINlR2uzL95SQH4122KMSHSs3rW/IymgHeNbNyuSt3n+OdBf3QuTJJTlvUExnI
9NEzhm1OD0PzXMXmAEHAja4WRqtew6BxBdZJjHfN02EszlCbVhDQSAaE3ciIWMLdmSxhf5ohy4bI
C5gVTwEJ2AlRYnSt5QVRZ28ggH9IEAwYQmOFNPz/4tE0eMPtTaRpPJjA08JGvvNVDYDrAV+mjqUr
/l2CVkWwyA0skgn75fE5qYIbRr4nRwF6JCgYnBCZfCSnm5SMXQZCECAwhqbASWNH2wIabQx1w37t
0EydhJy8zEUmAfXtYxGMCQpZ4pPTOcko0rDk3rIxCwiajm5pStkAZmAUJ9WyGOsqWomo0gqbLFJC
jVRlCItISyRmq1C4zF24ivRE4u2MBrXAD2dAGJFZILNSWiyLIKakQNe9UpcL/FAsTKmZXkazG7jI
lPe4Q4HssK1sRcin2awGx7CtTzlSY085QFGqfK7tBmwjqNuIUIQHTOA4uAIWruoTj0RSpSsdI8kN
/8ViFznlJjJH6VkgQFJMZfzFRUeyxbZegjHQmbQF11jFjg7mUpp8sJ2a8ShuKlfEVXDRSiipDR14
qs4RMIij+xJLC3RIU9twcT+wTBlUpZFUSOYwMiOgKQ8zahuarCJBKbUkM3P3U7FccoEpSx7GPCob
xfTQFmRN3IhSipatJg8pYlleRhP01JeFg6Un3ZBRA5abvDa1Y5Cq6lpto9MR0HNZ8/uaeWDFHfP0
U47PqSwEpGYO45iHPHA8nzkQGlrknPY54XNH+IbDCYFG9KJuqMOB0HDLOigwBbrQFk1qIokNAaK2
SKUDI35brt4C1w95QC4iaJKnNTC3BMI1g3HZcP9cGFgXdISIbrkOQdzkeuG5LphuufyQ3ZR99wUH
Qu6ehqvcQNThvA30Isomwd3hFjcQNJGEEFqlA0zsoAHfAUImgiCeIMQKFALewYERXOAhDJhZsgDE
Kt5LgloYwDYE2TCHO+zhD4M4xK4gad1EPBEgQDR+GllxJ+b2Ag354r4bOoWFTWzjG+M4xzouQ3tN
wA8bG1jFLB4yFG7QA1HEI8JENoKQEaxkIHxiyQaWsg+Q/L0m88DKQ9ayk5fMCS4nAcwQ3ggUFkyK
J1P5yGhWsxKw/AQkRxkJYjaCkXVQHO/VM81AKGQQ7ixZIQBSzzzgM5X9PL8/2zlTRM7zRhC9DnX/
lGoJkdajDwg9BNFWuTiTnrSgG01nTcfRCJbehHCwjGkdMFoIdfZnqjsdhVG7egmwHjKfOT1oRQ+5
1Qx2dEZsfQRf+3rUuoaHr2P9BF3rWdfC5jUQVt0d+0WUOQ3QNH14ANE7jqc56UuVeXAwSG5b1jmo
2ra3kcMcTUnn2dM2t3yE5Z0dvGfawzk1RE/1vc4eqzuiqPa02diDb/vTnpvqjrSXI596x1He50a4
Pc/xHvOUygFVe7as5n2+5cSRAcNRj8alw530cZw+yal22TqLavPYWz5lA0XH2w1yWd3ze8tRj9oS
PnNLfHs66kv4zmV+boykxxIYF/h3MM6eoT+H/+AZtzi6h1WfUz373sPx1GfXzR0BP70466YOet73
qVOpluQ53wE53K2r5XDC7DD/cnxwECrilN0S6Uv3Zxk+DokHMNRVVvA9eWUJtpGvf+hw26ty9QCN
7/Pw/sbVqUKVrH2ONuWQP1aoMsHPB4RvV2VHVtnUtiz7+Z3wpGAb+HjlbQjYSvHY6RUoTIV6xmuK
CLOqVagagKtUEZ6OAWQb4d0mHutkfhwMOFb4tP3fvueT96TfVNzAU6znr4+gwtI4OW61zwfPD/PW
6drYcvC0p60vArAi6B0JCuk4lp8ckoea29BveVUdHvYQlb2mXkV/ykocVsBqh3JiJTXvo56u+P9e
6ZFe41mH361W7VkE6CkfJlSfePQK7VkHRKGN4SHeqIwbdHRe2YyfcAhHBz7f98VfqTWUPmVe7h3g
OWBEZv3AqgHQAmreqFjCd/iX9p2P+jUHJzzHCuog5MnP1bwNDhzYDMIe+cygOgDS/cQgHp0PeQgL
DMpcE6ZaPr1RoHGczI3DsDjfx6GaREmcE0IesamK5bWe+OSgf3XNDY6BDJYDHpEPDrDH2LwRg0nN
E87K05hK2yBhD2ZK25if/PxX1uDgHNVh1YyNsMghDlqhAzIh84mhP/GfZX0H3IgHGqZNwIHecfAg
DHLiOUhNgU2Hrojh2PwhIPoTIIFNqcmPEbb/IdwQFCBNh/yBITwIINyoWhkqWiZqSqCNVgCNzyCi
og8Go2b54A7KkZ1Vh6iYYSHtIa7xDxSSFv1cohv+4hT6IgDhzz11nHn8Hq7M3ftUDQyWijE+oqcQ
lAaKo/9UjcaByqj4DzUekv34zyB2YeTpntW84zASW/3g4KbxIzFaRKQF5OrRjyL6TwxmY/w8IgAl
HXFMIqWth0VsoibmYCdWpP3IzcaJYs350SBOWjOmIh6FpP+8zTUCUnooo3aoI7EJC7ORAi5a5Cew
yte4A3Z8IjDyIQ/+YOTxJEZU4sGFofq5XTMqITQCoiVAoRth5A/4pCJmhyXgof0gZQQIC2vt/9oZ
guEL1tz3EEeomSH/lMp33EC/HSPOccIc3t1xGBmhWUTX2NGt5ZE+euJUMqQhqscctsNA1mNEqiUO
NKMhwUOgfcdCnt/3EIEtHtJ1zCJFPiNj6mJjXqQfDR956GJe3iQxaqBciuQe0ePfmaTEAWVd5hE8
hE8a3iI6euE49B8XXsKsAMvlydEw6uQO4lwxQh4gpUqrhEpQ6lPzJeHnLSEvyoq3TWOgXZ5FxJnV
FEHXQJom2t5r3ZMAqma4haMX9l/taSUgLkfrZSf/rGY/dc3+TNSs/GZvWhRCFQdb8t5dnpsOjOdm
BgdA9WM4Ss36AKHQxVE+KaPcpWfzKaDnzf8HOhDmepzjHeWgCcLKf2LiEm7irPieRbIe2wBS8G0l
bJbPKfJhYGaocOwReS5nqelmSg6nPi0gJZ6mDnBjapZdRDHfZcXctVnWbAojH3ZWRNkmAMFWOYjf
06QoVw6HWTrjY/LiZZlHLmYHjMaKF0IHi/rlfOzoodkoRInfclbWVeJRjaJerujKVjbfGm3pgdbo
//moqLRWzJUnbKlNtHkmHYaWJuRTgJUWJ2gmZ81KYaJoaNXpaMFoHO3pLiafk/pbaYbKkx5fVUKi
4mFWgFUpkaKeRF7kgmqp+AVnDF7bnZmDjbqNoSIpZpqPZmpmmb5WZZWacuzop8BKmCraOc7/WkfE
A/b1wK5sBDoAmCes2SXET4KRAvbhahTMKpQ1WYNZTazE6n+pGCYomJvxQK/uKrzp3bKeWZPFymCi
GZcZaxCYWRQOqxAAK4Gt2bUG2HdUKw8A66xuq60aWIT16pVtAnf6wLWm67siqxRE65kdma4WWLp6
n961ILsaW792mlf6KxB0Fr8GLJOxYMEibMIqbJoNrJwR7MJCbK9FrHbU6sR+j75abMZq7MbSSsW+
JMeCbMiK7MiSbMmaLBO44Mmq7MqybMu67MvK68PC7MzSbM3a7M0qbMri7M7ybM/67M+irMwC7dAS
bdEarcrq7NEq7dIybdMWbNI6bdRK7dRS/+2bCW3VYm3Wam3U6qwE7IDXAgHYBoHXiq0EmO3X8oDZ
qq3YCkHZrq0OgO3anm0AsK0P1C3coi3czm0OxO3b8u3Xym3Y7q3bsu3dBu7fhm3b9oDh6q3a4i3d
+i3d8u3bxm3aPq7kjm3aRu7dQm7hNm7eJm7nDq4TRK7dYi7g+i3hgu7lli3qHu7klm4SOC7r7u3p
/gDnrqHlPu7rGu7ski3inq7n6m7jUu7wIi7n4u7k3i7otu7xsu7lQu/z2u7iZi7wzq71bu7iym3t
Tm/vXm/wAq/10m7g1m3zTm/wpq70gq/zii/1Gu/Ytm7ysu/yDq/50u/5Iu/2yu/+ou7qXv+U+4Zv
++Zt5VauAOPv/XYv7Bbw+w4w9ZrvAwtw4b5u/f6t/gaw5vqu+kIwA5evAgOw8IouBg9u7YJwBH/w
7hLvBmOuCvsv+m4v+/6u6a6w6GawCE+w/kpw7Oou4aavBa/vD2cZd8Zw5zKv+xKwCbsu966u5wrv
C58v5AIu2qpw8z6wElfvDFdw/wIwFv8wD3vvDdtuB0MvFVPwBZdwF39w+iLx+rJwCn8vF2PxEFsu
BOdwEYev/C7BAmfx58qwC1tx7rYv45qxB6tu9MquHQNxGDMBGSPxBuOwFV/vAtuv/0qyBhuy4hpw
345uAYtxIityEl/y9xYy9kayAk/yII//8e46Lu6Wbymjchc/Mg1PcANbMuwi8imzagDL8SfT8i5P
wRDrMRzzMhJ0cB2rsitHQSWbsSBPsfoegRj3rRHjbTDz7hxf8hZfcR+38TNvMQhzMv6+sDKDMzLf
cRPgcCOPLxrvXR638Dd7cSTHsjVf8O2esw3PcgszMPP6cBKf7Sg/sQw3synbsw4XLDALLh6Trgbv
Mz9zb+m6MzHz8TwbQT3L8h8bsiivsRfvqz2/LzPvMQJD9PyaMh6TNDdnMzbnczmH7kpntDOj9Ehz
dExrb+wyMumCcRl7Mj7rtC47L0JL9DwLMku/9E5rcy3/swsyc1AT70dT9D9T8jAbcEgT/7VTU3VT
Gy8uw+9M6zM5v3RQK7VSv3Ix260Tc7AbjzAyW/VQL/M093Fbwy9ZV/Q7W/QykzVGR/RRtx5Yp7QU
X3NfY3JYL7Ja/3RVK4E3F/ZgIzb/ovQpn/EB7/VP+/JFS/YV+/Qjk208y/Nj+7RjD3Zlx7NeTzXu
MkAL8PNf/3VTp7Vbw3Vqt/NCU/RrLzRlx7by6u1JCzYrzzJcw/RYEzQHnzVvi/Js169wa0T+1rVw
o/Y+s/Zb33NotyBpb210S/d0G+1o1wB1Y3d2azfMWvd2e/d3gzfHdnd4k3d5m3esjfd5q/d6s/cU
jLcTa/Lo3rJAQzZV+/Vmi/BEV+9X2/92URuBAAC4AOgAgA94gBd4EBB4AAS4gSu4gB9Bgjd4gUM4
hPsAhR84ECx4hu9Ahlu4Eiz4hROxX/P2Ejc3Udv1Y9+3UI9zidc356Y3LUtxQ7u05AY3W/fvKtM3
Z4v4Uusyjuu4P39xP+94gnN4DhC5gx+5kSP5kit5kz+4g0d4lCd5g394lEs4g/dAh284lDt5lnO4
loO4Nsd2QO+0RW+zjBtx9tKzbv/4VcdvlUE3DJ8wQ89tNct5JzP2ZG/14TbxVb8yF+c5TmM4k0v5
klf5lCM6of83lCd6lW95l2M5lXu5EHw5pQv4hFc6gfuwYhu1LIcuK7u0HiMvUKu4Xp//MSNH9osb
NA1HryNjMArTOE579UzntkqL9CeLtQdHNWdb9ZEfOqEnupMH+6L7OoNP+aNbuYd/OZczAYFbuKM7
umbLeh5L8JyjbxQ/cTBD9myjdhkf8ZHFefe+8bhL76gfr4/Xsp238xKncgLzeCCvsZ4jAbQzOpYX
e6MbO7P/wK9feZgLu6Ev+xIse6TzgLNz+bCHeGdr9TET90STsEnvsFuD9GGH8LkLObhftwVru7i7
MnzD+i5XMSQ/vJ+PMVf3OU+Lc5BHtsDrO7Ij/BMkOZh3OaS3vMwPvMwjeMAXupOHPCL395DFdzgD
9Ij/vGV/NBsfPSmEe5qrcSc89Hxn/zut0/QbqzaMn3ZfUzFmTwHCD7ylbznOV3i9X7mGN7vO57yX
Y3q873rbjrnWJ/PQD7XRT7wco/oTv/htL3Zpf7y7I70WT/xU8zSsu3GnC/q8F7m/DzvOg/2+iz2y
z7zitzyVR3vYLzo77/rGr72J67etC74tc/w64Hm5J30uK7zD13U3v/mNX7zHqzglC73eNzaQD7R8
e73jd73kH/vtJ7u/F7zOEzymV/qk277ZDzraH37C6/j95jCL2zcQ1zPrQ79gOzM0Y3us80DK5PXP
l/WfZ7b2c7zGu73mQzVhb37z737aOz7lz7zw9/7Zpz/7L/76oz+x+z6z43zQ3/Pvrv/6IWcuCEiB
KAajiZ7pWq5o2b7uHM9unZLuojC5BAy2hMIbEfgr2mRLpg3XjD6lqhcxCr1ZjzOB9ytIgcdNL2oM
Npm76HWg7Waf4ba2mE51wcPLbN8Jc+RXRQNoIjiY2CdoxPXXhMPjk0dZaXmJmam5ydnp+QkaKjpK
Wmp6KiWJusra6voKGys7S1tLqmqbq7vL2+v7CxwcgCtcbHyMnKy8fNvD/AwdLT1NDUssFZQzckW4
nX2YOeQ4pEU5uKXdXYW4sqeG9sZnmpYXd2f/jh9v1x6mL/evnrx3ZQYKzBSHXz55awLe+0JwIUQ2
bszAizenosF9F+vwucbuD5SRLMD/lTz0TV0NcY7QKVFXbh3KloXu9ItoMyM9jmQeWpyYZg/DhhDJ
7Izy0+jGORwxSjyqBw9TnDp7OqWicapWOVcPOrWHjyhVnku3LiGK55pJlkp0xEzXtlwMGHJT4ljp
JO8UkyrubuFmVuzNsQH1afyJMyvGpAMZF6QatOziogYRI62M2ezXjQ4HXwXrz45gShdBR306mHFk
rJkjqu1bci4jlYQCjYMbO503wHzvzja09vc5skA5U04tNWdT5YoRH3V8NnQ/ywCP2+xM3PTYzVEV
ek7Y0ePTiVw/h5862vzjy6ddOzs5FzjfbuTWysUtf7hu/TSQ6O0fEmsPBcYHduNp/6feZFYRt153
UPm04GSV/KNYTgY2aBpoFU7YmGTRVaiaTgS6o9UaPCiwwF9x9aZbbfDN15tdetFlzm/GiNahVRce
ViB59MAD3WZhCUUQdaetdqBkQg2FVo7nCdTkktwtx1prnCSFXEQXTtcjCgygWFMS2iDC30y8vbUX
mVmsRCYLjKhp5kvZkdeeFCQOSKWWxRUZWnN0kiZdYX1KV+eVe0bHpXcLbSced1LaOaiihuqJyY/y
fJkimpeMdCaMe0ES5iOe+IUNopBeImiTN4nF6qCJ/VmVn12tap1nBSnUaoOodgmejl3OasmWDvZE
omBD4srrpWBqGpJ+pLa4WzZ4Uf8x3LOQ2OhpgIUyumujjqkqYj6L9rpUhkNNGSuhtgLLFbm6cqsc
lQjulF6V65qqWYk+GpdluAFgGic3pDqrBZyfenqwigJTy/BJXsWb6JJPcrloow5SVK6VTNVLa5JG
4luex792S5iHHD8G3sPwOjTkvcoBTO1s2iqsCZs0/RfzzdGm9N/MEM/JypYsK1mWpNd5+HPI77p8
mdGFOo1echlNDfSwD+ar2Z3lwVxN115/DXbY0XAtdtlmn4122qSQrXbbbr8Nd9psx0133XbfLczc
eO/Nd99+r71stAjjDG3CMOU2U+GFv6mwf40j7NuKKs7Y6X4z7uf44SesCRPPirj/ia3DNeqs+Hyc
s1R6zz6nrjl8L30uKi1cDxwmYM6GHheNMiVOuIvZJuybpprzZq3D9eWl+/HbyGAbXc/WZzuoB7Ml
p/Cmx05C7tLzPnj38Qn+O4vGQz55964wMEn4JJFfquj2bS4+bPG/Ja31zb+ouB/KF5+E49+4Jb/d
yQ+A9nkeOuRTsOltr2Dr856Y4pO9hcVPf4f7nuXGFxy78AyBvTtf+sCnuwu67wm4K+AET1iI462O
gOIAh/8kSD/QbRCDLoJefkyIGwP+bobzQ94CrfAD0Z0OgQSMCfU+1UDahG9362tgEmeBvhh2Dmdl
cuBu1pG55KkOiE8UYRd9WJfM/1kieuLTYhnr17/OZTFOWwxii2A3xvwxgRxFQN0Ns8UmIRqxEf6D
0f9qFyoopo9xU4ScGH+InyIisYMAstG0mnczC6LEep3Aix3L6ELLVbGQcVReD3f2OgFS0Ydm9IYA
N5lJPy4OEM1inxpRGYooNoyGrAtY9WgEwFZ+EpSwpKQMK3et1dkSjnuEjQUVyUs/ilFNdOwZI6fg
yVI185Ss3CAzmXc5Z+5SeNFsXStkqT7QUa6XNXGe9FSYhy8ukHQj3FnsKkFMDJrzevwJYQedGM5G
hvJ9v/zjNNGJQsMxEVo6FCU/uWezXIAzme7E4ori2chUMtSUVCwhIlf5TCWiie1TLYGoG+FHn1cK
jAvxtKQv04Q4ac7RoW9c4ztDGghm7ZOhtwnYQWGxUP7V0p7tVKn5AvnTzVHwpZIkKvCAyroqIhOk
PX1pLefYpvYJFKlMpeo903lRQDbVmzz1YP+qt1VvDhOrY3VqgLLIUeKdaYXA9B0fXyec0G01rWBN
Klk54VFf5tV89cyqEeXKSHKCYqF/K6xhD4vYJRA2sYxtrGPrttjHSnaylPVaZCuL2cxqNm8f3Kxn
PwtaQYZ2tKQtbSnQh9rUqna1rG2ta18L29jKdra0ra1tb4vb3Op2t7ztrW9/C9zgCne4xP1tCAAA
Ow==
--001a11c2c45219f2b804fefa151c--


From nobody Fri Jul 25 22:42:45 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F291A0301 for ; Fri, 25 Jul 2014 22:42:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id linkA9E1eAmT for ; Fri, 25 Jul 2014 22:42:38 -0700 (PDT)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A07221A0004 for ; Fri, 25 Jul 2014 22:42:37 -0700 (PDT)
Received: by mail-wg0-f50.google.com with SMTP id n12so5160001wgh.9 for ; Fri, 25 Jul 2014 22:42:36 -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:content-type; bh=HGZDoY6DKFOwUfeg7UlbS+GO/sbNAjweabIEYhJm+Ok=; b=KxluCmf1N5j+xhuSXJciMOj7ed7MsOI2OjaOobYTAeN1ToiGFuQQPA3F5gyyHIcPSW 2vmPPehlcdOO7IyMHBca1O9/qOi72SQnTbgPJAtMsLKyDTD13mxR6qhs49DuQGTOFfv5 SsOavErLR1BHNTtQOq1kQnURatXfdfsiF8ZshulugN2xe2W45gt2kiXdeA4U29b7oq93 BhLkLoyvi5OyH7xQSKL2S0hT15DG8lQJK5Why2TjAG/CMCp7Si3E83IQUkZ4TC4xD6FN LHi+zkKBGnYcXrhmp1j1WDrJjHUS2Av5kUzkqi20kZyAMAPa2hcJtavkiFzpL4D67Xzk AXrg==
X-Received: by 10.180.92.38 with SMTP id cj6mr11248481wib.64.1406353355877; Fri, 25 Jul 2014 22:42:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.136.137 with HTTP; Fri, 25 Jul 2014 22:42:15 -0700 (PDT)
In-Reply-To: <53D14F29.3040809@omnitor.se>
References:  <53B71B6E.2010604@omnitor.se> <470AD025-E40B-43BD-B141-599489FB892C@lurchi.franken.de> <53B797C1.3080609@omnitor.se> <596034E6-7D76-4F82-AFD3-521B8C0217B8@lurchi.franken.de> <53D14F29.3040809@omnitor.se>
From: Barry Dingle 
Date: Sat, 26 Jul 2014 15:42:15 +1000
Message-ID: 
To: Gunnar Hellstrom 
Content-Type: multipart/alternative; boundary=f46d043c7faa34b3ff04ff1228ba
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/AVpRfqmMRDQl8XTR8BkqOqAoVSM
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] WGLC for data channel drafts rtcweb-data-channel and rtcweb-data-protocol - missing descriptions of error situations
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Jul 2014 05:42:42 -0000

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

I agree that error handling is missing from draft-ietf-rtcweb-data-channel.

WebRTC 1.0 does not reference SCTP. It only references the
draft-ietf-rtcweb-data-channel.

*SCTP* (RFC 4960) Section '10.2 SCTP-to-ULP' describes the signals that are
sent from the SCTP to the Upper Layer Protocol. There are 8 Notifications
including 'DATA ARRIVE', 'NETWORK STATUS CHANGE', 'COMMUNICATION ERROR'.

We need to indicate in draft-ietf-rtcweb-data-channel how the 'Error
signals' are passed from SCTP to WebRTC 1.0. In addition, WebRTC 1.0 needs
a new Section "5.4 Error Handling" (before the existing Garbage Collection)
that is similar in style to Section "4.6 Error Handling" (of
RTCPeerConnection).

Gunnar - Can you repeat your suggested text additions to
draft-ietf-rtcweb-data-channel as there was some discussion relating to it?

Once we have some agreed draft-ietf-rtcweb-data-channel text, then we can
get some action on WebRTC 1.0.

Cheers,
/Barry Dingle



On Fri, Jul 25, 2014 at 4:23 AM, Gunnar Hellstrom <
gunnar.hellstrom@omnitor.se> wrote:

>  Michael said below:
> "So I think the only thing not covered is what to do if the SCTP
> association fails, but it is obvious to me that all channels are gone. Do
> we need to state that explicitly? What do others think?"
>
> I have not seen any response. I think it belongs to a complete
> specification to cover error situations.
> You say that all channels are gone in an error situation. How do you
> define "gone". Who will get an indication and what cleaning up is needed?
>
> I still think a good chapter on error handling is needed, both in the API
> speciifcation and in the data-channel specification. Even if there are
> mechanisms for part of this error handling in SCTP, I think that the
> data-channel specification should tell how the error situations influence
> rtcweb data channels..
>
> I have seen developers wondering in discussion groups why the WebRTC
> channels often get disconnected when they should be reliable. But that is
> in the definition of "reliable", that when all (about 5)  retries are don=
e
> or any of the timeout mechanisms expire, the association breaks up and
> channels disappear. And from your answers, I get that also the partially
> reliable type of channels will be gone if either the association watchdog
> or the ICE connectivity check fails but not if just the configured
> retransmission limit is reached. I cannot find any summary of these
> mechanisms, so it is just from your responses that I have learnt to know
> them vaguely.
>
> I have earlier proposed some wordings for the data-channel draft. Can it
> be picked up, corrected and inserted into the specification?   ( same for
> the API, and it would be good to coordinate the additions. )
>
> Regards
>
> Gunnar
>
>
>
>
>
>
>
>
>
>
>  ------------------------------
> Gunnar Hellstr=C3=B6m
> Omnitor
> gunnar.hellstrom@omnitor.se
> +46708204288
>  On 2014-07-07 22:00, Michael Tuexen wrote:
>
> On 05 Jul 2014, at 08:14, Gunnar Hellstrom  =
 wrote:
>
>
>  On 2014-07-04 23:34, Michael Tuexen wrote:
>
>  On 04 Jul 2014, at 23:23, Gunnar Hellstrom =
  wrote:
>
>
>  I cannot find that what happens in transmission error situations is desc=
ribed in any of these drafts.
>
> Both reliable and partially reliable transmission can fail, and the appli=
cation designer need to know what happens.
>
>  I don't understand the notion of "reliable and partially reliable transm=
ission can fail"...
> If a user message gets abandoned (so the stack gives up transmitting/retr=
ansmitting it, but
> the association stays alive), I don't think it is signalled via the JS AP=
I, but that might
> be an issue of W3C. If the association fails, all data channel fail. This=
 is signalled.
> However, this is something for the W3C document.
>
>  The W3C mechanism makes use of the rtcweb-data-channel.
> The rtcweb-data-channel should tell what happens in error situations and =
if that is possible to be signaled to higher layers.
> The higher layers should have specified the requirements on the data-chan=
nel.
> If no requirements can be found, we should either propose behavior in err=
or situations or request to get requirements stated from upper layers.
>
>  SCTP tells the user if the association has failed. At that point all dat=
a channels
> must be closed. But I think this is something which needs to be stated in=
 the
> W3C document...
>
>   We discussed it earlier, and came to the conclusion that
> A failing reliable channel will tear down the connection and some indicat=
ion will be provided if possible to the application.
> A failing partially reliable channel will enable transmission of next dat=
a item. ( I do not remember if the application will get any error indicatio=
n or if it needs to have its own sequence checking if it is interested in k=
nowing if there are no gaps. )
>
> I suggest that a section on failure handling is added. I get the impressi=
on that it is in the data-channel draft it would be best suited.
>
>  But this is about the API. So it should go into the W3C document.
>
>  The API can only provide the functions provided by the mechanisms it has=
 underneath.
>
> There was a mail discussion in webRTC about the error situations.
> A conclusion was that if a reliable channel reaches its retry limit ( tha=
t is usually only about 5 for WebRTC) or some other indication that the cha=
nnel failed to convey the data, then the channel shall be broken (by the ch=
annel) and indications provided to both sides if possible. (another reasons=
 mentioned was missed heartbeats for the whole association, setting a retry=
 time limit of - what was it - - - 15 seconds?)
>
>  A reliable channel doesn't have a limit. The association has. If the ass=
ociation breaks,
> all data channels are gone.
>
>  If the retries or retransmission time is exceeded for a partially reliab=
le channel, the conclusion was that communication can continue with next da=
ta item. I am not sure if the applications were to
>
>  It will continue. It is not a stop and wait...
>
>  get any notification about that or if they need to introduce sequence nu=
mber checking themselves if they are interested to know.
>
>  I don't think so. I don't see anything in the JS API.
>
>  I cannot see how we can avoid describing the mechanisms needed and what =
happens to the channel.
>
>
> I found a sentence about this  in section 6.6 of the data-channel-11 draf=
t.
>
> "
>
> If a message with an unsupported PPID is received or some error is
>  detected by the receiver (for example, illegal ordering), the
>  receiver SHOULD close the corresponding data channel."
>
>
> This paragraph could be extended to tell more about error situations in o=
pen channels.
> I suggest to move this sentence to a new section and add description of o=
ther situations. The sentence only tells about errors detected at the recei=
ving end. But it can also be the transmitting end that detects the problem.=
 It should be stated what shall be done then.T
>
> Something like this ( with my questions in paranthesis).
> -------------------------------------------------------Proposed error han=
dling section in rtcweb-data-channel---------------------------------------=
------------------------------------
> 6.7 Transmission failure and error handling
> Failures can occur when a data channel is open.
>
> If transmission in a reliable channel fails, the channel shall be closed =
by the party detecting the failure and an error indication provided.      (=
 what does STCP do in this situation? )
>
>  This can't happen. Only the association can fail and in this case all da=
ta channels are gone...
>
>  If a watchdog times out, the channel shall be closed with an error indic=
ation.         ( if this is part of the channel mechanisms, I have not seen=
 where it is defined.)
>
>  If you think about SCTP HEARTBEATs, it is like the above. But it is more=
 likely
> that ICE will detect it first.
>
>  If retransmissions or transmission time is exceeded in a partially relia=
ble channel, the transmission SHALL be allowed to continue with next data i=
tem.
>
>  It is not stop and wait... next item might be transmitted before the mes=
sage is abandoned.
>
>  If reception out-of order is detected from an SCTP channel for which ord=
ered transmission is requested, the receiver SHALL close the data channel.
>
>  This is covered by the text cited above.
>
>  If a message with an unsupported PPID is received or some logical error =
is detected by the receiver, the receiver SHALL close the corresponding dat=
a channel.
>
>  This is covered by the text cited above.
>
> So I think the only thing not covered is what to do if the SCTP associati=
on fails,
> but it is obvious to me that all channels are gone. Do we need to state t=
hat
> explicitly? What do others think?
>
> Best regards
> Michael
>
>  --------------------End of proposed section on failure handling---------=
---------------------------------------------------------------------------=
---------------------------------------
>
>
>
> Regards
>
> /Gunnar
>
>
>  Best regards
> Michael
>
>  Regards
>
> Gunnar
> Gunnar Hellstr=C3=B6m
> Omnitorgunnar.hellstrom@omnitor.se
> On 2014-06-10 20:52, Ted Hardie wrote:
>
>  Dear WG,
>
> This starts a working group last call for our core Data Channel drafts:
>
> draft-ietf-rtcweb-data-protocol-06.txt
> draft-ietf-rtcweb-data-channel-10.txt
>
> Please review them in detail, especially for areas which may be of concer=
n to the broader IETF community.  This WGLC will end on June 27, 2014.
>
> Ted, Sean, Cullen
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb
>
>  _______________________________________________
> rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/r=
tcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

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


I agree that error handling is missing=
 from draft-ietf-rtcweb-data-channel. 

WebRTC 1.0 does not ref=
erence SCTP. It only references the draft-ietf-rtcweb-data-channel. 


SCTP (RFC 4960) Section '10.2 SCTP-to-ULP' describes the sig=
nals=20
that are sent from the SCTP to the Upper Layer Protocol. There are 8 Notifi=
cations including=20
'DATA ARRIVE', 'NETWORK STATUS CHANGE', 'COMMUNICATION =
ERROR'. 

We need to indicate in draft-ietf-rtcweb-data-cha=
nnel how the 'Error signals' are passed from SCTP to WebRTC 1.0. In=
 addition, WebRTC 1.0 needs a new Section "5.4 Error Handling" (b=
efore the existing Garbage Collection) that is similar in style to Section =
"4.6 Error Handling" (of RTCPeerConnection). 



Gunnar - Can you repeat your suggested text additions to draft-ie=
tf-rtcweb-data-channel as there was some discussion relating to it? 
Once we have some agreed draft-ietf-rtcweb-data-channel text, then w=
e can get some action on WebRTC 1.0. 




Che=
ers,
/Barry Dingle




On Fri, Jul 25, 2014 at 4:23 AM, Gunnar =
Hellstrom <gunnar.hellstrom@omnitor.se> wrote:
=




 =20
   =20
 =20
  

    
Michael said below:

      "So I think the only thing not covered is what to do if the SCTP
      association fails,
      but it is obvious to me that all channels are gone. Do we need to
      state that
      explicitly? What do others think?"

      

      I have not seen any response. I think it belongs to a complete
      specification to cover error situations.

      You say that all channels are gone in an error situation. How do
      you define "gone". Who will get an indication and what clea=
ning up
      is needed?

      

      I still think a good chapter on error handling is needed, both in
      the API speciifcation and in the data-channel specification. Even
      if there are mechanisms for part of this error handling in SCTP, I
      think that the data-channel specification should tell how the
      error situations influence rtcweb data channels..

      

      I have seen developers wondering in discussion groups why the
      WebRTC channels often get disconnected when they should be
      reliable. But that is in the definition of "reliable", that=
 when
      all (about 5)=C2=A0 retries are done=C2=A0 or any of the timeout mech=
anisms
      expire, the association breaks up and channels disappear. And from
      your answers, I get that also the partially reliable type of
      channels will be gone if either the association watchdog or the
      ICE connectivity check fails but not if just the configured
      retransmission limit is reached. I cannot find any summary of
      these mechanisms, so it is just from your responses that I have
      learnt to know them vaguely.

      

      I have earlier proposed some wordings for the data-channel draft.
      Can it be picked up, corrected and inserted into the
      specification? =C2=A0 ( same for the API, and it would be good to
      coordinate the additions. ) 

      

      Regards

      

      Gunnar

      

      

      

      

      =C2=A0 =C2=A0 

      

      

      

      

      

      

        

        Gunnar Hellstr=C3=B6m

        Omnitor

        gu=
nnar.hellstrom@omnitor.se

        +46708204288

      

      On 2014-07-07 22:00, Michael Tuexen wrote:

    

    

      
On 05 Jul 2014, at 08:14, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se=
> wrote:



      

        
On 2014-07-04 23:34, Michael Tuexen wrote:


        

          
On 04 Jul 2014, at 23:23, Gunnar Hellstrom <gunnar.hellstrom@omnito=
r.se> wrote:



          

            
I cannot find that what happens in transmission error situ=
ations is described in any of these drafts.

Both reliable and partially reliable transmission can fail, and the applica=
tion designer need to know what happens.


          

          
I don't understand the notion of "reliable and part=
ially reliable transmission can fail"...
If a user message gets abandoned (so the stack gives up transmitting/retran=
smitting it, but
the association stays alive), I don't think it is signalled via the JS =
API, but that might
be an issue of W3C. If the association fails, all data channel fail. This i=
s signalled.
However, this is something for the W3C document.


        

        
The W3C mechanism makes use of the rtcweb-data-channel.
The rtcweb-data-channel should tell what happens in error situations and if=
 that is possible to be signaled to higher layers.
The higher layers should have specified the requirements on the data-channe=
l.
If no requirements can be found, we should either propose behavior in error=
 situations or request to get requirements stated from upper layers.


      

      
SCTP tells the user if the association has failed. At that point=
 all data channels
must be closed. But I think this is something which needs to be stated in t=
he
W3C document...


      

        

          

            
We discussed it earlier, and came to the conclusion that
A failing reliable channel will tear down the connection and some indicatio=
n will be provided if possible to the application.
A failing partially reliable channel will enable transmission of next data =
item. ( I do not remember if the application will get any error indication =
or if it needs to have its own sequence checking if it is interested in kno=
wing if there are no gaps. )

I suggest that a section on failure handling is added. I get the impression=
 that it is in the data-channel draft it would be best suited.


          

          
But this is about the API. So it should go into the W3C docu=
ment.


        

        
The API can only provide the functions provided by the mechani=
sms it has underneath.

There was a mail discussion in webRTC about the error situations.
A conclusion was that if a reliable channel reaches its retry limit ( that =
is usually only about 5 for WebRTC) or some other indication that the chann=
el failed to convey the data, then the channel shall be broken (by the chan=
nel) and indications provided to both sides if possible. (another reasons m=
entioned was missed heartbeats for the whole association, setting a retry t=
ime limit of - what was it - - - 15 seconds?)


      

      
A reliable channel doesn't have a limit. The association has=
. If the association breaks,
all data channels are gone.


      

        
If the retries or retransmission time is exceeded for a partia=
lly reliable channel, the conclusion was that communication can continue wi=
th next data item. I am not sure if the applications were to=20


      

      
It will continue. It is not a stop and wait...


      

        
get any notification about that or if they need to introduce s=
equence number checking themselves if they are interested to know.


      

      
I don't think so. I don't see anything in the JS API.


      

        
I cannot see how we can avoid describing the mechanisms needed=
 and what happens to the channel.


I found a sentence about this  in section 6.6 of the data-channel-11 draft.

"

If a message with an unsupported PPID is received or some error is
 detected by the receiver (for example, illegal ordering), the
 receiver SHOULD close the corresponding data channel."


This paragraph could be extended to tell more about error situations in ope=
n channels.
I suggest to move this sentence to a new section and add description of oth=
er situations. The sentence only tells about errors detected at the receivi=
ng end. But it can also be the transmitting end that detects the problem. I=
t should be stated what shall be done then.T

Something like this ( with my questions in paranthesis).
-------------------------------------------------------Proposed error handl=
ing section in rtcweb-data-channel-----------------------------------------=
----------------------------------
6.7 Transmission failure and error handling
Failures can occur when a data channel is open.

If transmission in a reliable channel fails, the channel shall be closed by=
 the party detecting the failure and an error indication provided.      ( w=
hat does STCP do in this situation? )


      

      
This can't happen. Only the association can fail and in this=
 case all data channels are gone...


      

        
If a watchdog times out, the channel shall be closed with an e=
rror indication.         ( if this is part of the channel mechanisms, I hav=
e not seen where it is defined.)


      

      
If you think about SCTP HEARTBEATs, it is like the above. But it=
 is more likely
that ICE will detect it first.


      

        
If retransmissions or transmission time is exceeded in a parti=
ally reliable channel, the transmission SHALL be allowed to continue with n=
ext data item.


      

      
It is not stop and wait... next item might be transmitted before=
 the message is abandoned.


      

        
If reception out-of order is detected from an SCTP channel for=
 which ordered transmission is requested, the receiver SHALL close the data=
 channel.


      

      
This is covered by the text cited above.


      

        
If a message with an unsupported PPID is received or some logi=
cal error is detected by the receiver, the receiver SHALL close the corresp=
onding data channel.


      

      
This is covered by the text cited above.

So I think the only thing not covered is what to do if the SCTP association=
 fails,
but it is obvious to me that all channels are gone. Do we need to state tha=
t
explicitly? What do others think?

Best regards
Michael


      

        
--------------------End of proposed section on failure handlin=
g--------------------------------------------------------------------------=
-------------------------------------------------



Regards

/Gunnar



        

          
Best regards
Michael


          

            
Regards

Gunnar
Gunnar Hellstr=C3=B6m
Omnitor
gunnar.hel=
lstrom@omnitor.se
On 2014-06-10 20:52, Ted Hardie wrote:


            

              
Dear WG,

This starts a working group last call for our core Data Channel drafts:

draft-ietf-rtcweb-data-protocol-06.txt
draft-ietf-rtcweb-data-channel-10.txt

Please review them in detail, especially for areas which may be of concern =
to the broader IETF community.  This WGLC will end on June 27, 2014.

Ted, Sean, Cullen


_______________________________________________
rtcweb mailing list

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


            

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


          

        

        

      

      

    

    

  



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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





--f46d043c7faa34b3ff04ff1228ba--


From nobody Fri Jul 25 23:18:41 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDABC1A0327 for ; Fri, 25 Jul 2014 23:18:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.552
X-Spam-Level: 
X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=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 pjsz7CuyNnGU for ; Fri, 25 Jul 2014 23:18:34 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B50671A031D for ; Fri, 25 Jul 2014 23:18:33 -0700 (PDT)
Received: from [10.54.131.214] (unknown [88.128.80.96]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 6C62C1C0B3D10; Sat, 26 Jul 2014 08:18:29 +0200 (CEST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Michael Tuexen 
In-Reply-To: <53D14F29.3040809@omnitor.se>
Date: Sat, 26 Jul 2014 08:18:26 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <189B84DE-EEE2-45A6-A163-B7C6CDA78E50@lurchi.franken.de>
References:  <53B71B6E.2010604@omnitor.se> <470AD025-E40B-43BD-B141-599489FB892C@lurchi.franken.de> <53B797C1.3080609@omnitor.se> <596034E6-7D76-4F82-AFD3-521B8C0217B8@lurchi.franken.de> <53D14F29.3040809@omnitor.se>
To: Gunnar Hellstrom 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xqx6cei2nlMjYb9e7JKHS7ZuhvY
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] WGLC for data channel drafts rtcweb-data-channel and rtcweb-data-protocol - missing descriptions of error situations
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Jul 2014 06:18:37 -0000

On 24 Jul 2014, at 20:23, Gunnar Hellstrom  =
wrote:

> Michael said below:
> "So I think the only thing not covered is what to do if the SCTP =
association fails, but it is obvious to me that all channels are gone. =
Do we need to state that explicitly? What do others think?"
>=20
> I have not seen any response. I think it belongs to a complete =
specification to cover error situations.
> You say that all channels are gone in an error situation. How do you =
define "gone". Who will get an indication and what cleaning up is =
needed?
What I mean by all channels are gone is that the association has been =
terminated,
either graceful or not. However, there is no graceful shutdown of the =
association
been specified for WebRTC, so this only applies to the case where the =
peer is not
reachable anymore. That is why I use the term gone...
>=20
> I still think a good chapter on error handling is needed, both in the =
API speciifcation and in the data-channel specification. Even if there =
are mechanisms for part of this error handling in SCTP, I       think =
that the data-channel specification should tell how the error situations =
influence rtcweb data channels..
Again: If the association fails, all data channels fail and should get =
whatever onError
is appropriate, but that is an API issue and needs to be specified by =
W3C.
>=20
> I have seen developers wondering in discussion groups why the WebRTC =
channels often get disconnected when they should be reliable. But that =
is in the definition of "reliable", that when all (about 5)  retries are =
done  or any of the timeout mechanisms expire, the association breaks up =
and channels disappear. And from your answers, I get that also the =
partially reliable type of=20
I wouldn't expect 5, but 10. See
=
http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-05#section-6.=
1
and
http://tools.ietf.org/html/rfc4960#section-15
> channels will be gone if either the association watchdog or the ICE =
connectivity check fails but not if just the configured retransmission =
limit is reached. I cannot find any summary of these=20
And that is correct. If you send a message on an unreliable channel with =
let's say 2
retransmissions, a message will be abandoned after two retransmissions, =
but the channel stays
alive.

Best regards
Michael
> mechanisms, so it is just from your responses that I have learnt to =
know them vaguely.
>=20
> I have earlier proposed some wordings for the data-channel draft. Can =
it be picked up, corrected and inserted into the specification?   ( same =
for the API, and it would be good to coordinate the additions. )=20
>=20
> Regards
>=20
> Gunnar
>=20
>=20
>=20
>=20
>    =20
>=20
>=20
>=20
>=20
>=20
> Gunnar Hellstr=F6m
> Omnitor
> gunnar.hellstrom@omnitor.se
> +46708204288
> On 2014-07-07 22:00, Michael Tuexen wrote:
>> On 05 Jul 2014, at 08:14, Gunnar Hellstrom =

>>  wrote:
>>=20
>>=20
>>> On 2014-07-04 23:34, Michael Tuexen wrote:
>>>=20
>>>> On 04 Jul 2014, at 23:23, Gunnar Hellstrom =

>>>>  wrote:
>>>>=20
>>>>=20
>>>>> I cannot find that what happens in transmission error situations =
is described in any of these drafts.
>>>>>=20
>>>>> Both reliable and partially reliable transmission can fail, and =
the application designer need to know what happens.
>>>>>=20
>>>> I don't understand the notion of "reliable and partially reliable =
transmission can fail"...
>>>> If a user message gets abandoned (so the stack gives up =
transmitting/retransmitting it, but
>>>> the association stays alive), I don't think it is signalled via the =
JS API, but that might
>>>> be an issue of W3C. If the association fails, all data channel =
fail. This is signalled.
>>>> However, this is something for the W3C document.
>>>>=20
>>> The W3C mechanism makes use of the rtcweb-data-channel.
>>> The rtcweb-data-channel should tell what happens in error situations =
and if that is possible to be signaled to higher layers.
>>> The higher layers should have specified the requirements on the =
data-channel.
>>> If no requirements can be found, we should either propose behavior =
in error situations or request to get requirements stated from upper =
layers.
>>>=20
>> SCTP tells the user if the association has failed. At that point all =
data channels
>> must be closed. But I think this is something which needs to be =
stated in the
>> W3C document...
>>=20
>>>>> We discussed it earlier, and came to the conclusion that
>>>>> A failing reliable channel will tear down the connection and some =
indication will be provided if possible to the application.
>>>>> A failing partially reliable channel will enable transmission of =
next data item. ( I do not remember if the application will get any =
error indication or if it needs to have its own sequence checking if it =
is interested in knowing if there are no gaps. )
>>>>>=20
>>>>> I suggest that a section on failure handling is added. I get the =
impression that it is in the data-channel draft it would be best suited.
>>>>>=20
>>>> But this is about the API. So it should go into the W3C document.
>>>>=20
>>> The API can only provide the functions provided by the mechanisms it =
has underneath.
>>>=20
>>> There was a mail discussion in webRTC about the error situations.
>>> A conclusion was that if a reliable channel reaches its retry limit =
( that is usually only about 5 for WebRTC) or some other indication that =
the channel failed to convey the data, then the channel shall be broken =
(by the channel) and indications provided to both sides if possible. =
(another reasons mentioned was missed heartbeats for the whole =
association, setting a retry time limit of - what was it - - - 15 =
seconds?)
>>>=20
>> A reliable channel doesn't have a limit. The association has. If the =
association breaks,
>> all data channels are gone.
>>=20
>>> If the retries or retransmission time is exceeded for a partially =
reliable channel, the conclusion was that communication can continue =
with next data item. I am not sure if the applications were to=20
>>>=20
>> It will continue. It is not a stop and wait...
>>=20
>>> get any notification about that or if they need to introduce =
sequence number checking themselves if they are interested to know.
>>>=20
>> I don't think so. I don't see anything in the JS API.
>>=20
>>>=20
>>>=20
>>> I cannot see how we can avoid describing the mechanisms needed and =
what happens to the channel.
>>>=20
>>>=20
>>> I found a sentence about this  in section 6.6 of the data-channel-11 =
draft.
>>>=20
>>> "
>>>=20
>>> If a message with an unsupported PPID is received or some error is
>>>  detected by the receiver (for example, illegal ordering), the
>>>  receiver SHOULD close the corresponding data channel."
>>>=20
>>>=20
>>> This paragraph could be extended to tell more about error situations =
in open channels.
>>> I suggest to move this sentence to a new section and add description =
of other situations. The sentence only tells about errors detected at =
the receiving end. But it can also be the transmitting end that detects =
the problem. It should be stated what shall be done then.T
>>>=20
>>> Something like this ( with my questions in paranthesis).
>>> -------------------------------------------------------Proposed =
error handling section in =
rtcweb-data-channel-------------------------------------------------------=
--------------------
>>> 6.7 Transmission failure and error handling
>>> Failures can occur when a data channel is open.
>>>=20
>>> If transmission in a reliable channel fails, the channel shall be =
closed by the party detecting the failure and an error indication =
provided.      ( what does STCP do in this situation? )
>>>=20
>> This can't happen. Only the association can fail and in this case all =
data channels are gone...
>>=20
>>> If a watchdog times out, the channel shall be closed with an error =
indication.         ( if this is part of the channel mechanisms, I have =
not seen where it is defined.)
>>>=20
>> If you think about SCTP HEARTBEATs, it is like the above. But it is =
more likely
>> that ICE will detect it first.
>>=20
>>> If retransmissions or transmission time is exceeded in a partially =
reliable channel, the transmission SHALL be allowed to continue with =
next data item.
>>>=20
>> It is not stop and wait... next item might be transmitted before the =
message is abandoned.
>>=20
>>> If reception out-of order is detected from an SCTP channel for which =
ordered transmission is requested, the receiver SHALL close the data =
channel.
>>>=20
>> This is covered by the text cited above.
>>=20
>>> If a message with an unsupported PPID is received or some logical =
error is detected by the receiver, the receiver SHALL close the =
corresponding data channel.
>>>=20
>> This is covered by the text cited above.
>>=20
>> So I think the only thing not covered is what to do if the SCTP =
association fails,
>> but it is obvious to me that all channels are gone. Do we need to =
state that
>> explicitly? What do others think?
>>=20
>> Best regards
>> Michael
>>=20
>>> --------------------End of proposed section on failure =
handling------------------------------------------------------------------=
---------------------------------------------------------
>>>=20
>>>=20
>>>=20
>>> Regards
>>>=20
>>> /Gunnar
>>>=20
>>>=20
>>>> Best regards
>>>> Michael
>>>>=20
>>>>> Regards
>>>>>=20
>>>>> Gunnar
>>>>> Gunnar Hellstr=F6m
>>>>> Omnitor
>>>>>=20
>>>>> gunnar.hellstrom@omnitor.se
>>>>>=20
>>>>> On 2014-06-10 20:52, Ted Hardie wrote:
>>>>>=20
>>>>>> Dear WG,
>>>>>>=20
>>>>>> This starts a working group last call for our core Data Channel =
drafts:
>>>>>>=20
>>>>>> draft-ietf-rtcweb-data-protocol-06.txt
>>>>>> draft-ietf-rtcweb-data-channel-10.txt
>>>>>>=20
>>>>>> Please review them in detail, especially for areas which may be =
of concern to the broader IETF community.  This WGLC will end on June =
27, 2014.
>>>>>>=20
>>>>>> Ted, Sean, Cullen
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> rtcweb mailing list
>>>>>>=20
>>>>>>=20
>>>>>> rtcweb@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>> _______________________________________________
>>>>> rtcweb mailing list
>>>>>=20
>>>>> rtcweb@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>=20
>=20


From nobody Fri Jul 25 23:20:14 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9070E1A032C for ; Fri, 25 Jul 2014 23:20:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.552
X-Spam-Level: 
X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=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 N0g8o3nHpJgp for ; Fri, 25 Jul 2014 23:20:00 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FBDB1A0327 for ; Fri, 25 Jul 2014 23:20:00 -0700 (PDT)
Received: from [10.54.131.214] (unknown [88.128.80.96]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 550BE1C0ACEB4; Sat, 26 Jul 2014 08:19:58 +0200 (CEST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Michael Tuexen 
In-Reply-To: 
Date: Sat, 26 Jul 2014 08:19:56 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <53B71B6E.2010604@omnitor.se> <470AD025-E40B-43BD-B141-599489FB892C@lurchi.franken.de> <53B797C1.3080609@omnitor.se> <596034E6-7D76-4F82-AFD3-521B8C0217B8@lurchi.franken.de> <53D14F29.3040809@omnitor.se> 
To: Barry Dingle 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Vf9E2OMGEQJntBz_pn3isdmCUs4
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] WGLC for data channel drafts rtcweb-data-channel and rtcweb-data-protocol - missing descriptions of error situations
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Jul 2014 06:20:03 -0000

On 26 Jul 2014, at 07:42, Barry Dingle  wrote:

> I agree that error handling is missing from =
draft-ietf-rtcweb-data-channel.=20
>=20
> WebRTC 1.0 does not reference SCTP. It only references the =
draft-ietf-rtcweb-data-channel.=20
>=20
> SCTP (RFC 4960) Section '10.2 SCTP-to-ULP' describes the signals that =
are sent from the SCTP to the Upper Layer Protocol. There are 8 =
Notifications including 'DATA ARRIVE', 'NETWORK STATUS CHANGE', =
'COMMUNICATION ERROR'.=20
>=20
> We need to indicate in draft-ietf-rtcweb-data-channel how the 'Error =
signals' are passed from SCTP to WebRTC 1.0. In addition, WebRTC 1.0 =
needs a new Section "5.4 Error Handling" (before the existing Garbage =
Collection) that is similar in style to Section "4.6 Error Handling" (of =
RTCPeerConnection).=20
Again: This is an API issue and needs to be discussed in the W3C =
document. Whatever signal
you want to provide to the JS application needs to be specified there.
This is at least what I think...=20

Best regards
Michael
>=20
> Gunnar - Can you repeat your suggested text additions to =
draft-ietf-rtcweb-data-channel as there was some discussion relating to =
it?=20
>=20
> Once we have some agreed draft-ietf-rtcweb-data-channel text, then we =
can get some action on WebRTC 1.0.=20
>=20
> Cheers,
> /Barry Dingle
>=20
>=20
>=20
> On Fri, Jul 25, 2014 at 4:23 AM, Gunnar Hellstrom =
 wrote:
> Michael said below:
> "So I think the only thing not covered is what to do if the SCTP =
association fails, but it is obvious to me that all channels are gone. =
Do we need to state that explicitly? What do others think?"
>=20
> I have not seen any response. I think it belongs to a complete =
specification to cover error situations.
> You say that all channels are gone in an error situation. How do you =
define "gone". Who will get an indication and what cleaning up is =
needed?
>=20
> I still think a good chapter on error handling is needed, both in the =
API speciifcation and in the data-channel specification. Even if there =
are mechanisms for part of this error handling in SCTP, I think that the =
data-channel specification should tell how the error situations =
influence rtcweb data channels..
>=20
> I have seen developers wondering in discussion groups why the WebRTC =
channels often get disconnected when they should be reliable. But that =
is in the definition of "reliable", that when       all (about 5)  =
retries are done  or any of the timeout mechanisms expire, the =
association breaks up and channels disappear. And from your answers, I =
get that also the partially reliable type of channels will be gone if =
either the association watchdog or the ICE connectivity check fails but =
not if just the configured retransmission limit is reached. I cannot =
find any summary of these mechanisms, so it is just from your responses =
that I have learnt to know them vaguely.
>=20
> I have earlier proposed some wordings for the data-channel draft. Can =
it be picked up, corrected and inserted into the specification?   ( same =
for the API, and it would be good to coordinate the additions. )=20
>=20
> Regards
>=20
> Gunnar
>=20
>=20
>=20
>=20
>    =20
>=20
>=20
>=20
>=20
>=20
> Gunnar Hellstr=F6m
> Omnitor
> gunnar.hellstrom@omnitor.se
> +46708204288
> On 2014-07-07 22:00, Michael Tuexen wrote:
>> On 05 Jul 2014, at 08:14, Gunnar Hellstrom =

>>  wrote:
>>=20
>>=20
>>> On 2014-07-04 23:34, Michael Tuexen wrote:
>>>=20
>>>> On 04 Jul 2014, at 23:23, Gunnar Hellstrom =

>>>>  wrote:
>>>>=20
>>>>=20
>>>>> I cannot find that what happens in transmission error situations =
is described in any of these drafts.
>>>>>=20
>>>>> Both reliable and partially reliable transmission can fail, and =
the application designer need to know what happens.
>>>>>=20
>>>> I don't understand the notion of "reliable and partially reliable =
transmission can fail"...
>>>> If a user message gets abandoned (so the stack gives up =
transmitting/retransmitting it, but
>>>> the association stays alive), I don't think it is signalled via the =
JS API, but that might
>>>> be an issue of W3C. If the association fails, all data channel =
fail. This is signalled.
>>>> However, this is something for the W3C document.
>>>>=20
>>> The W3C mechanism makes use of the rtcweb-data-channel.
>>> The rtcweb-data-channel should tell what happens in error situations =
and if that is possible to be signaled to higher layers.
>>> The higher layers should have specified the requirements on the =
data-channel.
>>> If no requirements can be found, we should either propose behavior =
in error situations or request to get requirements stated from upper =
layers.
>>>=20
>> SCTP tells the user if the association has failed. At that point all =
data channels
>> must be closed. But I think this is something which needs to be =
stated in the
>> W3C document...
>>=20
>>>>> We discussed it earlier, and came to the conclusion that
>>>>> A failing reliable channel will tear down the connection and some =
indication will be provided if possible to the application.
>>>>> A failing partially reliable channel will enable transmission of =
next data item. ( I do not remember if the application will get any =
error indication or if it needs to have its own sequence checking if it =
is interested in knowing if there are no gaps. )
>>>>>=20
>>>>> I suggest that a section on failure handling is added. I get the =
impression that it is in the data-channel draft it would be best suited.
>>>>>=20
>>>> But this is about the API. So it should go into the W3C document.
>>>>=20
>>> The API can only provide the functions provided by the mechanisms it =
has underneath.
>>>=20
>>> There was a mail discussion in webRTC about the error situations.
>>> A conclusion was that if a reliable channel reaches its retry limit =
( that is usually only about 5 for WebRTC) or some other indication that =
the channel failed to convey the data, then the channel shall be broken =
(by the channel) and indications provided to both sides if possible. =
(another reasons mentioned was missed heartbeats for the whole =
association, setting a retry time limit of - what was it - - - 15 =
seconds?)
>>>=20
>> A reliable channel doesn't have a limit. The association has. If the =
association breaks,
>> all data channels are gone.
>>=20
>>> If the retries or retransmission time is exceeded for a partially =
reliable channel, the conclusion was that communication can continue =
with next data item. I am not sure if the applications were to=20
>>>=20
>> It will continue. It is not a stop and wait...
>>=20
>>> get any notification about that or if they need to introduce =
sequence number checking themselves if they are interested to know.
>>>=20
>> I don't think so. I don't see anything in the JS API.
>>=20
>>> I cannot see how we can avoid describing the mechanisms needed and =
what happens to the channel.
>>>=20
>>>=20
>>> I found a sentence about this  in section 6.6 of the data-channel-11 =
draft.
>>>=20
>>> "
>>>=20
>>> If a message with an unsupported PPID is received or some error is
>>>  detected by the receiver (for example, illegal ordering), the
>>>  receiver SHOULD close the corresponding data channel."
>>>=20
>>>=20
>>> This paragraph could be extended to tell more about error situations =
in open channels.
>>> I suggest to move this sentence to a new section and add description =
of other situations. The sentence only tells about errors detected at =
the receiving end. But it can also be the transmitting end that detects =
the problem. It should be stated what shall be done then.T
>>>=20
>>> Something like this ( with my questions in paranthesis).
>>> -------------------------------------------------------Proposed =
error handling section in =
rtcweb-data-channel-------------------------------------------------------=
--------------------
>>> 6.7 Transmission failure and error handling
>>> Failures can occur when a data channel is open.
>>>=20
>>> If transmission in a reliable channel fails, the channel shall be =
closed by the party detecting the failure and an error indication =
provided.      ( what does STCP do in this situation? )
>>>=20
>> This can't happen. Only the association can fail and in this case all =
data channels are gone...
>>=20
>>> If a watchdog times out, the channel shall be closed with an error =
indication.         ( if this is part of the channel mechanisms, I have =
not seen where it is defined.)
>>>=20
>> If you think about SCTP HEARTBEATs, it is like the above. But it is =
more likely
>> that ICE will detect it first.
>>=20
>>> If retransmissions or transmission time is exceeded in a partially =
reliable channel, the transmission SHALL be allowed to continue with =
next data item.
>>>=20
>> It is not stop and wait... next item might be transmitted before the =
message is abandoned.
>>=20
>>> If reception out-of order is detected from an SCTP channel for which =
ordered transmission is requested, the receiver SHALL close the data =
channel.
>>>=20
>> This is covered by the text cited above.
>>=20
>>> If a message with an unsupported PPID is received or some logical =
error is detected by the receiver, the receiver SHALL close the =
corresponding data channel.
>>>=20
>> This is covered by the text cited above.
>>=20
>> So I think the only thing not covered is what to do if the SCTP =
association fails,
>> but it is obvious to me that all channels are gone. Do we need to =
state that
>> explicitly? What do others think?
>>=20
>> Best regards
>> Michael
>>=20
>>> --------------------End of proposed section on failure =
handling------------------------------------------------------------------=
---------------------------------------------------------
>>>=20
>>>=20
>>>=20
>>> Regards
>>>=20
>>> /Gunnar
>>>=20
>>>=20
>>>> Best regards
>>>> Michael
>>>>=20
>>>>> Regards
>>>>>=20
>>>>> Gunnar
>>>>> Gunnar Hellstr=F6m
>>>>> Omnitor
>>>>>=20
>>>>> gunnar.hellstrom@omnitor.se
>>>>>=20
>>>>> On 2014-06-10 20:52, Ted Hardie wrote:
>>>>>=20
>>>>>> Dear WG,
>>>>>>=20
>>>>>> This starts a working group last call for our core Data Channel =
drafts:
>>>>>>=20
>>>>>> draft-ietf-rtcweb-data-protocol-06.txt
>>>>>> draft-ietf-rtcweb-data-channel-10.txt
>>>>>>=20
>>>>>> Please review them in detail, especially for areas which may be =
of concern to the broader IETF community.  This WGLC will end on June =
27, 2014.
>>>>>>=20
>>>>>> Ted, Sean, Cullen
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> rtcweb mailing list
>>>>>>=20
>>>>>>=20
>>>>>> rtcweb@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>> _______________________________________________
>>>>> rtcweb mailing list
>>>>>=20
>>>>> rtcweb@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>=20
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>=20
>=20


From nobody Sun Jul 27 17:44:32 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB7A1B27CF for ; Sun, 27 Jul 2014 17:44:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhbFEZyxmCns for ; Sun, 27 Jul 2014 17:44:28 -0700 (PDT)
Received: from BLU004-OMC3S2.hotmail.com (blu004-omc3s2.hotmail.com [65.55.116.77]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 273191B27CD for ; Sun, 27 Jul 2014 17:44:27 -0700 (PDT)
Received: from BLU436-SMTP50 ([65.55.116.73]) by BLU004-OMC3S2.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712);  Sun, 27 Jul 2014 17:44:27 -0700
X-TMN: [C6Od18K3Tnsc4tAU2jW7pfunrGVrTsHS]
X-Originating-Email: [coverdale@sympatico.ca]
Message-ID: 
Received: from PaulNewPC ([74.15.62.229]) by smtphm.sympatico.ca over TLS secured channel with Microsoft SMTPSVC(8.0.9200.16384);  Sun, 27 Jul 2014 17:44:26 -0700
From: Paul Coverdale 
To: 
References:  
In-Reply-To: 
Date: Sun, 27 Jul 2014 20:44:15 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHPp4O7RRt3DNdZ4E2+IDpgyWaWGpuwHeQ5gASDESA=
Content-Language: en-us
X-OriginalArrivalTime: 28 Jul 2014 00:44:26.0544 (UTC) FILETIME=[15411300:01CFA9FD]
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_7QIov52th-usOKkP3qdrS_yCeA
Subject: Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-audio-codecs-for-interop
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Jul 2014 00:44:30 -0000

I don't follow the comment about not wanting to spend working group time on
this. The aim is to provide an informational document which will provide
guidance on enhancing audio interoperability for WebRTC. This seems a
relevant activity to me, in the rtcweb WG. Of course if some individuals
don't want to work on it, that's their prerogative.


...Paul

>-----Original Message-----
>From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Andrew Allen
>Sent: Thursday, July 24, 2014 11:14 PM
>To: martin.thomson@gmail.com; TurnerS@ieca.com
>Cc: rtcweb@ietf.org
>Subject: Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-
>audio-codecs-for-interop
>
>
>I am with Martin on this.
>
>Have it as an individual draft and AD sponsored. Its basically as I
>understand it an informational summary of the reality in existing
>deployments. So this isn't reallly the work of the RTCweb WG - in fact
>is relevant (for as long as its information is up to date) also for work
>in RAI groups other than RTCweb too.
>
>Andrew
>
>----- Original Message -----
>From: Martin Thomson [mailto:martin.thomson@gmail.com]
>Sent: Thursday, July 24, 2014 05:10 PM Eastern Standard Time
>To: Sean Turner 
>Cc: rtcweb@ietf.org 
>Subject: Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-
>audio-codecs-for-interop
>
>On 24 July 2014 12:50, Sean Turner  wrote:
>> At the RTCWEB session on Thursday there was support for adoption of
>draft-proust-rtcweb-audio-codecs-for-interop as an informational WG
>draft.  If you do not support adoption of this draft as a WG draft
>please respond to this email by August 1st.  Please also indicate why
>you do not support WG adoption.
>
>Do we anticipate this draft having a material impact on what
>people/implementations do?  Otherwise, I think that I'm against spending
>working group time on this.
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb


From nobody Sun Jul 27 17:46:09 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76E01B27CF for ; Sun, 27 Jul 2014 17:46:06 -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, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dfi8gHukK_05 for ; Sun, 27 Jul 2014 17:46:04 -0700 (PDT)
Received: from BLU004-OMC3S11.hotmail.com (blu004-omc3s11.hotmail.com [65.55.116.86]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7340C1B27CD for ; Sun, 27 Jul 2014 17:46:04 -0700 (PDT)
Received: from BLU436-SMTP187 ([65.55.116.73]) by BLU004-OMC3S11.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712);  Sun, 27 Jul 2014 17:46:04 -0700
X-TMN: [1LbptSiDF0Tx+zrPONtn3Mf49xDS68xY]
X-Originating-Email: [coverdale@sympatico.ca]
Message-ID: 
Received: from PaulNewPC ([74.15.62.229]) by smtphm.sympatico.ca over TLS secured channel with Microsoft SMTPSVC(8.0.9200.16384);  Sun, 27 Jul 2014 17:46:03 -0700
From: Paul Coverdale 
To: 
References: <2184C33E-F1E0-4B31-BC59-6AA11260E1EF@ieca.com>  <53D1E2F2.5060803@mozilla.com>
In-Reply-To: <53D1E2F2.5060803@mozilla.com>
Date: Sun, 27 Jul 2014 20:45:52 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac+nxH0FSVogfqiCQGm5a4szS3GmSwCM7SFA
Content-Language: en-us
X-OriginalArrivalTime: 28 Jul 2014 00:46:03.0318 (UTC) FILETIME=[4EEF9D60:01CFA9FD]
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/SuS0fa3CyXqp3QZiplFqZvxcmnY
Subject: Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-audio-codecs-for-interop
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Jul 2014 00:46:06 -0000

The point of having this as a separate informational document, distinct from
draft-ietf-rtcweb-audio, is to allow for easier update if necessary, as new
codecs become available.

...Paul

>-----Original Message-----
>From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Jean-Marc
>Valin
>Sent: Friday, July 25, 2014 12:54 AM
>To: Bernard Aboba; Sean Turner
>Cc: rtcweb@ietf.org
>Subject: Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-
>audio-codecs-for-interop
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I also do not support adoption of the draft. I agree with the reasons
>stated by Bernard, but I also think that a separate codec document is a
>bad idea in general, regardless of its content. As new codecs get
>adopted and included in non-IETF contexts, the contents would soon be
>outdated.
>
>	Jean-Marc
>
>On 24/07/14 04:18 PM, Bernard Aboba wrote:
>> I do not support adoption of the draft in its current form, for the
>> following reasons:
>>
>> a. The draft only currently covers AMR-WB, AMR and G.722.  Since the
>> AMR codecs generally are accessible only through a proprietary
>> "blackbox" API that does not permit WebRTC use without a separate
>> license, these codecs are not currently practical to support in
>> browsers, even in operating systems that support AMR-WB/AMR for other
>> uses.
>>
>> b. The remaining codec (G.722) does not have these issues, and so it
>> could be implemented in browsers.  However, the useful text in this
>> portion of the document is so small that it does not justify creation
>> of yet another document, even a separate one.
>>
>>
>> On Thu, Jul 24, 2014 at 3:50 PM, Sean Turner > > wrote:
>>
>> At the RTCWEB session on Thursday there was support for adoption of
>> draft-proust-rtcweb-audio-codecs-for-interop as an informational WG
>> draft.  If you do not support adoption of this draft as a WG draft
>> please respond to this email by August 1st.  Please also indicate why
>> you do not support WG adoption.
>>
>> spt _______________________________________________ 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
>>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1
>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
>iQEcBAEBAgAGBQJT0eLuAAoJEJ6/8sItn9q9BVYH/jbxk53SF+IV/mGpGpnqUXM9
>VSjlWSQcOBuJoSSUgjPlu3gIaJ+9uTypJXkq/vGYAOE8JSsNeZ3FkORqpsnR4CUX
>PGjNEahtkJN+3XqEAqJLU3mPuy8tLtgE+MUgSOi9iQvMyalxGMjpDg8ksEFyQG6p
>6/HzNGk7qtaA4v/LkuQvTV+OkGA4QfmtZKrwh9syZVZ7tHCBvM/J0dk3TOWoOrJ6
>RelfzBfk8+SWOm1rHBxO9+gDrxx0S8YjqQuVHddWo0sTofJ4is2MS5q1zbn2sN1M
>iauuVTkoePQbcnfUf9py1gYLofYsSkEupzoNstdmeAuJUYaIvLDVi09stNINgzk=
>=bnqu
>-----END PGP SIGNATURE-----
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb


From nobody Sun Jul 27 18:26:03 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72C61B27D7 for ; Sun, 27 Jul 2014 18:26:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKS1qnQCeAu7 for ; Sun, 27 Jul 2014 18:26:00 -0700 (PDT)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45FD01B27D5 for ; Sun, 27 Jul 2014 18:26:00 -0700 (PDT)
Received: by mail-ie0-f182.google.com with SMTP id y20so6006749ier.41 for ; Sun, 27 Jul 2014 18:25:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HdCXrbXh6nXS4oLmKyEWmCY82mD0QhbLrAWPwoOehL0=; b=jDH7TCk/SLjEFx3NRdMNRmZw6eIVvC3dgdmQl6lAV7Ba2OxoWVaVvH3DozAtSaNhBq D8J/oYAp0110Rp1f0ADXB89uZ1Rfpajn99dB8YPLZ+8lBPNxg8t+IpW8ly8qdW24J+Ta qs4CCkjBCXsltgES4g7E1RPNp9gKuW7ympTne1/9Y9RDNdX8RsR4K/CZYQPMAyfET2UO tbqrCW3DfL4jIVvkZoz8saHZUPzzWIsMepi50/odF3oIFjf7bO7nr6nE6t8AdWt+ZF2O zeNXWymjeRysGaZvwEgUxolEOhJKM38ih+lB08208rA5hdqOUG9PHuIvirnJN0jyEB03 HzjA==
X-Received: by 10.42.100.6 with SMTP id y6mr38715311icn.28.1406510759682; Sun, 27 Jul 2014 18:25:59 -0700 (PDT)
Received: from [172.19.131.163] ([12.130.116.65]) by mx.google.com with ESMTPSA id lq10sm21645457igb.22.2014.07.27.18.25.57 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Jul 2014 18:25:58 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Jim Spring 
X-Mailer: iPhone Mail (11D257)
In-Reply-To: 
Date: Sun, 27 Jul 2014 18:25:53 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <4875B498-4318-4ABE-9291-7D5749318609@gmail.com>
References: <2184C33E-F1E0-4B31-BC59-6AA11260E1EF@ieca.com> 
To: Martin Thomson 
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/FgxPHVj5VeocmX9O_l4QEjCIYs4
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-audio-codecs-for-interop
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Jul 2014 01:26:01 -0000

Right now, required codecs per draft-ietf-rtcweb-05 are Opus and G.711.

In terms of making progress in the working group, I don't see how this draft=
 helps us make progress towards the base WebRtc requirements.

I'm against.

-Jim=20

Sent from my iThingy

> On Jul 24, 2014, at 14:10, Martin Thomson  wrote=
:
>=20
>> On 24 July 2014 12:50, Sean Turner  wrote:
>> At the RTCWEB session on Thursday there was support for adoption of draft=
-proust-rtcweb-audio-codecs-for-interop as an informational WG draft.  If yo=
u do not support adoption of this draft as a WG draft please respond to this=
 email by August 1st.  Please also indicate why you do not support WG adopti=
on.
>=20
> Do we anticipate this draft having a material impact on what
> people/implementations do?  Otherwise, I think that I'm against
> spending working group time on this.
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From nobody Mon Jul 28 08:30:15 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C275D1B288E for ; Mon, 28 Jul 2014 08:30:07 -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, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFTs8Bbb7dhr for ; Mon, 28 Jul 2014 08:29:58 -0700 (PDT)
Received: from BLU004-OMC3S18.hotmail.com (blu004-omc3s18.hotmail.com [65.55.116.93]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C11841B288A for ; Mon, 28 Jul 2014 08:29:57 -0700 (PDT)
Received: from BLU436-SMTP67 ([65.55.116.73]) by BLU004-OMC3S18.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712);  Mon, 28 Jul 2014 08:29:57 -0700
X-TMN: [QGsDo+dn2PmexH/LG25G14RoBrdsocn2]
X-Originating-Email: [coverdale@sympatico.ca]
Message-ID: 
Received: from PaulNewPC ([74.15.62.229]) by smtphm.sympatico.ca over TLS secured channel with Microsoft SMTPSVC(8.0.9200.16384);  Mon, 28 Jul 2014 08:29:56 -0700
From: Paul Coverdale 
To: 
References: <2184C33E-F1E0-4B31-BC59-6AA11260E1EF@ieca.com>  <4875B498-4318-4ABE-9291-7D5749318609@gmail.com>
In-Reply-To: <4875B498-4318-4ABE-9291-7D5749318609@gmail.com>
Date: Mon, 28 Jul 2014 11:29:55 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac+qAuVC0Zh2taTIQ1Wsq7bN5JEroAAa143w
Content-Language: en-us
X-OriginalArrivalTime: 28 Jul 2014 15:29:56.0081 (UTC) FILETIME=[C8ED0E10:01CFAA78]
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/LLydnUB8OFGqH4j_jOQlGBQqf0A
Subject: Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-audio-codecs-for-interop
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Jul 2014 15:30:07 -0000

This draft isn't about the required codecs for WebRTC. That is already clear
in draft-ietf-rtcweb-05. 

It addresses the point in clause 3:

"If other suitable audio codecs are available for the browser to use, it is
RECOMMENDED that they are also be included in the offer in order to maximize
the possibility to establish the session without the need for audio
transcoding."

The intent is to list a set of optional audio codecs and appropriate
contexts and guidance to use them for increased interoperability.

...Paul


>-----Original Message-----
>From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Jim Spring
>Sent: Sunday, July 27, 2014 9:26 PM
>To: Martin Thomson
>Cc: rtcweb@ietf.org
>Subject: Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-
>audio-codecs-for-interop
>
>Right now, required codecs per draft-ietf-rtcweb-05 are Opus and G.711.
>
>In terms of making progress in the working group, I don't see how this
>draft helps us make progress towards the base WebRtc requirements.
>
>I'm against.
>
>-Jim
>
>Sent from my iThingy
>
>> On Jul 24, 2014, at 14:10, Martin Thomson 
>wrote:
>>
>>> On 24 July 2014 12:50, Sean Turner  wrote:
>>> At the RTCWEB session on Thursday there was support for adoption of
>draft-proust-rtcweb-audio-codecs-for-interop as an informational WG
>draft.  If you do not support adoption of this draft as a WG draft
>please respond to this email by August 1st.  Please also indicate why
>you do not support WG adoption.
>>
>> Do we anticipate this draft having a material impact on what
>> people/implementations do?  Otherwise, I think that I'm against
>> spending working group time on this.
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb


From nobody Mon Jul 28 14:44:07 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE841A0217 for ; Mon, 28 Jul 2014 14:44:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQwb2hWTVBl3 for ; Mon, 28 Jul 2014 14:44:03 -0700 (PDT)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id DCCD41A01D9 for ; Mon, 28 Jul 2014 14:44:02 -0700 (PDT)
Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs210cnc.rim.net with ESMTP/TLS/AES128-SHA; 28 Jul 2014 17:44:01 -0400
Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT102CNC.rim.net ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.03.0174.001; Mon, 28 Jul 2014 17:43:59 -0400
From: Andrew Allen 
To: "coverdale@sympatico.ca" , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] call for adoption: draft-draft-proust-rtcweb-audio-codecs-for-interop
Thread-Index: AQHPp4O7RRt3DNdZ4E2+IDpgyWaWGpuwHeQ5gASDESCAAWoWeQ==
Date: Mon, 28 Jul 2014 21:43:58 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.160.251]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RkNEN9hGhbAchdemMRgXnKhxg3I
Subject: Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-audio-codecs-for-interop
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Jul 2014 21:44:05 -0000

Paul

I view this as=20

A) purely an informational analysis of what codecs other deployments are us=
ing and not normative or specific to the RTCweb work (although I don't have=
 a problem RTCweb docs referencing it informatively).

B) useful outside of RTCweb (I.e SIP, MMUSIC)

Why does this need the overhead of WG review since the main areas of expert=
ise required are from experts in deployments outside RTCweb.

AD sponsored seems a better path to me.

Andrew

----- Original Message -----
From: Paul Coverdale [mailto:coverdale@sympatico.ca]
Sent: Sunday, July 27, 2014 08:44 PM Eastern Standard Time=0A=
To: rtcweb@ietf.org 
Subject: Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-audio-co=
decs-for-interop

I don't follow the comment about not wanting to spend working group time on
this. The aim is to provide an informational document which will provide
guidance on enhancing audio interoperability for WebRTC. This seems a
relevant activity to me, in the rtcweb WG. Of course if some individuals
don't want to work on it, that's their prerogative.


...Paul

>-----Original Message-----
>From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Andrew Allen
>Sent: Thursday, July 24, 2014 11:14 PM
>To: martin.thomson@gmail.com; TurnerS@ieca.com
>Cc: rtcweb@ietf.org
>Subject: Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-
>audio-codecs-for-interop
>
>
>I am with Martin on this.
>
>Have it as an individual draft and AD sponsored. Its basically as I
>understand it an informational summary of the reality in existing
>deployments. So this isn't reallly the work of the RTCweb WG - in fact
>is relevant (for as long as its information is up to date) also for work
>in RAI groups other than RTCweb too.
>
>Andrew
>
>----- Original Message -----
>From: Martin Thomson [mailto:martin.thomson@gmail.com]
>Sent: Thursday, July 24, 2014 05:10 PM Eastern Standard Time
>To: Sean Turner 
>Cc: rtcweb@ietf.org 
>Subject: Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-
>audio-codecs-for-interop
>
>On 24 July 2014 12:50, Sean Turner  wrote:
>> At the RTCWEB session on Thursday there was support for adoption of
>draft-proust-rtcweb-audio-codecs-for-interop as an informational WG
>draft.  If you do not support adoption of this draft as a WG draft
>please respond to this email by August 1st.  Please also indicate why
>you do not support WG adoption.
>
>Do we anticipate this draft having a material impact on what
>people/implementations do?  Otherwise, I think that I'm against spending
>working group time on this.
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb

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


From nobody Mon Jul 28 15:03:10 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC061A008E for ; Mon, 28 Jul 2014 15:02:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-W6htg-yhsE for ; Mon, 28 Jul 2014 15:02:27 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (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 199B41A0080 for ; Mon, 28 Jul 2014 15:02:27 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 2156EE1973550 for ; Mon, 28 Jul 2014 22:02:19 +0000 (GMT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s6SM2MUx014879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 29 Jul 2014 00:02:22 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.71]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 29 Jul 2014 00:02:22 +0200
From: "DRAGE, Keith (Keith)" 
To: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] call for adoption: draft-draft-proust-rtcweb-audio-codecs-for-interop
Thread-Index: AQHPp4O7RRt3DNdZ4E2+IDpgyWaWGpuwHeQ5gASDESCAAWoWeYAABOJQ
Date: Mon, 28 Jul 2014 22:02:22 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B214A96@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References:  
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.41]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/t-MF5wBWZzNkmKCznWm5DI1PN-4
Subject: Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-audio-codecs-for-interop
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Jul 2014 22:02:45 -0000

I think this draft should progress.

How it progresses I do not mind - if the WG chairs in conjunction with Ads =
think it should be WG, then fine, if AD sponsored, then also fine.

Keith=20

> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of=20
> Andrew Allen
> Sent: 28 July 2014 22:44
> To: coverdale@sympatico.ca; rtcweb@ietf.org
> Subject: Re: [rtcweb] call for adoption:=20
> draft-draft-proust-rtcweb-audio-codecs-for-interop
>=20
>=20
> Paul
>=20
> I view this as=20
>=20
> A) purely an informational analysis of what codecs other=20
> deployments are using and not normative or specific to the=20
> RTCweb work (although I don't have a problem RTCweb docs=20
> referencing it informatively).
>=20
> B) useful outside of RTCweb (I.e SIP, MMUSIC)
>=20
> Why does this need the overhead of WG review since the main=20
> areas of expertise required are from experts in deployments=20
> outside RTCweb.
>=20
> AD sponsored seems a better path to me.
>=20
> Andrew
>=20
> ----- Original Message -----
> From: Paul Coverdale [mailto:coverdale@sympatico.ca]
> Sent: Sunday, July 27, 2014 08:44 PM Eastern Standard Time
> To: rtcweb@ietf.org 
> Subject: Re: [rtcweb] call for adoption:=20
> draft-draft-proust-rtcweb-audio-codecs-for-interop
>=20
> I don't follow the comment about not wanting to spend working=20
> group time on this. The aim is to provide an informational=20
> document which will provide guidance on enhancing audio=20
> interoperability for WebRTC. This seems a relevant activity=20
> to me, in the rtcweb WG. Of course if some individuals don't=20
> want to work on it, that's their prerogative.
>=20
>=20
> ...Paul
>=20
> >-----Original Message-----
> >From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of=20
> Andrew Allen
> >Sent: Thursday, July 24, 2014 11:14 PM
> >To: martin.thomson@gmail.com; TurnerS@ieca.com
> >Cc: rtcweb@ietf.org
> >Subject: Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-=20
> >audio-codecs-for-interop
> >
> >
> >I am with Martin on this.
> >
> >Have it as an individual draft and AD sponsored. Its basically as I=20
> >understand it an informational summary of the reality in existing=20
> >deployments. So this isn't reallly the work of the RTCweb WG=20
> - in fact=20
> >is relevant (for as long as its information is up to date) also for=20
> >work in RAI groups other than RTCweb too.
> >
> >Andrew
> >
> >----- Original Message -----
> >From: Martin Thomson [mailto:martin.thomson@gmail.com]
> >Sent: Thursday, July 24, 2014 05:10 PM Eastern Standard Time
> >To: Sean Turner 
> >Cc: rtcweb@ietf.org 
> >Subject: Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-=20
> >audio-codecs-for-interop
> >
> >On 24 July 2014 12:50, Sean Turner  wrote:
> >> At the RTCWEB session on Thursday there was support for adoption of
> >draft-proust-rtcweb-audio-codecs-for-interop as an informational WG=20
> >draft.  If you do not support adoption of this draft as a WG draft=20
> >please respond to this email by August 1st.  Please also=20
> indicate why=20
> >you do not support WG adoption.
> >
> >Do we anticipate this draft having a material impact on what=20
> >people/implementations do?  Otherwise, I think that I'm against=20
> >spending working group time on this.
> >
> >_______________________________________________
> >rtcweb mailing list
> >rtcweb@ietf.org
> >https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >_______________________________________________
> >rtcweb mailing list
> >rtcweb@ietf.org
> >https://www.ietf.org/mailman/listinfo/rtcweb
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> =


From nobody Thu Jul 31 06:50:58 2014
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C041A0020 for ; Thu, 31 Jul 2014 06:50:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.898
X-Spam-Level: 
X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=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 x2f1Rw-zU-Gi for ; Thu, 31 Jul 2014 06:50:52 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB8831B2819 for ; Thu, 31 Jul 2014 06:50:51 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id E231A2DC775; Thu, 31 Jul 2014 15:50:49 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id C257827C20F; Thu, 31 Jul 2014 15:50:49 +0200 (CEST)
Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Thu, 31 Jul 2014 15:50:49 +0200
From: 
To: 'Justin Uberti' , 'Bernard Aboba' 
Thread-Topic: [rtcweb] call for adoption: draft-draft-proust-rtcweb-audio-codecs-for-interop
Thread-Index: AQHPp3x9364MOWe3hUe2R9mbd0o1T5uvlKWAgAqevIA=
Date: Thu, 31 Jul 2014 13:50:48 +0000
Message-ID: <3430_1406814649_53DA49B9_3430_1615_1_2842AD9A45C83B44B57635FD4831E60A0C17D7D9@PEXCVZYM14.corporate.adroot.infra.ftgroup>
References: <2184C33E-F1E0-4B31-BC59-6AA11260E1EF@ieca.com>  
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.4]
Content-Type: multipart/alternative; boundary="_000_2842AD9A45C83B44B57635FD4831E60A0C17D7D9PEXCVZYM14corpo_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.100319
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1KgixVguGNv3JVNIvtV3UM4eacE
Cc: "'rtcweb@ietf.org'" 
Subject: Re: [rtcweb] call for adoption: draft-draft-proust-rtcweb-audio-codecs-for-interop
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 13:50:58 -0000

--_000_2842AD9A45C83B44B57635FD4831E60A0C17D7D9PEXCVZYM14corpo_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Pj4gdGhlcmVmb3JlIGEgZG9jdW1lbnQgdGhhdCByZWNvbW1lbmRzIHN1cHBvcnQgb2YgdGhlc2Ug
Y29kZWNzIHdpdGhvdXQgYWRkcmVzc2luZyB0aGUgYXNzb2NpYXRlZCBpc3N1ZXMgaXMgbm90IHN1
aXRhYmxlIGZvciBhZG9wdGlvbi4NCg0KVGhlIGN1cnJlbnQgV2ViUlRDIGF1ZGlvIGRyYWZ0IGFs
cmVhZHkgcmVjb21tZW5kcyB0aGUgc3VwcG9ydCBvZiAiYXZhaWxhYmxlIiBjb2RlY3MgdG8gYWRk
cmVzcyB0aGUgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZQ0KSWYgb3RoZXIgc3VpdGFibGUgYXVkaW8g
Y29kZWNzIGFyZSBhdmFpbGFibGUgZm9yIHRoZSBicm93c2VyIHRvIHVzZSwgaXQgaXMgUkVDT01N
RU5ERUQgdGhhdCB0aGV5IGFyZSBhbHNvIGJlIGluY2x1ZGVkIGluIHRoZSBvZmZlciBpbiBvcmRl
ciB0byBtYXhpbWl6ZSB0aGUgcG9zc2liaWxpdHkgdG8gZXN0YWJsaXNoIHRoZSBzZXNzaW9uIHdp
dGhvdXQgdGhlIG5lZWQgZm9yIGF1ZGlvIHRyYW5zY29kaW5nLg0KVGhlIHB1cnBvc2Ugb2YgdGhp
cyBhZGRpdGlvbmFsIGRyYWZ0IGlzIG9ubHkgdG8gY29tcGxlbWVudCB0aGlzIHN0YXRlbWVudCBh
bmQgY2FwdHVyZSBhbGwgdGhlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gdXNlZnVsIHRvIGV4dGVu
ZCB0aGUgV2ViUlRDIGludGVyb3BlcmFiaWxpdHkgdG8gc29tZSB3ZWxsIGlkZW50aWZpZWQgdXNl
IGNhc2VzIGluY2x1ZGluZyBzb21lIHJlZmVyZW5jZSBhbmQgZ3VpZGFuY2Ugb24gaG93IHRvIGlt
cGxlbWVudCB0aGVzZSBjb2RlY3MgZm9yIGludGVyb3BlcmFiaWxpdHkuDQpUaGUgcmVhc29uIGZv
ciBoYXZpbmcgYW4gaW5mb3JtYXRpb25hbCBzZXBhcmF0ZSBkcmFmdCBpcyB0byBrZWVwIHRoZSBh
dWRpbyBzcGVjaWZpY2F0aW9uIGZvY3VzZWQgb24gbWFuZGF0b3J5IGF1ZGlvIGNvZGVjcywgbm90
IGNvbmZ1c2UgdGhlIGlzc3VlIGFuZCBob3BlZnVsbHkgbWFrZSB0aGlzIHByb3Bvc2FsIGFjY2Vw
dGFibGUgZm9yIGFsbC4NCg0KDQo+PlRoZSBkcmFmdCBvbmx5IGN1cnJlbnRseSBjb3ZlcnMgQU1S
LVdCLCBBTVIgYW5kIEcuNzIyDQoNCkl0IGlzIG5vdCB0aGUgaW50ZW50IG9mIHRoZSBkcmFmdCB0
byBiZSBsaW1pdGVkIHRvIGFueSBzcGVjaWZpYyBjb2RlY3MgYnV0IGp1c3QgdG8gaWRlbnRpZnkg
YWxsIGNvZGVjcyB0aGF0IG1heSBiZSByZWxldmFudCBmb3IgdXNhZ2Ugd2l0aCBXZWJSVEMgdGVj
aG5vbG9neS4gIFRoZSBEcmFmdCBjYW4gcHJvZ3Jlc3MgYXMgYSBXRyBEcmFmdCB3aXRoIG90aGVy
IHJlbGV2YW50IGNvZGVjcyBhZGRlZCBpZiBuZWVkZWQuDQoNCg0KPj4gU2luY2UgdGhlIEFNUiBj
b2RlY3MgZ2VuZXJhbGx5IGFyZSBhY2Nlc3NpYmxlIG9ubHkgdGhyb3VnaCBhIHByb3ByaWV0YXJ5
ICJibGFja2JveCIgQVBJIHRoYXQgZG9lcyBub3QgcGVybWl0IFdlYlJUQyB1c2Ugd2l0aG91dCBh
IHNlcGFyYXRlIGxpY2Vuc2UsIHRoZXNlIGNvZGVjcyBhcmUgbm90IGN1cnJlbnRseSBwcmFjdGlj
YWwgdG8gc3VwcG9ydCBpbiBicm93c2VycywgZXZlbiBpbiBvcGVyYXRpbmcgc3lzdGVtcyB0aGF0
IHN1cHBvcnQgQU1SLVdCL0FNUiBmb3Igb3RoZXIgdXNlcy4NCg0KVGhlcmUgaXMgY3VycmVudGx5
IGEgY2xlYXIgYW5kIGluY3JlYXNpbmcgdHJlbmQgYW5kIHJlbGF0ZWQgd29ya3MgdG8gb3BlbiBB
UElzIG9uIGRldmljZXMgdG8gZ2l2ZSBhY2Nlc3MgdG8gaGFyZHdhcmUgY29kZWNzLiBJdCBpcyBu
b3QgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoaXMgR3JvdXAgdG8gd29yayBvbiB0aGlzIGJ1dCBp
dCBpcyBpbiB0aGUgaW50ZXJlc3Qgb2YgV2ViUlRDIHN0YW5kYXJkIHRvIHRha2UgdGhpcyBpbnRv
IGNvbnNpZGVyYXRpb24gYW5kIHNob3cgc29tZSBvcGVubmVzcyB0byBvdGhlciBjb2RlY3Mgd2hl
cmUgbmVlZGVkLiBXZSBjYW4gdGhlbiBhbnRpY2lwYXRlIHNvbWUgcHJvZ3Jlc3MgaW4gdGhlIG9w
ZW5uZXNzIGFuZCBzdGFuZGFyZGl6YXRpb24gb2YgImNvZGVjcyIgQVBJcyBvbiBkZXZpY2Vz4oCm
DQoNCkFzIGEgY29uY2x1c2lvbiBhbmQgcmVjb21tZW5kYXRpb24gSSB3b3VsZCBzYXkgdGhhdCBh
ZG9wdGluZyB0aGUgZHJhZnQgYXMgYSBXRyBEcmFmdCB3b3VsZCBiZSBncmVhdCBmb3IgYWxsIHdo
byBjYXJlIGFib3V0IGludGVyb3AgdXNlIGNhc2VzIHdpdGhvdXQgYW55IGltcGFjdCBvbiBjdXJy
ZW50IFdlYlJUQyBzcGVjaWZpY2F0aW9uIGFuZCB1c2UgY2FzZXMgcmVseWluZyBvbiBPUFVTIGFu
ZCBHLjcxMSBtYW5kYXRvcnkgY29kZWNzDQoNClN0w6lwaGFuZQ0KDQoNCkRlIDogcnRjd2ViIFtt
YWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSnVzdGluIFViZXJ0
aQ0KRW52b3nDqSA6IGpldWRpIDI0IGp1aWxsZXQgMjAxNCAyMzowMg0Kw4AgOiBCZXJuYXJkIEFi
b2JhDQpDYyA6IHJ0Y3dlYkBpZXRmLm9yZw0KT2JqZXQgOiBSZTogW3J0Y3dlYl0gY2FsbCBmb3Ig
YWRvcHRpb246IGRyYWZ0LWRyYWZ0LXByb3VzdC1ydGN3ZWItYXVkaW8tY29kZWNzLWZvci1pbnRl
cm9wDQoNCkkgYWdyZWUgdGhhdCBpdCBpcyBjdXJyZW50bHkgaW1wcmFjdGljYWwgdG8gc3VwcG9y
dCBBTVIvQU1SLVdCIGluIGJyb3dzZXJzLCBhbmQgdGhlcmVmb3JlIGEgZG9jdW1lbnQgdGhhdCBy
ZWNvbW1lbmRzIHN1cHBvcnQgb2YgdGhlc2UgY29kZWNzIHdpdGhvdXQgYWRkcmVzc2luZyB0aGUg
YXNzb2NpYXRlZCBpc3N1ZXMgaXMgbm90IHN1aXRhYmxlIGZvciBhZG9wdGlvbi4NCg0KSSBoYXZl
IG5vIGlzc3VlcyB3aXRoIHRoZSByZWNvbW1lbmRhdGlvbiBvZiBHLjcyMi4NCg0KT24gVGh1LCBK
dWwgMjQsIDIwMTQgYXQgNDoxOCBQTSwgQmVybmFyZCBBYm9iYSA8YmVybmFyZC5hYm9iYUBnbWFp
bC5jb208bWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPj4gd3JvdGU6DQpJIGRvIG5vdCBz
dXBwb3J0IGFkb3B0aW9uIG9mIHRoZSBkcmFmdCBpbiBpdHMgY3VycmVudCBmb3JtLCBmb3IgdGhl
IGZvbGxvd2luZyByZWFzb25zOg0KDQphLiBUaGUgZHJhZnQgb25seSBjdXJyZW50bHkgY292ZXJz
IEFNUi1XQiwgQU1SIGFuZCBHLjcyMi4gIFNpbmNlIHRoZSBBTVIgY29kZWNzIGdlbmVyYWxseSBh
cmUgYWNjZXNzaWJsZSBvbmx5IHRocm91Z2ggYSBwcm9wcmlldGFyeSAiYmxhY2tib3giIEFQSSB0
aGF0IGRvZXMgbm90IHBlcm1pdCBXZWJSVEMgdXNlIHdpdGhvdXQgYSBzZXBhcmF0ZSBsaWNlbnNl
LCB0aGVzZSBjb2RlY3MgYXJlIG5vdCBjdXJyZW50bHkgcHJhY3RpY2FsIHRvIHN1cHBvcnQgaW4g
YnJvd3NlcnMsIGV2ZW4gaW4gb3BlcmF0aW5nIHN5c3RlbXMgdGhhdCBzdXBwb3J0IEFNUi1XQi9B
TVIgZm9yIG90aGVyIHVzZXMuDQoNCmIuIFRoZSByZW1haW5pbmcgY29kZWMgKEcuNzIyKSBkb2Vz
IG5vdCBoYXZlIHRoZXNlIGlzc3VlcywgYW5kIHNvIGl0IGNvdWxkIGJlIGltcGxlbWVudGVkIGlu
IGJyb3dzZXJzLiAgSG93ZXZlciwgdGhlIHVzZWZ1bCB0ZXh0IGluIHRoaXMgcG9ydGlvbiBvZiB0
aGUgZG9jdW1lbnQgaXMgc28gc21hbGwgdGhhdCBpdCBkb2VzIG5vdCBqdXN0aWZ5IGNyZWF0aW9u
IG9mIHlldCBhbm90aGVyIGRvY3VtZW50LCBldmVuIGEgc2VwYXJhdGUgb25lLg0KDQpPbiBUaHUs
IEp1bCAyNCwgMjAxNCBhdCAzOjUwIFBNLCBTZWFuIFR1cm5lciA8VHVybmVyU0BpZWNhLmNvbTxt
YWlsdG86VHVybmVyU0BpZWNhLmNvbT4+IHdyb3RlOg0KQXQgdGhlIFJUQ1dFQiBzZXNzaW9uIG9u
IFRodXJzZGF5IHRoZXJlIHdhcyBzdXBwb3J0IGZvciBhZG9wdGlvbiBvZiBkcmFmdC1wcm91c3Qt
cnRjd2ViLWF1ZGlvLWNvZGVjcy1mb3ItaW50ZXJvcCBhcyBhbiBpbmZvcm1hdGlvbmFsIFdHIGRy
YWZ0LiAgSWYgeW91IGRvIG5vdCBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQgYXMgYSBX
RyBkcmFmdCBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsIGJ5IEF1Z3VzdCAxc3QuICBQbGVh
c2UgYWxzbyBpbmRpY2F0ZSB3aHkgeW91IGRvIG5vdCBzdXBwb3J0IFdHIGFkb3B0aW9uLg0KDQpz
cHQNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3
ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4N
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5n
IGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0KCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3Nh
Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u
cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMg
ZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg
dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl
cgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2lu
dGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRl
cmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdl
IGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2Ug
YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl
ZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBu
b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4K
SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0
aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFz
IGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2Vz
IHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91
LgoK

--_000_2842AD9A45C83B44B57635FD4831E60A0C17D7D9PEXCVZYM14corpo_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7
DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np
emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7
fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp
ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh
dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8
Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX
b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZn
dDsmZ3Q7IHRoZXJlZm9yZSBhIGRvY3VtZW50IHRoYXQgcmVjb21tZW5kcyBzdXBwb3J0IG9mIHRo
ZXNlIGNvZGVjcyB3aXRob3V0IGFkZHJlc3NpbmcgdGhlIGFzc29jaWF0ZWQgaXNzdWVzIGlzIG5v
dCBzdWl0YWJsZSBmb3IgYWRvcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgY3VycmVudCBX
ZWJSVEMgYXVkaW8gZHJhZnQgYWxyZWFkeSByZWNvbW1lbmRzIHRoZSBzdXBwb3J0IG9mICZxdW90
O2F2YWlsYWJsZSZxdW90OyBjb2RlY3MgdG8gYWRkcmVzcyB0aGUgaW50ZXJvcGVyYWJpbGl0eSBp
c3N1ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPklm
IG90aGVyIHN1aXRhYmxlIGF1ZGlvIGNvZGVjcyBhcmUgYXZhaWxhYmxlIGZvciB0aGUgYnJvd3Nl
ciB0byB1c2UsIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgdGhleSBhcmUgYWxzbyBiZSBpbmNsdWRl
ZCBpbiB0aGUgb2ZmZXIgaW4gb3JkZXIgdG8gbWF4aW1pemUgdGhlIHBvc3NpYmlsaXR5IHRvIGVz
dGFibGlzaCB0aGUNCiBzZXNzaW9uIHdpdGhvdXQgdGhlIG5lZWQgZm9yIGF1ZGlvIHRyYW5zY29k
aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIj5UaGUgcHVycG9zZSBvZiB0aGlzIGFkZGl0aW9uYWwgZHJhZnQgaXMgb25seSB0
byBjb21wbGVtZW50IHRoaXMgc3RhdGVtZW50IGFuZCBjYXB0dXJlIGFsbCB0aGUgYWRkaXRpb25h
bCBpbmZvcm1hdGlvbiB1c2VmdWwgdG8gZXh0ZW5kIHRoZSBXZWJSVEMgaW50ZXJvcGVyYWJpbGl0
eSB0byBzb21lIHdlbGwgaWRlbnRpZmllZCB1c2UgY2FzZXMgaW5jbHVkaW5nIHNvbWUgcmVmZXJl
bmNlDQogYW5kIGd1aWRhbmNlIG9uIGhvdyB0byBpbXBsZW1lbnQgdGhlc2UgY29kZWNzIGZvciBp
bnRlcm9wZXJhYmlsaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgcmVhc29uIGZvciBoYXZpbmcgYW4gaW5mb3JtYXRp
b25hbCBzZXBhcmF0ZSBkcmFmdCBpcyB0byBrZWVwIHRoZSBhdWRpbyBzcGVjaWZpY2F0aW9uIGZv
Y3VzZWQgb24gbWFuZGF0b3J5IGF1ZGlvIGNvZGVjcywgbm90IGNvbmZ1c2UgdGhlIGlzc3VlIGFu
ZCBob3BlZnVsbHkgbWFrZSB0aGlzIHByb3Bvc2FsIGFjY2VwdGFibGUgZm9yIGFsbC48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7Jmd0O1RoZSBkcmFmdCBvbmx5IGN1cnJlbnRs
eSBjb3ZlcnMgQU1SLVdCLCBBTVIgYW5kIEcuNzIyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JdCBpcyBu
b3QgdGhlIGludGVudCBvZiB0aGUgZHJhZnQgdG8gYmUgbGltaXRlZCB0byBhbnkgc3BlY2lmaWMg
Y29kZWNzIGJ1dCBqdXN0IHRvIGlkZW50aWZ5IGFsbCBjb2RlY3MgdGhhdCBtYXkgYmUgcmVsZXZh
bnQgZm9yIHVzYWdlIHdpdGggV2ViUlRDIHRlY2hub2xvZ3kuICZuYnNwO1RoZSBEcmFmdCBjYW4g
cHJvZ3Jlc3MgYXMgYSBXRyBEcmFmdCB3aXRoIG90aGVyIHJlbGV2YW50IGNvZGVjcw0KIGFkZGVk
IGlmIG5lZWRlZC4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyZndDsmbmJz
cDtTaW5jZSB0aGUgQU1SIGNvZGVjcyBnZW5lcmFsbHkgYXJlIGFjY2Vzc2libGUgb25seSB0aHJv
dWdoIGEgcHJvcHJpZXRhcnkgJnF1b3Q7YmxhY2tib3gmcXVvdDsgQVBJIHRoYXQgZG9lcyBub3Qg
cGVybWl0IFdlYlJUQyB1c2Ugd2l0aG91dCBhIHNlcGFyYXRlIGxpY2Vuc2UsIHRoZXNlIGNvZGVj
cyBhcmUgbm90IGN1cnJlbnRseSBwcmFjdGljYWwgdG8gc3VwcG9ydCBpbiBicm93c2VycywgZXZl
bg0KIGluIG9wZXJhdGluZyBzeXN0ZW1zIHRoYXQgc3VwcG9ydCBBTVItV0IvQU1SIGZvciBvdGhl
ciB1c2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlcmUgaXMgY3VycmVudGx5IGEgY2xlYXIgYW5k
IGluY3JlYXNpbmcgdHJlbmQgYW5kIHJlbGF0ZWQgd29ya3MgdG8gb3BlbiBBUElzIG9uIGRldmlj
ZXMgdG8gZ2l2ZSBhY2Nlc3MgdG8gaGFyZHdhcmUgY29kZWNzLiBJdCBpcyBub3QgdGhlIHJlc3Bv
bnNpYmlsaXR5IG9mIHRoaXMgR3JvdXAgdG8gd29yayBvbiB0aGlzIGJ1dCBpdCBpcyBpbiB0aGUg
aW50ZXJlc3Qgb2YgV2ViUlRDDQogc3RhbmRhcmQgdG8gdGFrZSB0aGlzIGludG8gY29uc2lkZXJh
dGlvbiBhbmQgc2hvdyBzb21lIG9wZW5uZXNzIHRvIG90aGVyIGNvZGVjcyB3aGVyZSBuZWVkZWQu
IFdlIGNhbiB0aGVuIGFudGljaXBhdGUgc29tZSBwcm9ncmVzcyBpbiB0aGUgb3Blbm5lc3MgYW5k
IHN0YW5kYXJkaXphdGlvbiBvZiAmcXVvdDtjb2RlY3MmcXVvdDsgQVBJcyBvbiBkZXZpY2Vz4oCm
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIj5BcyBhIGNvbmNsdXNpb24gYW5kIHJlY29tbWVuZGF0aW9uIEkg
d291bGQgc2F5IHRoYXQgYWRvcHRpbmcgdGhlIGRyYWZ0IGFzIGEgV0cgRHJhZnQgd291bGQgYmUg
Z3JlYXQgZm9yIGFsbCB3aG8gY2FyZSBhYm91dCBpbnRlcm9wIHVzZSBjYXNlcyB3aXRob3V0IGFu
eSBpbXBhY3Qgb24gY3VycmVudCBXZWJSVEMgc3BlY2lmaWNhdGlvbiBhbmQgdXNlIGNhc2VzIHJl
bHlpbmcgb24NCiBPUFVTIGFuZCBHLjcxMSBtYW5kYXRvcnkgY29kZWNzIDxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyI+U3TDqXBoYW5lPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij4gcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmdd
DQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiBKdXN0aW4gVWJlcnRpPGJyPg0KPGI+RW52b3nDqSZuYnNw
Ozo8L2I+IGpldWRpIDI0IGp1aWxsZXQgMjAxNCAyMzowMjxicj4NCjxiPsOAJm5ic3A7OjwvYj4g
QmVybmFyZCBBYm9iYTxicj4NCjxiPkNjJm5ic3A7OjwvYj4gcnRjd2ViQGlldGYub3JnPGJyPg0K
PGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW3J0Y3dlYl0gY2FsbCBmb3IgYWRvcHRpb246IGRyYWZ0
LWRyYWZ0LXByb3VzdC1ydGN3ZWItYXVkaW8tY29kZWNzLWZvci1pbnRlcm9wPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB0aGF0IGl0IGlzIGN1cnJlbnRseSBp
bXByYWN0aWNhbCB0byBzdXBwb3J0IEFNUi9BTVItV0IgaW4gYnJvd3NlcnMsIGFuZCB0aGVyZWZv
cmUgYSBkb2N1bWVudCB0aGF0IHJlY29tbWVuZHMgc3VwcG9ydCBvZiB0aGVzZSBjb2RlY3Mgd2l0
aG91dCBhZGRyZXNzaW5nIHRoZSBhc3NvY2lhdGVkIGlzc3VlcyBpcyBub3Qgc3VpdGFibGUgZm9y
IGFkb3B0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
SSBoYXZlIG5vIGlzc3VlcyB3aXRoIHRoZSByZWNvbW1lbmRhdGlvbiBvZiBHLjcyMi48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEp1bCAyNCwgMjAxNCBhdCA0OjE4IFBNLCBCZXJu
YXJkIEFib2JhICZsdDs8YSBocmVmPSJtYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb20iIHRh
cmdldD0iX2JsYW5rIj5iZXJuYXJkLmFib2JhQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG8gbm90IHN1cHBvcnQg
YWRvcHRpb24gb2YgdGhlIGRyYWZ0IGluIGl0cyBjdXJyZW50IGZvcm0sIGZvciB0aGUgZm9sbG93
aW5nIHJlYXNvbnM6Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5hLiBUaGUgZHJhZnQgb25seSBjdXJyZW50bHkgY292ZXJzIEFNUi1XQiwgQU1SIGFu
ZCBHLjcyMi4gJm5ic3A7U2luY2UgdGhlIEFNUiBjb2RlY3MgZ2VuZXJhbGx5IGFyZSBhY2Nlc3Np
YmxlIG9ubHkgdGhyb3VnaCBhIHByb3ByaWV0YXJ5ICZxdW90O2JsYWNrYm94JnF1b3Q7IEFQSSB0
aGF0IGRvZXMgbm90IHBlcm1pdCBXZWJSVEMgdXNlIHdpdGhvdXQgYSBzZXBhcmF0ZSBsaWNlbnNl
LCB0aGVzZSBjb2RlY3MgYXJlIG5vdCBjdXJyZW50bHkNCiBwcmFjdGljYWwgdG8gc3VwcG9ydCBp
biBicm93c2VycywgZXZlbiBpbiBvcGVyYXRpbmcgc3lzdGVtcyB0aGF0IHN1cHBvcnQgQU1SLVdC
L0FNUiBmb3Igb3RoZXIgdXNlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Yi4gVGhlIHJlbWFpbmluZyBjb2RlYyAoRy43MjIpIGRvZXMgbm90
IGhhdmUgdGhlc2UgaXNzdWVzLCBhbmQgc28gaXQgY291bGQgYmUgaW1wbGVtZW50ZWQgaW4gYnJv
d3NlcnMuICZuYnNwO0hvd2V2ZXIsIHRoZSB1c2VmdWwgdGV4dCBpbiB0aGlzIHBvcnRpb24gb2Yg
dGhlIGRvY3VtZW50IGlzIHNvIHNtYWxsIHRoYXQgaXQgZG9lcyBub3QganVzdGlmeSBjcmVhdGlv
biBvZiB5ZXQgYW5vdGhlciBkb2N1bWVudCwgZXZlbg0KIGEgc2VwYXJhdGUgb25lLiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKdWwgMjQsIDIw
MTQgYXQgMzo1MCBQTSwgU2VhbiBUdXJuZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpUdXJuZXJTQGll
Y2EuY29tIiB0YXJnZXQ9Il9ibGFuayI+VHVybmVyU0BpZWNhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXQgdGhlIFJUQ1dFQiBzZXNzaW9u
IG9uIFRodXJzZGF5IHRoZXJlIHdhcyBzdXBwb3J0IGZvciBhZG9wdGlvbiBvZiBkcmFmdC1wcm91
c3QtcnRjd2ViLWF1ZGlvLWNvZGVjcy1mb3ItaW50ZXJvcCBhcyBhbiBpbmZvcm1hdGlvbmFsIFdH
IGRyYWZ0LiAmbmJzcDtJZiB5b3UgZG8gbm90IHN1cHBvcnQgYWRvcHRpb24gb2YgdGhpcyBkcmFm
dCBhcyBhIFdHIGRyYWZ0IHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgYnkgQXVndXN0DQog
MXN0LiAmbmJzcDtQbGVhc2UgYWxzbyBpbmRpY2F0ZSB3aHkgeW91IGRvIG5vdCBzdXBwb3J0IFdH
IGFkb3B0aW9uLjxicj4NCjxicj4NCnNwdDxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fPGJyPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy
ZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5v
cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcnRjd2ViIG1h
aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBp
ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8UFJFPl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIg
ZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRv
aXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1
dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVp
bGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUg
bGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNj
ZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0
ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2ku
CgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp
YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3
Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg
YXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwg
cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMg
YXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi
bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp
ZmllZC4KVGhhbmsgeW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo=

--_000_2842AD9A45C83B44B57635FD4831E60A0C17D7D9PEXCVZYM14corpo_--




On Wed, Jul 23, 2014 at 8:55 AM, Ted =
Hardie <ted.ietf@gmail.com> wrote:



=

On Tue, Jul 22, 2014 at 11:58 PM, Justin Uberti <jubert=
i@google.com> wrote:





I
Since we can't se=
nd a zero-length SCTP message, I propose we add a PPID_EMPTY value or somet=
hing similar to indicate a message with empty content.







=E2=80=8BHowdy,




The keepalive problem seems to be pretty am=
enable to any message, whether of zero length, single byte or something els=
e.=C2=A0 Is the convergence with websockets on zero length important enough=
 to re-open the drafts we just sent to the ADs?




Ted