From magnus.westerlund@ericsson.com Tue Oct 2 08:08:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C81121F8476 for ; Tue, 2 Oct 2012 08:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnnsRgjQvkqf for ; Tue, 2 Oct 2012 08:08:27 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 784CE21F8471 for ; Tue, 2 Oct 2012 08:08:27 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-1b-506b03697544 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 6F.C0.17130.9630B605; Tue, 2 Oct 2012 17:08:25 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 17:08:25 +0200 Message-ID: <506B0367.4000103@ericsson.com> Date: Tue, 2 Oct 2012 17:08:23 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplluLIzCtJLcpLzFFi42KZGfG3VjeTOTvA4MR/KYs5ux4wWaz9187u wOSxZMlPJo8vlz+zBTBFcdmkpOZklqUW6dslcGVcO7mNseAGW8W+qf9ZGhi3sHYxcnJICJhI vD94jA3CFpO4cG89kM3FISRwilHixddNLBDOMkaJM2fWsoBU8QpoS9w4c54JxGYRUJG4174P zGYTsJC4+aMRbJKoQLDEpP1boOoFJU7OfAJmiwioS1x+eIEdxGYWcJTY3bcDrFdYQEfiVusE RogrJCXeTL7JAlGjJzHlagsjhC0v0bx1NjOILQR0Q0NTB+sERoFZSFbMQtIyC0nLAkbmVYzC uYmZOenl5nqpRZnJxcX5eXrFqZsYgUF5cMtvgx2Mm+6LHWKU5mBREufVU93vLySQnliSmp2a WpBaFF9UmpNafIiRiYNTqoFxRVVcyS77u5xXvzv1HPNVYvDa46YRGR2c/domQvx8xPRrhUzV fX1mm0+Y9OQUme96yX/Sq2jeDZO9KQonZoR+DQvSTXUPiZskbiGneGC10OK6TT6fhE7cLlDJ UHVSyyrU85z5VvlDSdnzD7onlr012X54iWeL447nhUlbA29trmc+O72t4LkSS3FGoqEWc1Fx IgCF8z2JGAIAAA== Cc: "rtcweb-chairs@tools.ietf.org" Subject: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 15:08:28 -0000 WG, We chairs like to have input into what you see should be on the Agenda for our two meeting slots in Atlanta. Both document editors/authors and participant are welcome to request or inform the WG or the chairs only about issues that needs to be discussed in the meeting. Two items we chairs believe should be on the agenda are: - Video codec selection - JSEP Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ted.ietf@gmail.com Tue Oct 2 09:25:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1ED21F84D8 for ; Tue, 2 Oct 2012 09:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSMXluD4oQAw for ; Tue, 2 Oct 2012 09:25:29 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6A41121F84DC for ; Tue, 2 Oct 2012 09:25:29 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so7939772vcb.31 for ; Tue, 02 Oct 2012 09:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=AIwGHEZiQkVYGwFuOLHXesV95pMRd+zepWc5eHAwC1w=; b=jDbTKbRSQKlqvCRKy9bAWC5DJeBHp2Q5GRBnqar3SRseHvS5t+gqQ9bznIycCIOaEP thwA7aMRyfTYtpCKWp3+vMSghWxll5bvO9Q2Dm1PbPpQON0S8sHoS/OeWnvdo85hvc/k L5/RoVGGL4kuts9pTkZPqZENwDMhPaRn5TExuA7QMKCOXvze8CPUzO1kRRwcg4pmvclE 5E2j8rqgdToIt6NJk9gCKfU2QroYCPBy99xCBYAyd6qxoMVz7KCW7D6cVGLdkxp/AOdA qyfaIpFgSB9jEWeeC4sSkbUqrtYvCJw473aXeFZR42yCznwftuoR4W/l+fnpUv/FZ7zi usog== MIME-Version: 1.0 Received: by 10.220.238.148 with SMTP id ks20mr6995242vcb.5.1349195128834; Tue, 02 Oct 2012 09:25:28 -0700 (PDT) Received: by 10.58.245.39 with HTTP; Tue, 2 Oct 2012 09:25:28 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Oct 2012 09:25:28 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [rtcweb] Video codec proposals due October 15th, 2012 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 16:25:33 -0000 Just a reminder that this deadline is approaching quickly; please get your drafts in! thanks, Ted Hardie On Thu, Aug 16, 2012 at 10:14 AM, Ted Hardie wrote: > As agreed at the recent meeting, the chairs solicit internet-drafts > naming proposed mandatory-to-implement video codecs or codec sets by > October 15th, 2012. Please include any technical data you believe > supports the choice you are proposing. A non-exhaustive list of data > you may wish to include is found in slides 3-6 of > http://www.ietf.org/proceedings/84/slides/slides-84-rtcweb-4.pptx . > > Discussion based on these will commence immediately upon receipt, > rather than waiting until the October 15th deadline, so early > submission is encouraged. > > regards, > > Ted Hardie From christer.holmberg@ericsson.com Tue Oct 2 11:00:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51C321F84DD for ; Tue, 2 Oct 2012 11:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.111 X-Spam-Level: X-Spam-Status: No, score=-6.111 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUGQAFSHraxc for ; Tue, 2 Oct 2012 11:00:18 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id DA4B521F84F0 for ; Tue, 2 Oct 2012 11:00:17 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-d1-506b2bb0353a Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id DE.7F.17130.0BB2B605; Tue, 2 Oct 2012 20:00:16 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Tue, 2 Oct 2012 20:00:16 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Date: Tue, 2 Oct 2012 20:00:15 +0200 Thread-Topic: JSEP: Relaxing SDP O/A rules? Thread-Index: Ac2gx8YO2FbS6BWgTLSGmCyMIXGpLA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvre4G7ewAg1mTDCzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpN/PxgLDvFVbPoT0MB4k6eLkZNDQsBEYsXMfawQtpjEhXvr 2boYuTiEBE4xShxYvY4ZwpnPKNGy6AZQhoODTcBCovufNkiDiIC6xOWHF9hBbBYBFYmvN+4z gdjCAmoSp18uYoGo0ZaY9fIbK4StJzHzz01mEJtXIFzi5ZXVYPWMQIu/n1oDZjMLiEvcejKf CeIgAYkle84zQ9iiEi8f/2OFqBeVuNO+nhGiPl+i+1knO8RMQYmTM5+wTGAUmoVk1CwkZbOQ lEHEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjMK5iZk56eXmeqlFmcnFxfl5esWpmxiB 0XBwy2+DHYyb7osdYpTmYFES59VT3e8vJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbFsWtff mwaecy9/a9xuPVlm3hO7mLMlYjemLylr4XWKq1sWXSb3qvrZ3HlLnaaXr7lb/VC5XmNmtpnG DP+Mt6c3Nx/iuLnPVzzkl84klsW8O+54iG6TsPoszLLn89Web9vV/itVNv+/H5KqHLxNpHNv 8oE3M45KLfY7/mvKe8ePLyyvMshFqaUpsRRnJBpqMRcVJwIAyXksX1QCAAA= Subject: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 18:00:18 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, One of the arguments for the Microsoft API proposal was regarding the JSEP = usage of SDP Offer/Answer. There has also been ideas about JSEP "relaxing" the SDP O/A rules. What is the current status of that? Is the intention to "relax" something? Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
One of the arguments for the Microsoft API proposal w= as regarding the JSEP usage of SDP Offer/Answer.
 
There has also been ideas about JSEP "relaxing&q= uot; the SDP O/A rules.
 
What is the current status of that? Is the intention = to "relax" something?
 
Regards,
 
Christer
 
 --_000_7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1ESESSCMS0356e_-- From Markus.Isomaki@nokia.com Tue Oct 2 11:30:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E917D21F857E for ; Tue, 2 Oct 2012 11:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PS8Cmbz1qqAk for ; Tue, 2 Oct 2012 11:30:30 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCA021F8543 for ; Tue, 2 Oct 2012 11:30:29 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92IUQH0029156; Tue, 2 Oct 2012 21:30:27 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Oct 2012 21:30:26 +0300 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.5]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.02.0309.003; Tue, 2 Oct 2012 20:30:25 +0200 From: To: , Thread-Topic: [rtcweb] Video codec proposals due October 15th, 2012 Thread-Index: AQHNoLtUIKedTdT5iU+iT3jOpQ5mSpemVBjg Date: Tue, 2 Oct 2012 18:30:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.174.233] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Oct 2012 18:30:26.0511 (UTC) FILETIME=[FE1385F0:01CDA0CB] X-Nokia-AV: Clean Subject: Re: [rtcweb] Video codec proposals due October 15th, 2012 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 18:30:31 -0000 Hi, Why do you want to receive these proposals as drafts instead of just on the= mailing list? I have a proposal/opinion and a few simple arguments for it,= but writing a draft about it seems like a lot of overhead.=20 Markus=20 >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of ext Ted Hardie >Sent: 02 October, 2012 19:25 >To: rtcweb@ietf.org >Subject: Re: [rtcweb] Video codec proposals due October 15th, 2012 > >Just a reminder that this deadline is approaching quickly; please get your >drafts in! > >thanks, > >Ted Hardie > > >On Thu, Aug 16, 2012 at 10:14 AM, Ted Hardie wrote: >> As agreed at the recent meeting, the chairs solicit internet-drafts >> naming proposed mandatory-to-implement video codecs or codec sets by >> October 15th, 2012. Please include any technical data you believe >> supports the choice you are proposing. A non-exhaustive list of data >> you may wish to include is found in slides 3-6 of >> http://www.ietf.org/proceedings/84/slides/slides-84-rtcweb-4.pptx . >> >> Discussion based on these will commence immediately upon receipt, >> rather than waiting until the October 15th deadline, so early >> submission is encouraged. >> >> regards, >> >> Ted Hardie >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From kaiduanx@gmail.com Tue Oct 2 11:56:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3B321F8587 for ; Tue, 2 Oct 2012 11:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtAWWVk-AWEl for ; Tue, 2 Oct 2012 11:56:52 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 28B9E21F8574 for ; Tue, 2 Oct 2012 11:56:52 -0700 (PDT) Received: by oagn5 with SMTP id n5so7929164oag.31 for ; Tue, 02 Oct 2012 11:56:51 -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=epzylaNAIraC3km4ZLQ33JkJQIl0iZcYp7oqr7rOe08=; b=GtRJeBE1fNnLCioggsGG9XOXJf4CPzDeGaVlJLKw59MzMe/OGdy/obk3NZXgC+3KVV wjpL4kZIMWFoNEWQXEC3V142ZyjGbaBvjh6OghbXDaV9NczGjbWG0yHBBVyogvq0G+k7 F5K5PkplJ0Fh1pGR8Q/B7XkYKFT0Nort8HXsIRsPJi4+BpYyFwvWL/IW+y25ANgZBZYb 13JwelIIJVRLBLI0VJGNbxfuqIlj0+i45qhEoDjIHnHgbVErtF8xj6RBNM8nn6le09iE TDDLrVi9i5eS2fUccclloqf0f16tBrI6WdpFEQ6zqWIL7MY/LCux/aEmVBAh9zHEGE8z IJRA== MIME-Version: 1.0 Received: by 10.60.8.229 with SMTP id u5mr14745499oea.64.1349204211806; Tue, 02 Oct 2012 11:56:51 -0700 (PDT) Received: by 10.76.23.129 with HTTP; Tue, 2 Oct 2012 11:56:51 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 2 Oct 2012 14:56:51 -0400 Message-ID: From: Kaiduan Xie To: Christer Holmberg Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 18:56:52 -0000 I also have this concern particularly on how to inter-operate with the in-service SIP world which follows the SDP O/A rules? /Kaiduan On Tue, Oct 2, 2012 at 2:00 PM, Christer Holmberg wrote: > > Hi, > > One of the arguments for the Microsoft API proposal was regarding the JSEP > usage of SDP Offer/Answer. > > There has also been ideas about JSEP "relaxing" the SDP O/A rules. > > What is the current status of that? Is the intention to "relax" something? > > Regards, > > Christer > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From martin.thomson@gmail.com Tue Oct 2 11:59:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CD921F8587 for ; Tue, 2 Oct 2012 11:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACfPRf9NsPqE for ; Tue, 2 Oct 2012 11:59:56 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E6E8021F850D for ; Tue, 2 Oct 2012 11:59:55 -0700 (PDT) Received: by lbok13 with SMTP id k13so6091989lbo.31 for ; Tue, 02 Oct 2012 11:59: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=HDxAxkZ8NYtQogdysfvyg4pf3k+wfs5Uv5ShYiLsmdA=; b=tB/f9pGM8lJZ7IZi+VcKo+spvmW+GuFGEWXXMhoOFYKjdOXnaNH2DpcZv+Nu/cwddE tMie1As992z9/GiJw34xP4aSWZaQD+nsmC48YNIU3BpK9rDNFHsnkdB1X1DnZrwTGr+J qsV8qlto+Y+057dXrgN9DyXvKfxRRzRBh8ZDtfcFq31T08GJbcwI3avopHWW84wYUL07 cfFYl4+Rg3MVro+bAVNnyYY1oKcM6eWE4+YrUusq2xHUkJIk9Aur7G1g9sSMagh0LeEs mih3EnryIF5e3HnFsA1LXaZfPWIP9rzcV0RXcfvHdP081+FTBkj0JLaXlEe3qpUsc4R/ DaHA== MIME-Version: 1.0 Received: by 10.152.106.81 with SMTP id gs17mr15407290lab.2.1349204394815; Tue, 02 Oct 2012 11:59:54 -0700 (PDT) Received: by 10.112.83.2 with HTTP; Tue, 2 Oct 2012 11:59:54 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 2 Oct 2012 11:59:54 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 18:59:56 -0000 On 2 October 2012 11:00, Christer Holmberg wrote: > There has also been ideas about JSEP "relaxing" the SDP O/A rules. JSEP already does that. PRANSWER is probably the most obvious diversion, but it goes deeper. There's a simple view of what JSEP is and it goes a little like this: - SDP provides a description of the session that you are going to create [1] - You need two SDP blobs so that you can get all the non-negotiated parameters like crypto and candidate attributes - setLocalDescription and setRemoteDescription provide a way of matching up two SDP blobs into a complete session description - negotiation is performed outside this machine, and the browser can help you with that in two ways: providing createOffer and createAnswer to build the SDP; and by nudging you with a negotiatedneeded event when it learns of things that necessitate changes. Obviously, it's a little more nuanced than that, but if you take this view, you are more likely to get something to work. --Martin [1] Caveat: PRANSWER adds a layer of complexity to this by shifting part of the session description to the offer rather than the answer From ted.ietf@gmail.com Tue Oct 2 12:02:36 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FA221F85B8 for ; Tue, 2 Oct 2012 12:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mk7zl1IQqc3f for ; Tue, 2 Oct 2012 12:02:35 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2327F21F85B1 for ; Tue, 2 Oct 2012 12:02:35 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so7919249vbb.31 for ; Tue, 02 Oct 2012 12:02: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:date:message-id:subject:from:to :cc:content-type; bh=maa4nJvd6ASw0+iIs+6EaNKLZ3XKRz4zHy7M6b8F7Ic=; b=VsE00ZGdg3z66cN9g0fjRFtaLGyjKPKmu+O72s2jZx8kUGleVsfc30rz5NsCwQ+Ts7 8QMJC2puhuXc1ZdeMdJXV1BlstwnU3H0q0rmxXNN79SQzl2KHEFsA4N3AQyNA6svdFfY zQjRvBMeeytl6BQZm1+mwc7uzdfSygXzHb1pjNifN6Ium+rw2NZBkXrsQ7NCw5/620vf 8x2DD03tDQb0MbMBoM70c1lw3OtefPfba3QlbG0U6wezTjItUFUzRzO+cia9wqkxnozA 9XumK/RhaXLd16A8XyWWKDknB9ucwqVQnrSHK2+sxwvnwEE3COnuaDWgDMTlCRqzmo9v rM/A== MIME-Version: 1.0 Received: by 10.52.175.193 with SMTP id cc1mr8781335vdc.61.1349204554571; Tue, 02 Oct 2012 12:02:34 -0700 (PDT) Received: by 10.58.245.39 with HTTP; Tue, 2 Oct 2012 12:02:34 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Oct 2012 12:02:34 -0700 Message-ID: From: Ted Hardie To: Markus.Isomaki@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Video codec proposals due October 15th, 2012 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 19:02:36 -0000 On Tue, Oct 2, 2012 at 11:30 AM, wrote: > Hi, > > Why do you want to receive these proposals as drafts instead of just on the mailing list? I have a proposal/opinion and a few simple arguments for it, but writing a draft about it seems like a lot of overhead. > > Markus > Sorry that the draft system creates extra overhead, but we think it is useful to make all the proposals parallel, and we believe at least some of them will have technical justifications that would be complicated to include in an email. In particular, why you'd pick a specific profile of a codec with multiple profiles may require contextualizing the different profiles in ways that would be difficult to put into an email. When we have drafts, we are also more likely to get reviews from those who are picking up on our work from grabbing the related drafts. Lastly, if folks need to declare IPR in a proposal, the system is better set up to do so with a draft than an email. Thanks for taking it on despite the overhead, regards, Ted > >>-----Original Message----- >>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >>Of ext Ted Hardie >>Sent: 02 October, 2012 19:25 >>To: rtcweb@ietf.org >>Subject: Re: [rtcweb] Video codec proposals due October 15th, 2012 >> >>Just a reminder that this deadline is approaching quickly; please get your >>drafts in! >> >>thanks, >> >>Ted Hardie >> >> >>On Thu, Aug 16, 2012 at 10:14 AM, Ted Hardie wrote: >>> As agreed at the recent meeting, the chairs solicit internet-drafts >>> naming proposed mandatory-to-implement video codecs or codec sets by >>> October 15th, 2012. Please include any technical data you believe >>> supports the choice you are proposing. A non-exhaustive list of data >>> you may wish to include is found in slides 3-6 of >>> http://www.ietf.org/proceedings/84/slides/slides-84-rtcweb-4.pptx . >>> >>> Discussion based on these will commence immediately upon receipt, >>> rather than waiting until the October 15th deadline, so early >>> submission is encouraged. >>> >>> regards, >>> >>> Ted Hardie >>_______________________________________________ >>rtcweb mailing list >>rtcweb@ietf.org >>https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Wed Oct 3 06:03:17 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB08E21F86DC for ; Wed, 3 Oct 2012 06:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.116 X-Spam-Level: X-Spam-Status: No, score=-6.116 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-BAnJhFzgbM for ; Wed, 3 Oct 2012 06:03:17 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4268C21F86A0 for ; Wed, 3 Oct 2012 06:03:13 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-6b-506c379087ad Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 57.8D.11467.0973C605; Wed, 3 Oct 2012 15:03:12 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 3 Oct 2012 15:03:11 +0200 From: Christer Holmberg To: Martin Thomson Date: Wed, 3 Oct 2012 15:03:10 +0200 Thread-Topic: [rtcweb] JSEP: Relaxing SDP O/A rules? Thread-Index: Ac2g0BxI+mitQkdhQvyzKrKnRWQp4wAlS8zg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585340A7BC848ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvre4E85wAgyuvRC2unfnHaLH2Xzu7 A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXx4nJKQY9HRcPsyYwNjD1uXYycHBICJhJf Ns5jg7DFJC7cWw9kc3EICZxilGjaeY8dwpnPKNHy4DdzFyMHB5uAhUT3P22QBhEBXYlFZx+w g9jMAuoSdxafA7NZBFQkPjw/ADZUWMBYovPzMSaIehOJNTvWsEDYRhLrz31hBLF5BcIlVu77 zwxiCwnMY5To/y4PYnMKBErMfXUCrJ4R6Ljvp9YwQewSl7j1ZD4TxNECEkv2nGeGsEUlXj7+ xwpRLypxp309I0R9vsSzFQ9YIXYJSpyc+YRlAqPoLCSjZiEpm4WkbBbQx8wCmhLrd+lDlChK TOl+yA5ha0i0zpnLjiy+gJF9FaNwbmJmTnq5oV5qUWZycXF+nl5x6iZGYJwd3PJbdwfjqXMi hxilOViUxHm5kvb7CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCcpNjvfsu2+X30aiu2s+75 D1eVPVxhsTknmC3R+/5lqeuGVQHPngQIxizddKl8kiJrz3cDpXjN69dnbfV8mXm8btaEy9Fb S/7MNwxfrsx51ZT3XcnWB9tDUh5Jd9+5P3nyXDdN1pKZIsv0tdwctkz4MVX/+daqk4uuzrv7 fMubF3dWlu/0WvrfR4mlOCPRUIu5qDgRADmopNWBAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 13:03:18 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585340A7BC848ESESSCMS0356e_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkndmUgYmVlbiBsb29raW5nIGF0IHRoZSBPL0Egc3RhdGUgbWFjaGluZSwgYW5kIHRo ZSBhc3NvY2lhdGVkIHByb2NlZHVyZSB0ZXh0LCBpbiBzZWN0aW9uIDQuMiBvZiBkcmFmdC1qc2Vw LCBhbmQgYSBjb3VwbGUgb2YgaXNzdWVzLg0KDQpGaXJzdCwgdGhlIHRleHQgc2F5czoNCg0KICAg ICAgICAiQXMgaW4gW1JGQzMyNjRdLCBhbiBvZmZlcmVyIGNhbiBzZW5kIGFuIG9mZmVyLCBhbmQg dXBkYXRlIGl0IGFzIGxvbmcgYXMgaXQgaGFzIG5vdCBiZWVuIGFuc3dlcmVkLiINCg0KVGhhdCBp cyBub3QgdHJ1ZS4gSW4gb3JkZXIgdG8gdXBkYXRlIGFuIG9mZmVyIChiZWZvcmUgaXQgaGFzIGJl ZW4gYW5zd2VyZWQpLCBvbmUgbmVlZHMgdG8gY2FuY2VsIHRoZSBwcmV2aW91cyBvZmZlci4NCg0K DQpTZWNvbmQsIHRoZSB0ZXh0IHNheXM6DQoNCiAgICAgICAgIkEgZGVzY3JpcHRpb24gdXNlZCBh cyBhICJwcmFuc3dlciIgbWF5IGJlIGFwcGxpZWQgYXMgYSByZXNwb25zZSB0byBhbiAib2ZmZXIi LCBvciBhbiB1cGRhdGUgdG8gYSBwcmV2aW91c2x5IHNlbnQgImFuc3dlciIuIg0KDQpJIGRvbid0 IHVuZGVyc3RhbmQgdGhlIHVwZGF0ZS10by1hLXByZXZpb3VzbHktc2VudC1hbnN3ZXIgdGhpbmcu IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgb25lIHdvdWxkIHVwZGF0ZSBhbiAiYW5zd2VyIiB3aXRo IGEgInByZWFuc3dlciIuDQoNCkFuZCwgdGhlIHN0YXRlIG1hY2hpbmUgZG9lc24ndCBzZWVtIHRv IHN1cHBvcnQgaXQgZWl0aGVyLiBTbywgaWYgZG9uZSwgIHdoYXQgc3RhdGUgd2lsbCBJIGJlIGlu IGFmdGVyIHN1Y2ggYWN0aW9uPyBDYW4gSSB0aGVuIGFsc28gc2VuZCBhIG5ldyAiYW5zd2VyIiwg dG8gdXBkYXRlIHRoZSAicHJlYW5zd2VyIiB0aGF0IHVwZGF0ZWQgdGhlICJhbnN3ZXIiPw0KDQoN ClRoaXJkLCBpcyB0aGVyZSBhIHJlYXNvbiB3aHkgYSBuZXcgIm9mZmVyIiBjYW4ndCBiZSBzZW50 IG9uY2UgaW4gdGhlICJQcmVhbnN3ZXIiIHN0YXRlPw0KDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVy DQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcnRpbiBUaG9t c29uIFttYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tXQ0KU2VudDogMi4gbG9rYWt1dXRh IDIwMTIgMjI6MDANClRvOiBDaHJpc3RlciBIb2xtYmVyZw0KQ2M6IHJ0Y3dlYkBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtydGN3ZWJdIEpTRVA6IFJlbGF4aW5nIFNEUCBPL0EgcnVsZXM/DQoNCk9u IDIgT2N0b2JlciAyMDEyIDExOjAwLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3 cm90ZToNCj4gVGhlcmUgaGFzIGFsc28gYmVlbiBpZGVhcyBhYm91dCBKU0VQICJyZWxheGluZyIg dGhlIFNEUCBPL0EgcnVsZXMuDQoNCkpTRVAgYWxyZWFkeSBkb2VzIHRoYXQuDQoNClBSQU5TV0VS IGlzIHByb2JhYmx5IHRoZSBtb3N0IG9idmlvdXMgZGl2ZXJzaW9uLCBidXQgaXQgZ29lcyBkZWVw ZXIuDQoNClRoZXJlJ3MgYSBzaW1wbGUgdmlldyBvZiB3aGF0IEpTRVAgaXMgYW5kIGl0IGdvZXMg YSBsaXR0bGUgbGlrZSB0aGlzOg0KDQogLSBTRFAgcHJvdmlkZXMgYSBkZXNjcmlwdGlvbiBvZiB0 aGUgc2Vzc2lvbiB0aGF0IHlvdSBhcmUgZ29pbmcgdG8gY3JlYXRlIFsxXQ0KDQogLSBZb3UgbmVl ZCB0d28gU0RQIGJsb2JzIHNvIHRoYXQgeW91IGNhbiBnZXQgYWxsIHRoZSBub24tbmVnb3RpYXRl ZCBwYXJhbWV0ZXJzIGxpa2UgY3J5cHRvIGFuZCBjYW5kaWRhdGUgYXR0cmlidXRlcw0KDQogLSBz ZXRMb2NhbERlc2NyaXB0aW9uIGFuZCBzZXRSZW1vdGVEZXNjcmlwdGlvbiBwcm92aWRlIGEgd2F5 IG9mIG1hdGNoaW5nIHVwIHR3byBTRFAgYmxvYnMgaW50byBhIGNvbXBsZXRlIHNlc3Npb24gZGVz Y3JpcHRpb24NCg0KIC0gbmVnb3RpYXRpb24gaXMgcGVyZm9ybWVkIG91dHNpZGUgdGhpcyBtYWNo aW5lLCBhbmQgdGhlIGJyb3dzZXIgY2FuIGhlbHAgeW91IHdpdGggdGhhdCBpbiB0d28gd2F5czog cHJvdmlkaW5nIGNyZWF0ZU9mZmVyIGFuZCBjcmVhdGVBbnN3ZXIgdG8gYnVpbGQgdGhlIFNEUDsg YW5kIGJ5IG51ZGdpbmcgeW91IHdpdGggYSBuZWdvdGlhdGVkbmVlZGVkIGV2ZW50IHdoZW4gaXQg bGVhcm5zIG9mIHRoaW5ncyB0aGF0IG5lY2Vzc2l0YXRlIGNoYW5nZXMuDQoNCk9idmlvdXNseSwg aXQncyBhIGxpdHRsZSBtb3JlIG51YW5jZWQgdGhhbiB0aGF0LCBidXQgaWYgeW91IHRha2UgdGhp cyB2aWV3LCB5b3UgYXJlIG1vcmUgbGlrZWx5IHRvIGdldCBzb21ldGhpbmcgdG8gd29yay4NCg0K LS1NYXJ0aW4NCg0KWzFdIENhdmVhdDogUFJBTlNXRVIgYWRkcyBhIGxheWVyIG9mIGNvbXBsZXhp dHkgdG8gdGhpcyBieSBzaGlmdGluZyBwYXJ0IG9mIHRoZSBzZXNzaW9uIGRlc2NyaXB0aW9uIHRv IHRoZSBvZmZlciByYXRoZXIgdGhhbiB0aGUgYW5zd2VyDQoNCg== --_000_7F2072F1E0DE894DA4B517B93C6A0585340A7BC848ESESSCMS0356e_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpLCBzYW5zLXNlcmlmIiBzaXplPSIy Ij4NCjxkaXY+SGksPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JJ3ZlIGJlZW4gbG9v a2luZyBhdCB0aGUgTy9BIHN0YXRlIG1hY2hpbmUsIGFuZCB0aGUgYXNzb2NpYXRlZCBwcm9jZWR1 cmUgdGV4dCwgaW4gc2VjdGlvbiA0LjIgb2YgZHJhZnQtanNlcCwgYW5kIGEgY291cGxlIG9mIGlz c3Vlcy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PjxiPkZpcnN0PC9iPiwgdGhlIHRl eHQgc2F5czo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtBcyBpbiBbUkZDMzI2NF0sIGFuIG9mZmVy ZXIgY2FuIHNlbmQgYW4gb2ZmZXIsIGFuZCB1cGRhdGUgaXQgYXMgbG9uZyBhcyBpdCBoYXMgbm90 IGJlZW4gYW5zd2VyZWQuJnF1b3Q7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGF0 IGlzIG5vdCB0cnVlLiBJbiBvcmRlciB0byB1cGRhdGUgYW4gb2ZmZXIgKGJlZm9yZSBpdCBoYXMg YmVlbiBhbnN3ZXJlZCksIG9uZSBuZWVkcyB0byBjYW5jZWwgdGhlIHByZXZpb3VzIG9mZmVyLjwv ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PjxiPlNlY29u ZDwvYj4sIHRoZSB0ZXh0IHNheXM6PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7QSBkZXNjcmlwdGlv biB1c2VkIGFzIGEgJnF1b3Q7cHJhbnN3ZXImcXVvdDsgbWF5IGJlIGFwcGxpZWQgYXMgYSByZXNw b25zZSB0byBhbiAmcXVvdDtvZmZlciZxdW90Oywgb3IgYW4gdXBkYXRlIHRvIGEgcHJldmlvdXNs eSBzZW50ICZxdW90O2Fuc3dlciZxdW90Oy4mcXVvdDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+ DQo8ZGl2PkkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgdXBkYXRlLXRvLWEtcHJldmlvdXNseS1zZW50 LWFuc3dlciB0aGluZy4gSSBkb24ndCB1bmRlcnN0YW5kIHdoeSBvbmUgd291bGQgdXBkYXRlIGFu ICZxdW90O2Fuc3dlciZxdW90OyB3aXRoIGEgJnF1b3Q7cHJlYW5zd2VyJnF1b3Q7LiA8L2Rpdj4N CjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkFuZCwgdGhlIHN0YXRlIG1hY2hpbmUgZG9lc24ndCBz ZWVtIHRvIHN1cHBvcnQgaXQgZWl0aGVyLiBTbywgaWYgZG9uZSwmbmJzcDsgd2hhdCBzdGF0ZSB3 aWxsIEkgYmUgaW4gYWZ0ZXIgc3VjaCBhY3Rpb24/IENhbiBJIHRoZW4gYWxzbyBzZW5kIGEgbmV3 ICZxdW90O2Fuc3dlciZxdW90OywgdG8gdXBkYXRlIHRoZSAmcXVvdDtwcmVhbnN3ZXImcXVvdDsg dGhhdCB1cGRhdGVkIHRoZSAmcXVvdDthbnN3ZXImcXVvdDs/PC9kaXY+DQo8ZGl2PiZuYnNwOzwv ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+PGI+VGhpcmQ8L2I+LCBpcyB0aGVyZSBhIHJl YXNvbiB3aHkgYSBuZXcgJnF1b3Q7b2ZmZXImcXVvdDsgY2FuJ3QgYmUgc2VudCBvbmNlIGluIHRo ZSAmcXVvdDtQcmVhbnN3ZXImcXVvdDsgc3RhdGU/PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0K PGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+UmVnYXJkcyw8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+ DQo8ZGl2PkNocmlzdGVyPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp dj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp dj4NCjxkaXY+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQoNCkZyb206IE1hcnRpbiBU aG9tc29uIFs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIj5tYWlsdG86 bWFydGluLnRob21zb25AZ21haWwuY29tPC9hPl0NCjxicj4NCg0KU2VudDogMi4gbG9rYWt1dXRh IDIwMTIgMjI6MDA8YnI+DQoNClRvOiBDaHJpc3RlciBIb2xtYmVyZzxicj4NCg0KQ2M6IHJ0Y3dl YkBpZXRmLm9yZzxicj4NCg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIEpTRVA6IFJlbGF4aW5nIFNE UCBPL0EgcnVsZXM/PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5PbiAyIE9jdG9iZXIg MjAxMiAxMTowMCwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwv YT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGRpdj4mZ3Q7IFRoZXJlIGhhcyBhbHNvIGJlZW4gaWRlYXMg YWJvdXQgSlNFUCAmcXVvdDtyZWxheGluZyZxdW90OyB0aGUgU0RQIE8vQSBydWxlcy48L2Rpdj4N CjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkpTRVAgYWxyZWFkeSBkb2VzIHRoYXQuPC9kaXY+DQo8 ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5QUkFOU1dFUiBpcyBwcm9iYWJseSB0aGUgbW9zdCBvYnZp b3VzIGRpdmVyc2lvbiwgYnV0IGl0IGdvZXMgZGVlcGVyLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp dj4NCjxkaXY+VGhlcmUncyBhIHNpbXBsZSB2aWV3IG9mIHdoYXQgSlNFUCBpcyBhbmQgaXQgZ29l cyBhIGxpdHRsZSBsaWtlIHRoaXM6PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4gLSBT RFAgcHJvdmlkZXMgYSBkZXNjcmlwdGlvbiBvZiB0aGUgc2Vzc2lvbiB0aGF0IHlvdSBhcmUgZ29p bmcgdG8gY3JlYXRlIFsxXTwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+IC0gWW91IG5l ZWQgdHdvIFNEUCBibG9icyBzbyB0aGF0IHlvdSBjYW4gZ2V0IGFsbCB0aGUgbm9uLW5lZ290aWF0 ZWQgcGFyYW1ldGVycyBsaWtlIGNyeXB0byBhbmQgY2FuZGlkYXRlIGF0dHJpYnV0ZXM8L2Rpdj4N CjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiAtIHNldExvY2FsRGVzY3JpcHRpb24gYW5kIHNldFJl bW90ZURlc2NyaXB0aW9uIHByb3ZpZGUgYSB3YXkgb2YgbWF0Y2hpbmcgdXAgdHdvIFNEUCBibG9i cyBpbnRvIGEgY29tcGxldGUgc2Vzc2lvbiBkZXNjcmlwdGlvbjwvZGl2Pg0KPGRpdj4mbmJzcDs8 L2Rpdj4NCjxkaXY+IC0gbmVnb3RpYXRpb24gaXMgcGVyZm9ybWVkIG91dHNpZGUgdGhpcyBtYWNo aW5lLCBhbmQgdGhlIGJyb3dzZXIgY2FuIGhlbHAgeW91IHdpdGggdGhhdCBpbiB0d28gd2F5czog cHJvdmlkaW5nIGNyZWF0ZU9mZmVyIGFuZCBjcmVhdGVBbnN3ZXIgdG8gYnVpbGQgdGhlIFNEUDsg YW5kIGJ5IG51ZGdpbmcgeW91IHdpdGggYSBuZWdvdGlhdGVkbmVlZGVkIGV2ZW50IHdoZW4gaXQg bGVhcm5zIG9mIHRoaW5ncyB0aGF0IG5lY2Vzc2l0YXRlIGNoYW5nZXMuPC9kaXY+DQo8ZGl2PiZu YnNwOzwvZGl2Pg0KPGRpdj5PYnZpb3VzbHksIGl0J3MgYSBsaXR0bGUgbW9yZSBudWFuY2VkIHRo YW4gdGhhdCwgYnV0IGlmIHlvdSB0YWtlIHRoaXMgdmlldywgeW91IGFyZSBtb3JlIGxpa2VseSB0 byBnZXQgc29tZXRoaW5nIHRvIHdvcmsuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4t LU1hcnRpbjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+WzFdIENhdmVhdDogUFJBTlNX RVIgYWRkcyBhIGxheWVyIG9mIGNvbXBsZXhpdHkgdG8gdGhpcyBieSBzaGlmdGluZyBwYXJ0IG9m IHRoZSBzZXNzaW9uIGRlc2NyaXB0aW9uIHRvIHRoZSBvZmZlciByYXRoZXIgdGhhbiB0aGUgYW5z d2VyPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7F2072F1E0DE894DA4B517B93C6A0585340A7BC848ESESSCMS0356e_-- From kaiduanx@gmail.com Wed Oct 3 06:42:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD17C21F863B for ; Wed, 3 Oct 2012 06:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QlcgIrUj1se for ; Wed, 3 Oct 2012 06:42:52 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 41CAE21F84B6 for ; Wed, 3 Oct 2012 06:42:52 -0700 (PDT) Received: by obqv19 with SMTP id v19so8765226obq.31 for ; Wed, 03 Oct 2012 06:42:51 -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=nSDTTllIK4ooHvkCB4M35ivpiaNu1JfilDNg8z01Zds=; b=BCJFg2HW0QMzuRe/jie6u8Zq/FG0Bp8TeWdjAazK4PtsN2/0lOyLvOnNOzOEZmfLcD sDGJ48PwrQoJWdKl68kwZqA7s/cr5m7++uKLj57W/dmCLtOGC7k67f8F29BMfUd41ECA G6scI/zKIf0HKkJYbOipTHkBJI4bhhJagWadMWcubsmVIdD4bhfT0Eup4367SooeUKlp vwaAII6pAhNYn6hWFVE93jZehKWGnfICTjSnfNEDWhongwj8armPoCRomhT7cK6Ogzcp bItZ3efEUPzPhkVjMNwHwBDcjYXp9CAPEKRZAfexHY0VKBavfiMhaCeYBBN/5pl2hOpY xkJw== MIME-Version: 1.0 Received: by 10.60.29.230 with SMTP id n6mr1533153oeh.123.1349271771788; Wed, 03 Oct 2012 06:42:51 -0700 (PDT) Received: by 10.76.23.129 with HTTP; Wed, 3 Oct 2012 06:42:51 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 3 Oct 2012 09:42:51 -0400 Message-ID: From: Kaiduan Xie To: Christer Holmberg Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 13:42:53 -0000 There was a discussion on this, http://www.ietf.org/mail-archive/web/rtcweb/current/msg05141.html However I have not seen how the IETF webrtc work group address this issue. /Kaiduan On Wed, Oct 3, 2012 at 9:03 AM, Christer Holmberg wrote: > Hi, > > I've been looking at the O/A state machine, and the associated procedure > text, in section 4.2 of draft-jsep, and a couple of issues. > > First, the text says: > > "As in [RFC3264], an offerer can send an offer, and update it as > long as it has not been answered." > > That is not true. In order to update an offer (before it has been answered), > one needs to cancel the previous offer. > > > Second, the text says: > > "A description used as a "pranswer" may be applied as a response to > an "offer", or an update to a previously sent "answer"." > > I don't understand the update-to-a-previously-sent-answer thing. I don't > understand why one would update an "answer" with a "preanswer". > > And, the state machine doesn't seem to support it either. So, if done, what > state will I be in after such action? Can I then also send a new "answer", > to update the "preanswer" that updated the "answer"? > > > Third, is there a reason why a new "offer" can't be sent once in the > "Preanswer" state? > > > Regards, > > Christer > > > > > > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: 2. lokakuuta 2012 22:00 > To: Christer Holmberg > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? > > On 2 October 2012 11:00, Christer Holmberg > wrote: >> There has also been ideas about JSEP "relaxing" the SDP O/A rules. > > JSEP already does that. > > PRANSWER is probably the most obvious diversion, but it goes deeper. > > There's a simple view of what JSEP is and it goes a little like this: > > - SDP provides a description of the session that you are going to create [1] > > - You need two SDP blobs so that you can get all the non-negotiated > parameters like crypto and candidate attributes > > - setLocalDescription and setRemoteDescription provide a way of matching up > two SDP blobs into a complete session description > > - negotiation is performed outside this machine, and the browser can help > you with that in two ways: providing createOffer and createAnswer to build > the SDP; and by nudging you with a negotiatedneeded event when it learns of > things that necessitate changes. > > Obviously, it's a little more nuanced than that, but if you take this view, > you are more likely to get something to work. > > --Martin > > [1] Caveat: PRANSWER adds a layer of complexity to this by shifting part of > the session description to the offer rather than the answer > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From martin.thomson@gmail.com Wed Oct 3 08:26:39 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED4921F849D for ; Wed, 3 Oct 2012 08:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w43AfInfVBjD for ; Wed, 3 Oct 2012 08:26:38 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2522B21F84A2 for ; Wed, 3 Oct 2012 08:26:37 -0700 (PDT) Received: by lbok13 with SMTP id k13so7061732lbo.31 for ; Wed, 03 Oct 2012 08:26: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; bh=/8A68vcFM/TM9YqCdLJOBNuOfP2bXQQyjFX9JmQvy3U=; b=jDMbfLyzMh5LR0OPdbO698SqCDhOvd7bE890Cr4cuUu8zVkAiIe8H9dvcyuGFPHvV2 HLiqWaiqewke2sougfMfWeMiwWWnf8nFMlzQ7/hQdsZTh6J1S8zemgmt8yDuT1SrzRNW ac66aWZ+lgsBFLAN825tPqXf+si6gQ6SM+HJqYjtiS9c6g+Xn1BZWcFn9/iMjXrJJH+Z 1NEvFUc2W+3SxkAa1nMHMN6FwT2Jp+WQ6PSgB36ffUt4iidEQKge/OGaUvhO6DwKEo5y /B4E4tkjaC+QzYd70zbHjaD6ShmoYACaiwcCEx2v1dSJNlqvOuWmpr8E658QI0f1WLIs mn5Q== MIME-Version: 1.0 Received: by 10.112.24.101 with SMTP id t5mr1825869lbf.123.1349277997032; Wed, 03 Oct 2012 08:26:37 -0700 (PDT) Received: by 10.112.83.2 with HTTP; Wed, 3 Oct 2012 08:26:36 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 3 Oct 2012 08:26:36 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 15:26:39 -0000 These are just a few of the problems with the provisional answer. On 3 October 2012 06:03, Christer Holmberg wrote: > "As in [RFC3264], an offerer can send an offer, and update it as > long as it has not been answered." > > That is not true. In order to update an offer (before it has been answered), > one needs to cancel the previous offer. This might be OK if it were to include the fact that any outstanding offer is implicitly cancelled. Note that it is not clear how the current API could be used to cancel an offer. Various suggestions include passing a null offer or by setting the local (or remote?) description to a previous offer. > "A description used as a "pranswer" may be applied as a response to > an "offer", or an update to a previously sent "answer"." > > I don't understand the update-to-a-previously-sent-answer thing. I don't > understand why one would update an "answer" with a "preanswer". This doesn't make sense to me either. I could understand if it was an update to a previously sent *pranswer*, but since an answer is final, any further answers are illegal. > And, the state machine doesn't seem to support it either. So, if done, what > state will I be in after such action? Can I then also send a new "answer", > to update the "preanswer" that updated the "answer"? That's why I think that this is in error. > Third, is there a reason why a new "offer" can't be sent once in the > "Preanswer" state? Yes. If you send an offer out to multiple people and one gives a provisional answer, the new offer you create would have to be cleverly crafted to permit all sessions described by the previous offer as well as any new stuff, such that an answer to the old offer could be applied to the new offer. That really complicates things. In the assumed model, all answers and pranswers are made in respect to a specific offer. answers and pranswers only be applied to a session that has applied their specific offer. pranswers and answers can replace pranswers that reference the same offer. This is an expansion on 3264. This is what draft-*-jsep needs to describe clearly, if that is appropriate. I am slowly reaching the conclusion that pranswer is a complication that we don't need, especially since - for those who care about the functionality - it can be replicated by editing offers and answers. --Martin From harald@alvestrand.no Thu Oct 4 01:57:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D18F21F85FC for ; Thu, 4 Oct 2012 01:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.479 X-Spam-Level: X-Spam-Status: No, score=-110.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyjzE4c1IcrM for ; Thu, 4 Oct 2012 01:57:34 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B008421F85C3 for ; Thu, 4 Oct 2012 01:57:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 57E5139E0FE for ; Thu, 4 Oct 2012 10:57:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHGkiqTe1DZP for ; Thu, 4 Oct 2012 10:57:31 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8FE7E39E062 for ; Thu, 4 Oct 2012 10:57:31 +0200 (CEST) Message-ID: <506D4F7A.5020109@alvestrand.no> Date: Thu, 04 Oct 2012 10:57:30 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 08:57:35 -0000 On 10/03/2012 05:26 PM, Martin Thomson wrote: > This is an expansion on 3264. This is what draft-*-jsep needs to > describe clearly, if that is appropriate. I am slowly reaching the > conclusion that pranswer is a complication that we don't need, > especially since - for those who care about the functionality - it can > be replicated by editing offers and answers. I would be very happy to lose PRANSWER if the SIP guys tell us they can successfully gateway to systems using provisional SIP answers (which I think is the same thing as the one called "serial forking") without them. For the Web use case, I think PRANSWER is an unnecessary distraction; if we're writing both initiator and responder, multiple O/A rounds, or use of multiple PeerConnections, is a much cleaner solution for the use cases I can wrap my head around. From christer.holmberg@ericsson.com Thu Oct 4 02:54:59 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752B021F86FF for ; Thu, 4 Oct 2012 02:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.119 X-Spam-Level: X-Spam-Status: No, score=-6.119 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAM8Fpj37Qd5 for ; Thu, 4 Oct 2012 02:54:59 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7187B21F86DA for ; Thu, 4 Oct 2012 02:54:58 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-0e-506d5cf06e4f Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 80.E6.25676.0FC5D605; Thu, 4 Oct 2012 11:54:57 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Thu, 4 Oct 2012 11:54:56 +0200 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Date: Thu, 4 Oct 2012 11:52:55 +0200 Thread-Topic: [rtcweb] JSEP: Relaxing SDP O/A rules? Thread-Index: Ac2iDk4YSQEPaXi8SKyPtKctaeI9jwAB7i1B Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDE@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> , <506D4F7A.5020109@alvestrand.no> In-Reply-To: <506D4F7A.5020109@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvre7HmNwAg6sb2SyO9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGX8vn2csWACW8W1o2tYGxjfsHQxcnBICJhI rOsV7WLkBDLFJC7cW8/WxcjFISRwilGifdkxFghnPqPEilOz2UAa2AQsJLr/aYM0iAgES/Q+ f88IEmYRUJFY/1IZJCwsYCzR+fkYE0SJicSaHWtYIGwjiV3vlrCB2LwC4RKXtr9hhBh/hUli wuI77CAJTgFdiQUTuphBbEagg76fWgM2iFlAXOLWk/lMEIcKSCzZc54ZwhaVePn4HytEvajE nfb1jBD1OhILdn9ig7C1JZYtfM0MsVhQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcUonJuY mZNebqSXWpSZXFycn6dXnLqJERghB7f8Vt3BeOecyCFGaQ4WJXFe6617/IUE0hNLUrNTUwtS i+KLSnNSiw8xMnFwSjUwdn9e++rRzBkaE1QzbnZ/EGCXm5NmsDs0W8Ty7tHCTz0xHSl8T8MX /0/ze3r7wIZ017OCrvIp16omHavTstD5ov9sutbKdr9Fqkvmrzz74GTeYt0XBwt+HyoqY+B1 sjhUt0r3apedksbz3xX/v7/xj724nVNKc7lRkyjD5uqoWzL+CkazZXavVWIpzkg01GIuKk4E AMyRLDFeAgAA Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 09:54:59 -0000 Hi, >> This is an expansion on 3264. This is what draft-*-jsep needs to >> describe clearly, if that is appropriate. I am slowly reaching the >> conclusion that pranswer is a complication that we don't need, >> especially since - for those who care about the functionality - it can >> be replicated by editing offers and answers. > > I would be very happy to lose PRANSWER if the SIP guys tell us they can > successfully gateway to systems using provisional SIP answers (which I > think is the same thing as the one called "serial forking") without them. I guess serial forking could be handled using cloning, in the same way as p= arallel forking. (Assuming we are going to support cloning, that is - currently it IS descri= bed in JSEP) Regards, Christer= From christer.holmberg@ericsson.com Thu Oct 4 02:56:25 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C8921F86AF for ; Thu, 4 Oct 2012 02:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.121 X-Spam-Level: X-Spam-Status: No, score=-6.121 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv+PTmwRHWtT for ; Thu, 4 Oct 2012 02:56:24 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1614E21F86D0 for ; Thu, 4 Oct 2012 02:56:23 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-91-506d5d46bd70 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 56.27.25676.64D5D605; Thu, 4 Oct 2012 11:56:23 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 4 Oct 2012 11:56:22 +0200 From: Christer Holmberg To: Martin Thomson Date: Thu, 4 Oct 2012 11:56:22 +0200 Thread-Topic: [rtcweb] JSEP: Relaxing SDP O/A rules? Thread-Index: Ac2he3p3WYPLc1ycRw2otF2KGVpYowAeaRqQ Message-ID: <96F825286CEAFC40B37C080D4284A44F2C3CD91519@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvra57bG6AwfqrfBbXzvxjtFj7r53d gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mro/3+JseAOW8X1rZfYGhhnsnYxcnJICJhI LNi/gw3CFpO4cG89kM3FISRwilHi0K4uFghnPqPEwiu7mLsYOTjYBCwkuv9pgzSICOhKLDr7 gB3EZhZQl7iz+ByYzSKgIvHn6mNmEFtYwFii8/MxJoh6E4k1O9awQNhGEhvuXmABGckrEC6x erUNxKrNTBJLFm4FO45TIFCiZ+0PsJmMQMd9P7WGCWKXuMStJ/OZII4WkFiy5zwzhC0q8fLx P1aIelGJO+3rGSHqdSQW7P7EBmFrSyxb+BqsnldAUOLkzCcsExjFZiEZOwtJyywkLbOQtCxg ZFnFKJybmJmTXm6kl1qUmVxcnJ+nV5y6iREYOwe3/FbdwXjnnMghRmkOFiVxXuute/yFBNIT S1KzU1MLUovii0pzUosPMTJxcEo1MLJZKRbqptdVan5cdP2A0t0ajqDTzp4HjwRFbt6fvy1/ /xn173P11q796G7R19w3/f+N5NainUsKvp6yPXl2+/F7Ky+5HPfqidid/kj5qdPmJjXrlsD6 3hl1S93sWBliXhiKTHZ6e1WyYPKtZ5KnmGeEqnsE1e7+uuteTNV9aen5ZotsOx4vn6jEUpyR aKjFXFScCAAFCY3OawIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 09:56:25 -0000 Hi, >> "As in [RFC3264], an offerer can send an offer, and update it=20 >> as long as it has not been answered." >> >> That is not true. In order to update an offer (before it has been=20 >> answered), one needs to cancel the previous offer. > > This might be OK if it were to include the fact that any outstanding offe= r is implicitly cancelled. Sure. My issue was about the RFC 3264 claim. It's one of the "relaxes" we w= ould have to specify ourselves. > Note that it is not clear how the current API could be used to cancel an = offer. Various suggestions include passing a null offer or by setting the = local (or remote?) description to a previous offer. I assume that setting the description to a previous offer, from an API pers= pective, is the same as updating the offer with something new. Regards, Christer= From christer.holmberg@ericsson.com Thu Oct 4 04:26:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1591721F866B for ; Thu, 4 Oct 2012 04:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.123 X-Spam-Level: X-Spam-Status: No, score=-6.123 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVLp+AbQ2jmI for ; Thu, 4 Oct 2012 04:26:01 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A9F1321F8532 for ; Thu, 4 Oct 2012 04:26:00 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-de-506d7246e511 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 17.DD.17130.6427D605; Thu, 4 Oct 2012 13:25:58 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 4 Oct 2012 13:25:58 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Date: Thu, 4 Oct 2012 13:25:56 +0200 Thread-Topic: JSEP-02: Clone comments Thread-Index: Ac2iIwW7cKWr92TuQXaTuWwnWaxp7g== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A7BCD49@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585340A7BCD49ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyM+Jvra5bUW6AwfoGVYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsfveLJaCGYoVO1a/ZGlgbJHtYuTkkBAwkfg54y4rhC0mceHe erYuRi4OIYFTjBLT/35mh3DmM0p0ftjK3MXIwcEmYCHR/U8bpEFEQF3i8sML7CA2i4CKRMO1 v2wgtrCAgsTFI9MYIWpUJbraTrJB2HoSn+Z2gNm8AuESU6bNAFvMCLT4+6k1TCA2s4C4xK0n 85kgDhKQWLLnPDOELSrx8vE/qHpRiTvt6xkh6vMlLsy4wAIxU1Di5MwnLBMYhWYhGTULSdks JGUQcR2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FaNwbmJmTnq5uV5qUWZycXF+nl5x6iZG YDwc3PLbYAfjpvtihxilOViUxHn1VPf7CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamA8VxjA MqXg69ULDezlZr4Z32bJfDe8zti2od32il4YX3FisAV3mPn2zT2rzk1h/5bi1sunZ3rLckKj gWDQn6uSbaULbuk+f8C3dl/f/3eiFquvPE1OPhHcbCwjX8z6hvNIX9f6+bPumHJ5OfnOnmXj eY214uPe7bormbtWXN6gxzljcsFXXkMlluKMREMt5qLiRABDi6bVVQIAAA== Subject: [rtcweb] JSEP-02: Clone comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 11:26:02 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585340A7BCD49ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A couple of comments on the cloning stuff in JSEP: Q1. The document doesn't say how the cloning is performed. If that is outsi= de the scope of JSEP, and belongs to the W3C API spec, I think it should be= mentioned. Q2. The text in section 4.7.2 says: "As a result of this cloning, the application will end up w= ith N parallel sessions, each with a local and remote description= and their own local and remote addresses." I think the "own local addresses" wording is a little misleading, as each c= lone will share the same local address. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585340A7BCD49ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi,

 

A couple of comments on the cloning stu= ff in JSEP:

 

Q1. The document doesn’t say how the cloning is perform= ed. If that is outside the scope of JSEP, and belongs to the W3C API spec, = I think it should be mentioned.

&nb= sp;

Q2. The text in section 4.7.2 says:<= /o:p>

 

&nb= sp;            =    “As a result of this cloning, the application will end u= p with N

      =           parallel sessions, e= ach with a local and remote description and their

           &nbs= p;    own local and remote addresses.”

<= p class=3DMsoNormal> 

I think the &= #8220;own local addresses” wording is a little misleading, as each cl= one will share the same local address.

<= o:p> 

Regards,

 

Christer

=

 

 <= /o:p>

= --_000_7F2072F1E0DE894DA4B517B93C6A0585340A7BCD49ESESSCMS0356e_-- From harald@alvestrand.no Thu Oct 4 04:32:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C758321F8661 for ; Thu, 4 Oct 2012 04:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.498 X-Spam-Level: X-Spam-Status: No, score=-110.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cALSwlPP3dIJ for ; Thu, 4 Oct 2012 04:32:34 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAD721F85A1 for ; Thu, 4 Oct 2012 04:32:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7DB9F39E0FE for ; Thu, 4 Oct 2012 13:32:33 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmNOcrQ6uOys for ; Thu, 4 Oct 2012 13:32:32 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2631E39E062 for ; Thu, 4 Oct 2012 13:32:32 +0200 (CEST) Message-ID: <506D73CF.80701@alvestrand.no> Date: Thu, 04 Oct 2012 13:32:31 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A0585340A7BCD49@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A7BCD49@ESESSCMS0356.eemea.ericsson.se> Content-Type: multipart/alternative; boundary="------------030403090000030705020607" Subject: Re: [rtcweb] JSEP-02: Clone comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 11:32:35 -0000 This is a multi-part message in MIME format. --------------030403090000030705020607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/04/2012 01:25 PM, Christer Holmberg wrote: > > Hi, > > A couple of comments on the cloning stuff in JSEP: > > Q1. The document doesn't say how the cloning is performed. If that is > outside the scope of JSEP, and belongs to the W3C API spec, I think it > should be mentioned. > > Q2. The text in section 4.7.2 says: > > "As a result of this cloning, the application will end > up with N > > parallel sessions, each with a local and remote > description and their > > own local and remote addresses." > > I think the "own local addresses" wording is a little misleading, as > each clone will share the same local address. > Not sure what to say here. I can see multiple ways to implement this - some will end up with different local ports, some won't. If the non-local (reflexive?) candidates are allocated using STUN on a per-port basis, addresses could be different too. --------------030403090000030705020607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/04/2012 01:25 PM, Christer Holmberg wrote:

Hi,

 

A couple of comments on the cloning stuff in JSEP:

 

Q1. The document doesn’t say how the cloning is performed. If that is outside the scope of JSEP, and belongs to the W3C API spec, I think it should be mentioned.

 

Q2. The text in section 4.7.2 says:

 

                “As a result of this cloning, the application will end up with N

                parallel sessions, each with a local and remote description and their

                own local and remote addresses.”

 

I think the “own local addresses” wording is a little misleading, as each clone will share the same local address.


Not sure what to say here.

I can see multiple ways to implement this - some will end up with different local ports, some won't.

If the non-local (reflexive?) candidates are allocated using STUN on a per-port basis, addresses could be different too.

--------------030403090000030705020607-- From christer.holmberg@ericsson.com Thu Oct 4 04:57:29 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA5D21F8681 for ; Thu, 4 Oct 2012 04:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.825 X-Spam-Level: X-Spam-Status: No, score=-4.825 tagged_above=-999 required=5 tests=[AWL=-1.177, BAYES_50=0.001, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYYD+fl1EwVa for ; Thu, 4 Oct 2012 04:57:28 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 33E9F21F867B for ; Thu, 4 Oct 2012 04:57:27 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-d7-506d79a7bc25 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 63.D2.17130.7A97D605; Thu, 4 Oct 2012 13:57:27 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 4 Oct 2012 13:57:26 +0200 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Date: Thu, 4 Oct 2012 13:57:26 +0200 Thread-Topic: [rtcweb] JSEP-02: Clone comments Thread-Index: Ac2iI/XWrwwBPADvT568luJcEfqkxAAAvQKQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A7BCD92@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340A7BCD49@ESESSCMS0356.eemea.ericsson.se> <506D73CF.80701@alvestrand.no> In-Reply-To: <506D73CF.80701@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585340A7BCD92ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvre7yytwAg49f+SyO9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGXcPvOEvWC9RsWJxsfsDYwzlLoYOTkkBEwk NvT2s0PYYhIX7q1n62Lk4hASOMUoManzDTOEM59RYv3cTiCHg4NNwEKi+582SIOIQLBE7/P3 jCA2i4CKxNSmG0wgtrCArsTNoxPYIWr0JA5862WFsI0kFt7aCFbPKxAucWTCRGYQW0igQmLa 0ZnsIOM5BbQlNmyxAAkzAt3z/dQasJHMAuISt57MZ4K4U0BiyZ7zzBC2qMTLx/9YIepFJe60 r2eEqM+XOHljCRvEKkGJkzOfsExgFJmFZNQsJGWzkJRBxPUl9kw8BWVrSyxb+JoZwtaTuLfj Lyuy+AJG9lWMwrmJmTnp5eZ6qUWZycXF+Xl6xambGIERdXDLb4MdjJvuix1ilOZgURLn1VPd 7y8kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBkbfvRErbtO7l5xzWXqpJXmj3nf3MrPb4xUb3 zbqCVbVEjxWrNV+SuH1yhqy4yLesA3ttZjDHrouWFhXtZHLtrfJdMGOP25fC/xxHNiXO/3Nl 5rPPDW/W5650mJRx/EjvWT6Vcqa6+k1NB5vqN+bMF7DlOta0+tm1m/Lf/rItneX/iS29uIZL Q4mlOCPRUIu5qDgRAEhklVJ2AgAA Subject: Re: [rtcweb] JSEP-02: Clone comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 11:57:30 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585340A7BCD92ESESSCMS0356e_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi, >> A couple of comments on the cloning stuff in JSEP: >> >> Q1. The document doesn=1B$B!G=1B(Bt say how the cloning is performed. If= that is outside the scope of JSEP, and belongs to the W3C API spec, I thin= k it should be mentioned. >> >> Q2. The text in section 4.7.2 says: >> >> =1B$B!H=1B(BAs a result of this cloning, the application = will end up with N >> parallel sessions, each with a local and remote descripti= on and their >> own local and remote addresses.=1B$B!I=1B(B =1B$B"d=1B(B >> I think the =1B$B!H=1B(Bown local addresses=1B$B!I=1B(B wording is a lit= tle misleading, as each clone will share the same local address. > > Not sure what to say here. > > I can see multiple ways to implement this - some will end up with differe= nt local ports, some won't. Earlier in the same section, the text says: =1B$B!H=1B(BSince the clone uses the same local description as its parent, creating a clone will fail if it is not possible to reserve the same resources for the clone as have already been reserved by t= he parent.=1B$B!I=1B(B > If the non-local (reflexive?) candidates are allocated using STUN on a pe= r-port basis, addresses could be different too. My assumption, and understanding of the text, is that a clone is a=1B$B!D= =1B(B eeeeh=1B$B!D=1B(B clone - meaning that the local address is the same = :) Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585340A7BCD92ESESSCMS0356e_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
Hi,
 
>> A couple of comments on the cloning stuff in JSEP:
>>
>> Q1. The document doesn=1B$B!G=1B(Bt say how the cloning is pe= rformed. If that is outside the scope of JSEP, and belongs to the W3C API s= pec, I think it should be mentioned.
>> 
>> Q2. The text in section 4.7.2 says:
>> 
>>          &n= bsp;     =1B$B!H=1B(BAs a result of this cloning, the a= pplication will end up with N
>>           &= nbsp;    parallel sessions, each with a local and remote des= cription and their
>>           &= nbsp;    own local and remote addresses.=1B$B!I=1B(B
=1B$B"d=1B(B
>> I think the =1B$B!H=1B(Bown local addresses=1B$B!I=1B(B wordi= ng is a little misleading, as each clone will share the same local address.=
>
> Not sure what to say here.
>
> I can see multiple ways to implement this - some will end up with= different local ports, some won't.
 
Earlier in the same section, the text says:
 
        =1B= $B!H=1B(BSince the clone uses the same local description as its
       &= nbsp; parent, creating a clone will fail if it is not possible t= o reserve
       &nbs= p; the same resources for the clone as have already been reserved by the
       &nbs= p; parent.=1B$B!I=1B(B
 
> If the non-local (reflexive?) candidates are allocated using STUN= on a per-port basis, addresses could be different too.
 
My assumption, and understanding of the text, = is that a clone is a=1B$B!D=1B(B eeeeh=1B$B!D=1B(B clone – meaning th= at the local address is the same :)
 
Regards,
 
Christer
 
 
 
 --_000_7F2072F1E0DE894DA4B517B93C6A0585340A7BCD92ESESSCMS0356e_-- From Jim.Barnett@genesyslab.com Thu Oct 4 05:47:57 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466FC21F85F0 for ; Thu, 4 Oct 2012 05:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxrxA2K08LrX for ; Thu, 4 Oct 2012 05:47:55 -0700 (PDT) Received: from relay-out2.dc.genesyslab.com (relay-out2.dc.genesyslab.com [198.49.180.221]) by ietfa.amsl.com (Postfix) with ESMTP id DD99421F85C3 for ; Thu, 4 Oct 2012 05:47:55 -0700 (PDT) Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out2.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q94ClfQu009614; Thu, 4 Oct 2012 05:47:41 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Oct 2012 05:47:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDA22E.7166C3F9" Date: Thu, 4 Oct 2012 05:47:30 -0700 Message-ID: In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A7BCD92@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] JSEP-02: Clone comments Thread-Index: Ac2iI/XWrwwBPADvT568luJcEfqkxAAAvQKQAAHSDIA= References: <7F2072F1E0DE894DA4B517B93C6A0585340A7BCD49@ESESSCMS0356.eemea.ericsson.se><506D73CF.80701@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A0585340A7BCD92@ESESSCMS0356.eemea.ericsson.se> From: "Jim Barnett" To: "Christer Holmberg" , "Harald Alvestrand" , X-OriginalArrivalTime: 04 Oct 2012 12:47:41.0502 (UTC) FILETIME=[7133ADE0:01CDA22E] Subject: Re: [rtcweb] JSEP-02: Clone comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 12:47:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDA22E.7166C3F9 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit If the local address isn$B!G(Jt the same, we shouldn$B!G(Jt call it a $B!F(Jclone$B!G(J. I think that people will expect everything to be the same on a $B!F(Jclone$B!G(J. - Jim From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Thursday, October 04, 2012 7:57 AM To: Harald Alvestrand; rtcweb@ietf.org Subject: Re: [rtcweb] JSEP-02: Clone comments Hi, >> A couple of comments on the cloning stuff in JSEP: >> >> Q1. The document doesn$B!G(Jt say how the cloning is performed. If that is outside the scope of JSEP, and belongs to the W3C API spec, I think it should be mentioned. >> >> Q2. The text in section 4.7.2 says: >> >> $B!H(JAs a result of this cloning, the application will end up with N >> parallel sessions, each with a local and remote description and their >> own local and remote addresses.$B!I(J $B"d(J >> I think the $B!H(Jown local addresses$B!I(J wording is a little misleading, as each clone will share the same local address. > > Not sure what to say here. > > I can see multiple ways to implement this - some will end up with different local ports, some won't. Earlier in the same section, the text says: $B!H(JSince the clone uses the same local description as its parent, creating a clone will fail if it is not possible to reserve the same resources for the clone as have already been reserved by the parent.$B!I(J > If the non-local (reflexive?) candidates are allocated using STUN on a per-port basis, addresses could be different too. My assumption, and understanding of the text, is that a clone is a$B!D(J eeeeh$B!D(J clone (J-(J meaning that the local address is the same :) Regards, Christer ------_=_NextPart_001_01CDA22E.7166C3F9 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit

If the local address isn$B!G(Bt the same, we shouldn$B!G(Bt call it a $B!F(Bclone$B!G(B.  I think that people will expect everything to be the same on a $B!F(Bclone$B!G(B. 

 

-          Jim

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Thursday, October 04, 2012 7:57 AM
To: Harald Alvestrand; rtcweb@ietf.org
Subject: Re: [rtcweb] JSEP-02: Clone comments

 

Hi,

 

>> A couple of comments on the cloning stuff in JSEP:

>> 

>> Q1. The document doesn$B!G(Bt say how the cloning is performed. If that is outside the scope of JSEP, and belongs to the W3C API spec, I think it should be mentioned.

>> 

>> Q2. The text in section 4.7.2 says:

>> 

>>                $B!H(BAs a result of this cloning, the application will end up with N

>>                parallel sessions, each with a local and remote description and their

>>                own local and remote addresses.$B!I(B

$B"d(B

>> I think the $B!H(Bown local addresses$B!I(B wording is a little misleading, as each clone will share the same local address.

> 

> Not sure what to say here.

> 

> I can see multiple ways to implement this - some will end up with different local ports, some won't.

 

Earlier in the same section, the text says:

 

        $B!H(BSince the clone uses the same local description as its

      &nb! sp;  parent, creating a clone will fail if it is not possible to reserve

         the same resources for the clone as have already been reserved by the

         parent.$B!I(B

 

> If the non-local (reflexive?) candidates are allocated using STUN on a per-port basis, addresses could be different too.

 

My assumption, and understanding of the text, is that a clone is a$B!D(B eeeeh$B!D(B clone – meaning that the local address is the same :)

 

Regards,

 

Christer

 

 

 

------_=_NextPart_001_01CDA22E.7166C3F9-- From harald@alvestrand.no Thu Oct 4 06:26:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667E821F8699 for ; Thu, 4 Oct 2012 06:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.513 X-Spam-Level: X-Spam-Status: No, score=-110.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+WO-F0y57PI for ; Thu, 4 Oct 2012 06:26:26 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 40A5621F85F4 for ; Thu, 4 Oct 2012 06:26:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EEA0839E0FE for ; Thu, 4 Oct 2012 15:26:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0J1raEsQ545 for ; Thu, 4 Oct 2012 15:26:21 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 40FC139E062 for ; Thu, 4 Oct 2012 15:26:21 +0200 (CEST) Message-ID: <506D8E7C.1080509@alvestrand.no> Date: Thu, 04 Oct 2012 15:26:20 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="------------050904050408080702070202" Subject: [rtcweb] Chrome M23 beta released with the PeerConnection API X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 13:26:27 -0000 This is a multi-part message in MIME format. --------------050904050408080702070202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Normally product releases aren't the stuff of IETF mailing lists, but this one is a milestone: Chrome M23 is now in beta, and includes the current PeerConnection API. This is an important milestone: First shipping implementation! http://blog.chromium.org/2012/10/supporting-new-media-experiences-on-web.html is the announcement. https://sites.google.com/site/webrtc/faq-recent-topics gives some more details on exactly what's implemented in this version. Harald --------------050904050408080702070202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Normally product releases aren't the stuff of IETF mailing lists, but this one is a milestone:

Chrome M23 is now in beta, and includes the current PeerConnection API.
This is an important milestone: First shipping implementation!

http://blog.chromium.org/2012/10/supporting-new-media-experiences-on-web.html is the announcement.

https://sites.google.com/site/webrtc/faq-recent-topics gives some more details on exactly what's implemented in this version.

                   Harald


--------------050904050408080702070202-- From christer.holmberg@ericsson.com Thu Oct 4 07:33:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2C521F85C3 for ; Thu, 4 Oct 2012 07:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.106 X-Spam-Level: X-Spam-Status: No, score=-6.106 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9pYf9DSAxKW for ; Thu, 4 Oct 2012 07:33:54 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 894CD21F853E for ; Thu, 4 Oct 2012 07:33:53 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-5d-506d9e50a229 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 8A.63.25676.05E9D605; Thu, 4 Oct 2012 16:33:52 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Thu, 4 Oct 2012 16:33:52 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Date: Thu, 4 Oct 2012 16:33:50 +0200 Thread-Topic: JSEP-02: SDP line Thread-Index: Ac2iPS1XRwcDGMpnSoiEZI5qFJ9/hA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A7BCEF1@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585340A7BCEF1ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+JvrW7AvNwAg5Z+BYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsXnRScaCFcIVS5Y+Zmxg3CTYxcjJISFgIvH0zj02CFtM4sK9 9UA2F4eQwClGiSPrJzBCOPMZJZ5OmMXUxcjBwSZgIdH9TxukQURAXeLywwvsIDaLgIrEmTmv wEqEBaQkvl1ihSiRl5h87yo7SFhEQE9i4ncOkDCvQLjEj5crwUoYgdZ+P7WGCcRmFhCXuPVk PhPEOQISS/acZ4awRSVePv4HVS8qcad9PSNEfb7EhfkLWCFmCkqcnPmEZQKj0Cwko2YhKZuF pAwiriOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYhTOTczMSS830kstykwuLs7P0ytO3cQI jIWDW36r7mC8c07kEKM0B4uSOK/11j3+QgLpiSWp2ampBalF8UWlOanFhxiZODilGhh58g89 0/o2q1Guo/H5OmX/ty2Xdpd61JvbuYSUW56/9NO8X+DpTpbN/8sKXJ/6nHO9e0Fn75vDdWbu DffdJxY+PfTNZbfZAZv47+YpL5nvJtzjvLluQ7Eho9/0Tcd/uBW4GJnLXb97/qLikZgOzpO7 /HacXtWcel07TG+O2OKIUNnaC/k1y3OVWIozEg21mIuKEwGJxkONUwIAAA== Subject: [rtcweb] JSEP-02: SDP line X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 14:33:54 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585340A7BCEF1ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, What is a "SDP line"? The same thing as a "SDP blob"? Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585340A7BCEF1ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi,

 

What is a ”SDP line”? The s= ame thing as a “SDP blob”?

<= o:p> 

Regards,

 

Christer

=
= --_000_7F2072F1E0DE894DA4B517B93C6A0585340A7BCEF1ESESSCMS0356e_-- From ted.ietf@gmail.com Thu Oct 4 08:32:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE1B21F8705 for ; Thu, 4 Oct 2012 08:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C77hZAi+0Gvo for ; Thu, 4 Oct 2012 08:32:23 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 627C121F86FE for ; Thu, 4 Oct 2012 08:32:13 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so854193vcb.31 for ; Thu, 04 Oct 2012 08:32:12 -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=LnvafLt9FSKGBOkIXmZQAWA4asU7WoCYLXAO+dTOXec=; b=YJgxgf7pNPffvgfrQ9ekpScLcZnIrpauVCYOegO99yX/rHWh4SisFuUakF9Ph0gSO9 X3oIzvV9VOV9fGr/UefyyRaDhCMoHVM0N554K9yAEMTPyW7fANdMfgr429M6+7jxukw1 0WEESlFYcmvbsb7WuG4PuKlWGCJLFRJHuJgnrOsS6rWRwJ+YQ6YL5QSI+bWwDV2ONAGM KSkKz72753+DSditLw2iqFOz916a8AjzVuq9vHTAkW9tSNvut0tYuFpQ8iTz6Pc13FdM xOEd9441UPZBsiNPYmOQfS52PtvjiyShtyZGyE9/Z/ZRicr4GMmCPYWrnNNYd+cqDMng 98bA== MIME-Version: 1.0 Received: by 10.220.238.148 with SMTP id ks20mr3395486vcb.5.1349364732834; Thu, 04 Oct 2012 08:32:12 -0700 (PDT) Received: by 10.58.245.39 with HTTP; Thu, 4 Oct 2012 08:32:12 -0700 (PDT) Date: Thu, 4 Oct 2012 08:32:12 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Resolving whether to support additional key management methods X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 15:32:24 -0000 The Chairs would like to foster resolution of the long-running discussion of support for additional key management methods, e.g. as described in draft-ohlsson-rtcweb-sdes-support and the meeting materials supporting draft-ietf-avtcore-srtp-ekt. Working group discussion of this matter is, of course, welcome, but the chairs are also considering a virtual interim meeting in January of 2013, focused on this specific topic. Comments on this plan or on the relevant approaches is welcome. regards, Ted, Cullen, Magnus From fluffy@cisco.com Thu Oct 4 08:44:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD0F21F85C3 for ; Thu, 4 Oct 2012 08:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGouvKRWssH4 for ; Thu, 4 Oct 2012 08:44:10 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1445721F85BB for ; Thu, 4 Oct 2012 08:44:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1419; q=dns/txt; s=iport; t=1349365450; x=1350575050; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4horee4eunIq7GvNbhtujcHoHq3gHhcZQDSjASF7sdg=; b=jM1Rfjjq1wHZ+PWg8A1b7Sk/ec527Cf8jTrvNdL4NpMvSSRcMkfVZ3EL Jnww45W9v/VcbWgrFqGHMhqxhvy2PN0RR5ELXnlGgwpPC2BN+kiES6E4v t5nVzOqoDDvBNycC340zymAGRVuzMu+xDuXWxf09hDVaVMUVifJdvaoQB 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAWubVCtJV2c/2dsb2JhbABFvwqBCIIgAQEBAwEBAQEJBgFbCwUJAgIBCCIdBxsMCxQRAgQOBQgah10GC5gyoBcEBIs6hT1gA6QsgWmCbYIX X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="128316768" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 04 Oct 2012 15:44:06 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q94Fi5Jc008321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Oct 2012 15:44:05 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.62]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.001; Thu, 4 Oct 2012 10:44:05 -0500 From: "Cullen Jennings (fluffy)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Agenda requests for Atlanta meeting Thread-Index: AQHNokcVmKX2z94GUkOz6A2FaADmtg== Date: Thu, 4 Oct 2012 15:44:04 +0000 Message-ID: References: <506B0367.4000103@ericsson.com> In-Reply-To: <506B0367.4000103@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19238.000 x-tm-as-result: No--41.640500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 15:44:10 -0000 With my individual contributor hat on =85 Justin and I would like to have some time for JSEP. I think there are a bun= ch of issues, particularly around the use of SDP and timing of various thin= gs that need discussion.=20 Thanks, Cullen On Oct 2, 2012, at 9:08 AM, Magnus Westerlund wrote: > WG, >=20 > We chairs like to have input into what you see should be on the Agenda > for our two meeting slots in Atlanta. Both document editors/authors and > participant are welcome to request or inform the WG or the chairs only > about issues that needs to be discussed in the meeting. >=20 > Two items we chairs believe should be on the agenda are: >=20 > - Video codec selection > - JSEP >=20 >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ekr@rtfm.com Thu Oct 4 10:02:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725DC21F8715 for ; Thu, 4 Oct 2012 10:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.66 X-Spam-Level: X-Spam-Status: No, score=-102.66 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKB4KI3hNJhl for ; Thu, 4 Oct 2012 10:02:45 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A400D21F863F for ; Thu, 4 Oct 2012 10:02:44 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so686076eek.31 for ; Thu, 04 Oct 2012 10:02:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=Fi2pgordY/b+QyIDM0iB9jtG3s0zePnw5LpS7MJCAm4=; b=UqsvLNQP9js1uEljHC7xo1N/zexHM7AG8IAJgzm4hsZhSCPhHpJrMgZ7n6PKAkLF3W 9wOW7JliaydYeRMweEtd/6krVfasrnQTqMjGT98Zk0i6E8mKcF2kU2ZahaZkPLoCSDzA 2yiz9oQzZCd/CI0+YATleHuCggbIuLHORNak2wmsKXOr4VgIVCGOC9XetV9H+4zomjCw wH22Wdb+3a0R9Cgwj0Q08P76gnrCFN7h+ivSO5cwtzaUPtDmHCPG+lUN9+B+5fnpBAfR aO5bpqD76Cw160/413hnnpqqVRthJOTlF3IgDQWJEpmSgFetn636zZdL+YtAd/ycoefA Rnqg== Received: by 10.14.207.5 with SMTP id m5mr9311082eeo.22.1349370163693; Thu, 04 Oct 2012 10:02:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.144.77 with HTTP; Thu, 4 Oct 2012 10:02:03 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Thu, 4 Oct 2012 10:02:03 -0700 Message-ID: To: Ted Hardie Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnmy57/z8rHXz0XA96JS2/athsGCbTa/UrwpAnh0EjdZttFUrYKXwnuqWCkjaSxyWGZ/GbJ Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving whether to support additional key management methods X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 17:02:45 -0000 A virtual meeting seems OK. I'm totally heads-down in code for the next while so I won't really be able to contribute to much list discussion on this until after IETF... Best, -Ekr On Thu, Oct 4, 2012 at 8:32 AM, Ted Hardie wrote: > The Chairs would like to foster resolution of the long-running > discussion of support for additional key management methods, e.g. as > described in draft-ohlsson-rtcweb-sdes-support and the meeting > materials supporting draft-ietf-avtcore-srtp-ekt. Working group > discussion of this matter is, of course, welcome, but the chairs are > also considering a virtual interim meeting in January of 2013, focused > on this specific topic. Comments on this plan or on the relevant > approaches is welcome. > > regards, > > Ted, Cullen, Magnus > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Thu Oct 4 11:00:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F2721F8648 for ; Thu, 4 Oct 2012 11:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KM3Rz7EHOzTl for ; Thu, 4 Oct 2012 11:00:55 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id E6F5721F8605 for ; Thu, 4 Oct 2012 11:00:54 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id fm10so2184154wgb.1 for ; Thu, 04 Oct 2012 11:00: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=w4CpyFw1OJs/Q/qto5uw8tY+DlHCAsX5oXL+9QMtWAM=; b=WpnfGmhJ/IthP0OnTT+txymiSPxhnajiIRUv4qbITNa4eZbeovT73hU27Xp+G+QdSc s46a7xoHBXizp+z8g784GgiDE4cZD2C7mZMrqIj9wIK0L3bNjFLQp7Jo87CKPYAxRPzW K6f9ASu9cu/WL9iHdr+uN3ylSeWltvoxdPzv0PojNbAsBFItzE/zC5F82TxCoJvpsrEm X3Z+9FN+1933TLb+uYKBw16KjsZqWwbzCpMm2c3mebtVcr9IeShlRhpZcmo3uzL9wKdx f9pUenQJzcZgMZalA8t9vr2QMDDKNhbJt+GSP9eHPSzejHkjZrkKj5VZVa/rl66BrlXE MSGA== MIME-Version: 1.0 Received: by 10.180.73.76 with SMTP id j12mr14629457wiv.11.1349373653964; Thu, 04 Oct 2012 11:00:53 -0700 (PDT) Received: by 10.180.96.9 with HTTP; Thu, 4 Oct 2012 11:00:53 -0700 (PDT) In-Reply-To: <506D4F7A.5020109@alvestrand.no> References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <506D4F7A.5020109@alvestrand.no> Date: Thu, 4 Oct 2012 11:00:53 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 18:00:55 -0000 On 4 October 2012 09:57, Harald Alvestrand wrote: > For the Web use case, I think PRANSWER is an unnecessary distraction; if > we're writing both initiator and responder, multiple O/A rounds, or use of > multiple PeerConnections, is a much cleaner solution for the use cases I can > wrap my head around. I'd remove that qualifier. We currently have a draft that describes both cloning AND PRANSWER, both of which are more cleanly addressed by either multiple O/A rounds or multiple independent sessions. The two things that these provide is PRANSWER: The ability to describe a session that includes receipt capabilities that are a superset of send capabilities. SDP O/A doesn't really provide a way for me to describe this because the default assumption is that items not appearing in the answer are no longer needed. With something like bundle involved, we could split m= lines into sendonly and recvonly portions to allow for this case to be provided. CLONING: The ability to use the same transport primitives to interact with multiple peers. Ostensibly, this is to prepare for a session, with only one continuing to completion, mainly to reduce clipping. By adding candidates from all serial offenders to the same answer, you can get ICE setup, though I doubt that DTLS handshakes will be able to complete unless we permit multiple a=fingerprint lines and a few other things. I'm still disinclined to support this feature. Let the forkers have clipping. Both of these complicate the API significantly. I'd rather see the complexity pushed to the applications that need this complexity. That is, unless you are willing to consider a better API that makes these issues SEP. From christer.holmberg@ericsson.com Thu Oct 4 11:21:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A9521F8661 for ; Thu, 4 Oct 2012 11:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.808 X-Spam-Level: X-Spam-Status: No, score=-5.808 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPZilUFeHBEi for ; Thu, 4 Oct 2012 11:21:26 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id CA58C11E80E1 for ; Thu, 4 Oct 2012 11:21:24 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-b4-506dd3a339aa Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B4.0A.25676.3A3DD605; Thu, 4 Oct 2012 20:21:23 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Thu, 4 Oct 2012 20:21:23 +0200 From: Christer Holmberg To: Martin Thomson , Harald Alvestrand Date: Thu, 4 Oct 2012 20:21:22 +0200 Thread-Topic: [rtcweb] JSEP: Relaxing SDP O/A rules? Thread-Index: Ac2iWjXSYW+MEZhGQze7n9Bl7WSeEAAAGpH2 Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <506D4F7A.5020109@alvestrand.no>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvre7iy7kBBnMPmVsc6+tis7h25h+j xdp/7ewOzB5XJlxh9dg56y67x5IlP5kCmKO4bFJSczLLUov07RK4Mrb8n8Nc8FSwYsabkAbG ZXxdjJwcEgImEnfO/WWFsMUkLtxbz9bFyMUhJHCKUWLRxn5WCGc2o8SdnzOBMhwcbAIWEt3/ tEEaRAQiJY4cOcsOYjMLqEvcWXwOzGYRUJFof9HLCGILCxhLdH4+xgRRbyKxZscaFgjbSGLV jIlgNbwC4RKrjm+AWjybWWLRjg6wIk6BQImjy56ADWUEuu77qTVMEMvEJW49mc8EcbWAxJI9 55khbFGJl4//sULUi0rcaV/PCFGvI7Fg9yc2CFtbYtnC18wQiwUlTs58wjKBUWwWkrGzkLTM QtIyC0nLAkaWVYzCuYmZOenlRnqpRZnJxcX5eXrFqZsYgfF0cMtv1R2Md86JHGKU5mBREue1 3rrHX0ggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPj/JLOPz+3yZ9+s91Fg60mzWmnmYKowLwP byyf8XzeYcWSOoND2ZTJLiiPecfNvuqrTyO3HP4op3VStHTRZB4j4xXTM43PXrY9wpnMIZMm HpdTL11Z43yt94JxztK38pr5qjNyd6fOP7Pr28vpX1WcA/Z1n9vWVvbgYN/0hnCppm3h85Ot 2hKUWIozEg21mIuKEwH7+jnRdQIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 18:21:28 -0000 Hi, >> For the Web use case, I think PRANSWER is an unnecessary distraction; if >> we're writing both initiator and responder, multiple O/A rounds, or use = of >> multiple PeerConnections, is a much cleaner solution for the use cases I= can >> wrap my head around. > > I'd remove that qualifier. We currently have a draft that describes > both cloning AND PRANSWER, both of which are more cleanly addressed by > either multiple O/A rounds or multiple independent sessions. > >PRANSWER: >The ability to describe a session that includes receipt capabilities >that are a superset of send capabilities. SDP O/A doesn't really >provide a way for me to describe this because the default assumption >is that items not appearing in the answer are no longer needed. >With something like bundle involved, we could split m=3D lines into >sendonly and recvonly portions to allow for this case to be provided. I don't think the reason for PRANSWER comes from SDP O/A as such. It's more= about supporting serial forking. >CLONING: >The ability to use the same transport primitives to interact with >multiple peers. Ostensibly, this is to prepare for a session, with >only one continuing to completion, mainly to reduce clipping. >By adding candidates from all serial offenders to the same answer, you >can get ICE setup, though I doubt that DTLS handshakes will be able to >complete unless we permit multiple a=3Dfingerprint lines and a few other >things. I'm still disinclined to support this feature. Let the >forkers have clipping. If you want to support parallel forking, you need to be able to simultanous= ly perform ICE etc with all remote peers. >Both of these complicate the API significantly. I'd rather see the >complexity pushed to the applications that need this complexity. I want to be able to support forking. Exactly HOW it's done can be discusse= d. Also, I can live without support of parallel forking, and I don't really ca= re if serial forking support is provided using cloning or being able to upd= ate the remote descriptor (using PRANSWER, or something else). >That is, unless you are willing to consider a better API that makes >these issues SEP. You have one in mind? ;) Regards, Christer= From martin.thomson@gmail.com Thu Oct 4 11:43:57 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DC721F86DE for ; Thu, 4 Oct 2012 11:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wx0mEfGeg7In for ; Thu, 4 Oct 2012 11:43:56 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAF021F86DC for ; Thu, 4 Oct 2012 11:43:56 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so593129wey.31 for ; Thu, 04 Oct 2012 11:43: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=puGXgGkVg9JITjouOp5/wz984UDuh2pgGUxO5VAyNcw=; b=yLJLH9BTTr3s4mf7kTDvZaYmraUvdl2aveC3h/xOorv2yGoDEbSPai/whghxXjDbh2 raAb8b0hIwY4MpHqjHU9N1rjpdiRFJlBwcWYQBNdp9pc111cLgq2ICmAeHyButreFevm msIb2x4/yljcug99rnzV9KzztO6W7mpaGwXknobf2MYbLwDm5pRKNjD218rbKEo8YHiN 3p8qmNogb+Y3OSRqQVDBl8qV6iqTiUHgNN0P6hwChuh57M8r6THuKR/+WTT61G+/VV6q omKgXzoJdlFM0rVi3LvH/Tr+vUoW0rta7QnzDyi4Pw5uKJOnNHvsO/TzgMCIIKgSarP9 Si2A== MIME-Version: 1.0 Received: by 10.216.141.16 with SMTP id f16mr4153669wej.130.1349376235326; Thu, 04 Oct 2012 11:43:55 -0700 (PDT) Received: by 10.180.96.9 with HTTP; Thu, 4 Oct 2012 11:43:55 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <506D4F7A.5020109@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 4 Oct 2012 11:43:55 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 18:43:57 -0000 On 4 October 2012 11:21, Christer Holmberg wrote: > I don't think the reason for PRANSWER comes from SDP O/A as such. It's more about supporting serial forking. Not my point. My point is that the desired functionality (apply the answer without invalidating the offer) cannot be easily provided using SDP O/A. Most scenarios leave the possibility that the offerer sends the (provisional) answerer stuff that the answerer doesn't want. > If you want to support parallel forking, you need to be able to simultanously perform ICE etc with all remote peers. Right. You can almost get that by pretending that it's just one remote peer with lots of candidates. You can at least get to the consent point by doing that. But you aren't going to nominate more than one pair. Similarly, this will only generate a single DTLS session. Media is a complete mess if you manage to get that far. Unless you like scenarios were A and hear B and C, but B and C can't hear each other and other such joys (there's a consent issue too, but it's a minor issue of scale). >>Both of these complicate the API significantly. I'd rather see the >>complexity pushed to the applications that need this complexity. > > I want to be able to support forking. Exactly HOW it's done can be discussed. One approach is to create as many RTCPeerConnection objects as you feel might be needed. Then it becomes YOUR problem, not our problem. And those are the sorts of problem I like ;) (I might be interested in forking too, but I'm happy to keep my problems private.) > Also, I can live without support of parallel forking, and I don't really care if serial forking support is provided using cloning or being able to update the remote descriptor (using PRANSWER, or something else). Serial forking is potentially far easier to support by doing a series of O/A exchanges: 10: setLocal(offer) 20: get next answer 30: setRemote(answer) 40: goto 10 There's the small matter of having no guarantee that the offer will set successfully, but I'd consider that an unlikely scenario in practice. >>That is, unless you are willing to consider a better API that makes >>these issues SEP. > > You have one in mind? ;) I am not at liberty to disclose that information. From fluffy@cisco.com Thu Oct 4 16:16:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF12E21F8549 for ; Thu, 4 Oct 2012 16:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.513 X-Spam-Level: X-Spam-Status: No, score=-110.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OVqtLSuzdCS for ; Thu, 4 Oct 2012 16:16:04 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 36A6E21F854F for ; Thu, 4 Oct 2012 16:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=855; q=dns/txt; s=iport; t=1349392564; x=1350602164; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7fTKt5PzfZGXNJS9JrnaO9A1JBzGCRI1uBiFhgl3tYk=; b=izVI51CsbJ09tNnHPrakkU6XKZzpNNG5I+8a14NQ/XXKQ3s389ZXmXs3 A4D7PIAFhqHaEIbNkYw37ZV6DT6tpe60RmpVVt4lOsEp30gfMfuUuaXUe voBMpe4twB5pOfdGC0M7ObwOnGhO75pnTairutypXSiuf9BHZsCjE3arJ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAGsXblCtJXHB/2dsb2JhbABFhUi5UoEIgiABAQEDAQEBAQ8BJzQLEAIBCCIUECcLJQIEDgUIGoddBguYFqAJBIs+hSlgA6QsgWmCbYIX X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="128488202" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 04 Oct 2012 23:16:03 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q94NG3NE013296 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Oct 2012 23:16:03 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.62]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.001; Thu, 4 Oct 2012 18:16:03 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [rtcweb] JSEP: Relaxing SDP O/A rules? Thread-Index: AQHNooY5nrTR6y3qjU6/t/XSAiQTKg== Date: Thu, 4 Oct 2012 23:16:03 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19238.000 x-tm-as-result: No--33.667200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <8ACBC6F027EA324FB033B4FE345934DA@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 23:16:05 -0000 I'm going to get back to this thread at some point but as we pointed out be= fore, some of the text on this in the draft is just wrong. I'm trying to so= rt out some of the key things on what basic SDP looks like for rtcweb befor= e getting back to the PRANSWER stuff.=20 On Oct 2, 2012, at 12:00 PM, Christer Holmberg wrote: > =20 > Hi, > =20 > One of the arguments for the Microsoft API proposal was regarding the JSE= P usage of SDP Offer/Answer. > =20 > There has also been ideas about JSEP "relaxing" the SDP O/A rules. > =20 > What is the current status of that? Is the intention to "relax" something= ? > =20 > Regards, > =20 > Christer > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Fri Oct 5 00:39:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848F421F8602 for ; Fri, 5 Oct 2012 00:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.11 X-Spam-Level: X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzK7J-cvlnV4 for ; Fri, 5 Oct 2012 00:39:22 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 269E321F85F3 for ; Fri, 5 Oct 2012 00:39:18 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-e6-506e8ea53926 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 80.CC.11467.5AE8E605; Fri, 5 Oct 2012 09:39:18 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Fri, 5 Oct 2012 09:39:18 +0200 From: Christer Holmberg To: Martin Thomson Date: Fri, 5 Oct 2012 09:39:16 +0200 Thread-Topic: [rtcweb] JSEP: Relaxing SDP O/A rules? Thread-Index: Ac2iYDVKE9KFhrq+Ri+b5tNOgTV0GwAAPI1f Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A7BD0C5@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <506D4F7A.5020109@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvre6yvrwAg5kreC2O9XWxWVw784/R Yu2/dnYHZo8rE66weuycdZfdY8mSn0wBzFFcNimpOZllqUX6dglcGV82LGUsOCZW0TJZqoHx pmAXIyeHhICJxMq+nawQtpjEhXvr2boYuTiEBE4xSnyc+wzKmc8o0XrhO0sXIwcHm4CFRPc/ bZAGEQFdiUVnH7CD2MwCwRK9XZPBBrEIqEi8PXCbBcQWFjCW6Px8jAmi3kRizY41LBC2kcSZ nnmMIDavQLjE15U3WSF2bWCR+HLgKBtIglMgUOLvzTVgRYxA130/tYYJYpm4xK0n85kgrhaQ WLLnPDOELSrx8vE/Voh6UYk77esZIep1JBbs/sQGYWtLLFv4mhlisaDEyZlPWCYwis1CMnYW kpZZSFpmIWlZwMiyilE4NzEzJ73cUC+1KDO5uDg/T684dRMjMJ4Obvmtu4Px1DmRQ4zSHCxK 4rxcSfv9hQTSE0tSs1NTC1KL4otKc1KLDzEycXAC40K49GaFi8YOywlhcmdeW39yXb+4o685 vq5coi4q5OWTGOZv+/wF/1u/yXlS/K2tx/rmoufOf/fEFTptzJyY4qx/XiPZdBpHoWxM4Wu1 LTMXH9CV3Hl4wiGh01KRe0u3bdC6bFP/k0mX4/mXyKr41IlpR1OsM/Rr5RKPSTXb5MXoH0s5 MuGLjBJLcUaioRZzUXEiAFMrEtB1AgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 07:39:24 -0000 Hi, >> I don't think the reason for PRANSWER comes from SDP O/A as such. It's m= ore about supporting serial forking. > > Not my point. My point is that the desired functionality (apply the > answer without invalidating the offer) cannot be easily provided using > SDP O/A. Most scenarios leave the possibility that the offerer sends > the (provisional) answerer stuff that the answerer doesn't want. > >> If you want to support parallel forking, you need to be able to simultan= ously perform ICE etc with all remote peers. > > Right. You can almost get that by pretending that it's just one > remote peer with lots of candidates. You can at least get to the > consent point by doing that. But you aren't going to nominate more > than one pair. Similarly, this will only generate a single DTLS > session. I was thinking about the same once, but I think I found some issues (unfort= unately they don't come to my mind at the moment). But, it's for sure an alternative we could look into. That would allow ICE to take place during the early session, but media migh= t be more tricky - unless you also add the m- lines of each remote peer to = the "pretended" single peer. > Media is a complete mess if you manage to get that far. Unless you > like scenarios were A and hear B and C, but B and C can't hear each > other and other such joys (there's a consent issue too, but it's a > minor issue of scale). > >>>Both of these complicate the API significantly. I'd rather see the >>>complexity pushed to the applications that need this complexity. >> >> I want to be able to support forking. Exactly HOW it's done can be discu= ssed. > > One approach is to create as many RTCPeerConnection objects as you > feel might be needed. Then it becomes YOUR problem, not our problem. > And those are the sorts of problem I like ;) (I might be interested > in forking too, but I'm happy to keep my problems private.) > >> Also, I can live without support of parallel forking, and I don't really= care if serial forking support is provided using cloning or being able to = update the remote descriptor (using PRANSWER, or something else). > > Serial forking is potentially far easier to support by doing a series > of O/A exchanges: > 10: setLocal(offer) > 20: get next answer > 30: setRemote(answer) > 40: goto 10 > There's the small matter of having no guarantee that the offer will > set successfully, but I'd consider that an unlikely scenario in > practice. Can I use the same local descriptor for every setLocal() call? >>>That is, unless you are willing to consider a better API that makes >>>these issues SEP. >> >> You have one in mind? ;) > > I am not at liberty to disclose that information. Can you then at least tell me when I'll be able to buy the Microsoft Surfac= e? :) Regards, Christer From christer.holmberg@ericsson.com Fri Oct 5 05:41:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A5D21F8645; Fri, 5 Oct 2012 05:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.912 X-Spam-Level: X-Spam-Status: No, score=-4.912 tagged_above=-999 required=5 tests=[AWL=-1.063, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2fTsBDAm+-U; Fri, 5 Oct 2012 05:41:44 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDF621F8630; Fri, 5 Oct 2012 05:41:43 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-c4-506ed5866dc6 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 32.83.17130.685DE605; Fri, 5 Oct 2012 14:41:42 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Fri, 5 Oct 2012 14:41:42 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" , mmusic WG , Harald Tveit Alvestrand , Justin Uberti , Eric Rescorla , Bernard Aboba , Jonathan Lennox , Randell Jesup Date: Fri, 5 Oct 2012 14:41:40 +0200 Thread-Topic: path forward on bundle Thread-Index: AQHNovTwIf3O/3MMMESi6UaijuNjf5eqpRiw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A7BD37B@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM+JvrW7b1bwAg32XpC32L7nMbLHi9Tl2 i47JbBbH+rrYLPYvPs9ssXWqkMXU5Y9ZLDZ9OchssfZfO7sDp8eVCVdYPab83sjqsWBTqcfj njNsHkuW/GTy6DvQxeox+XEbs0fbszvsARxRXDYpqTmZZalF+nYJXBl9W5uZCharVpzbM4Ol gbFLuouRk0NCwERiXsNbNghbTOLCvfVANheHkMApRokZF89COfMZJRZcWcbSxcjBwSZgIdH9 TxskLiKwl0li0vHbjCDdzALqEncWn2MHsVkEVCQuzLrEDGILA9k3+jrBakQEVCUeLL3OAmEb SbyZf5YVxOYVCJe48/YoWI2QgI/Erj/nwWo4BXwl9j3qBYszAl33/dQaJohd4hK3nsxngrha QGLJnvPMELaoxMvH/1gh6kUl7rSvh7pNR2LB7k9sELa2xLKFr5kh9gpKnJz5hGUCo9gsJGNn IWmZhaRlFpKWBYwsqxiFcxMzc9LLzfVSizKTi4vz8/SKUzcxAiP34JbfBjsYN90XO8QozcGi JM6rp7rfX0ggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAMj8+KStYJquaeluwNyix133DjO7+J+ vbtWeWPefB/mhasEHCq5e31UChNdtTLFe46dUPCfx10z7Y/rzaN5m0oEZ0yftn06T6KVz5q2 vz+dA75qLD1mJNVhubXsxv/+Dywfahbe2tnYv4x1ooDI1DdNmYp8PlPkF8fVK/KYZU/YxLC4 +MHqA2VKLMUZiYZazEXFiQAEuMcCqgIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] path forward on bundle X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 12:41:45 -0000 Hi, >I'm trying to figure out how to move forward on bundle stuff. Let me start= by summarizing what I think the three proposals are then we can try and so= rt out pros/cons of each. I think we agree that the goals here is to have s= omething that gets the SDP so=20 >that we can negotiate using less ports.=20 > >I see it as we have three proposed solutions that I will call "a=3Dbundle = same port", "a=3Dbundle different port", and "m=3Dbundle". I'll try and de= scribe these below to make sure we are on same page of what the three are t= hen we can try and figurer out=20 >pros/cons of each and what to do. I'll give examples of the SDP offer for = each but I tried and make everything simple, I'm going to ignore the RTCP m= ux and such but I think you can see how that would get added to all the exa= mples.=20 > > >First lets set the baseline of an offer that does not want to multiplex th= e audio and video on same port=20 > v=3D0 > o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.com > s=3D > c=3DIN IP4 host.atlanta.example.com > t=3D0 0 > m=3Daudio 49170 RTP/AVP 0=20 > a=3Dmid:foo > a=3Drtpmap:0 PCMU/8000 > m=3Dvideo 49172 RTP/AVP 31=20 > a=3Dmid:bar > a=3Drtpmap:31 H261/90000 Correct. >Proposal "a=3Dbundle same port" > v=3D0 > o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.com > s=3D > c=3DIN IP4 host.atlanta.example.com > t=3D0 0 > a=3Dgroup:BUNDLE foo bar > m=3Daudio 49170 RTP/AVP 0=20 > a=3Dmid:foo > a=3Drtpmap:0 PCMU/8000 > m=3Dvideo 49170 RTP/AVP 31=20 > a=3Dmid:bar > a=3Drtpmap:31 H261/90000 > > In the above example, note that all the m lines for a mid identified in t= he group:BUNLDE have the same port (49170) Correct. This is what is currently described in draft-bundle. >Proposal "a=3Dbundle different port" > v=3D0 > o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.com > s=3D > c=3DIN IP4 host.atlanta.example.com > t=3D0 0 > a=3Dgroup:BUNDLE foo bar > m=3Daudio 49170 RTP/AVP 0=20 > a=3Dmid:foo > a=3Drtpmap:0 PCMU/8000 > m=3Dvideo 49172 RTP/AVP 31=20 > a=3Dmid:bar > a=3Drtpmap:31 H261/90000 > In the above example, note that the port numbers are the same as baseline= - if you device receiving this offer does not support group:BUNLDE, then t= his is identical to the baseline. So one m line has a port of 49170 and the= other has a different port.=20 > Other than that, it is the same as the "a=3Dbundle same port". The semant= ics of group:BUNLDE would be defined to be that if the SDP receiver support= s BUNDLE and wants to use it, then it places a group:BUNDLE line in the ans= wer and it send all the media=20 > to the mids in the in BUNDLE group to the port number identified for the = m-line corresponding to the first mid in the BUNDLE group. In this example,= the first mid on the a=3Dgroup:BUNDLE lines is foo, which has a m line wit= h a port of 49170, so both the=20 > H261 and PCMU (mids foo and bar) would go to port 49170 if the device cre= ating the answer wanted to use BUNDLE. We don't have a draft yet that says = exactly this thought it is very close to the one-rtp draft ( and for that m= atter close to bundle draft ) This is more or less Harald's original proposal. >Proposal "m=3Dbundle" > v=3D0 > o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.com > s=3D > c=3DIN IP4 host.atlanta.example.com > t=3D0 0 > a=3Dgroup:BUNDLE foo bar baz=20 > m=3Daudio 49170 RTP/AVP 0=20 > a=3Dmid:foo > a=3Drtpmap:0 PCMU/8000 > m=3Dvideo 49172 RTP/AVP 31=20 > a=3Dmid:bar > a=3Drtpmap:31 H261/90000 > m=3Dbundle 10000 RTP/AVP 0 8 97 31 32 > a=3Dmid:baz > a=3Dfull-rtpmap:0 audio/PCMU/8000 > a=3Dfull-rtpmap:31 video/H261/90000 > > > Note in the above example the SDP above the m=3Dbundle line is pretty muc= h the same as the baseline + the group:BUNDLE line. The m=3Dbundle is new m= edia type that indicates many things are bundled together on port 10000. A = device that understood=20 > bundle would know to ignore the m lines corresponding to foo and bar mids= and would just use the stuff from the bas mid.=20 Correct. Later today, we are planning to submit an individual draft (ie *no= t* a new version of draft-bundle) on this alternative, so that people have = some text to look at. Regards, Christer From harald@alvestrand.no Fri Oct 5 05:55:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DAF21F86DF; Fri, 5 Oct 2012 05:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.324 X-Spam-Level: X-Spam-Status: No, score=-109.324 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpGAktS2lfL3; Fri, 5 Oct 2012 05:55:40 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id BE06A21F86DC; Fri, 5 Oct 2012 05:55:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EFC4539E1D0; Fri, 5 Oct 2012 14:55:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVh3vnGAf-8X; Fri, 5 Oct 2012 14:55:33 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 4589A39E1BD; Fri, 5 Oct 2012 14:55:33 +0200 (CEST) Message-ID: <506ED8C4.6080409@alvestrand.no> Date: Fri, 05 Oct 2012 14:55:32 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Jonathan Lennox , mmusic WG , Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] path forward on bundle X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 12:55:41 -0000 On 10/05/2012 02:28 PM, Cullen Jennings (fluffy) wrote: > I'm trying to figure out how to move forward on bundle stuff. Let me st= art by summarizing what I think the three proposals are then we can try a= nd sort out pros/cons of each. I think we agree that the goals here is to= have something that gets the SDP so that we can negotiate using less por= ts. > > I see it as we have three proposed solutions that I will call "a=3Dbund= le same port", "a=3Dbundle different port", and "m=3Dbundle". I'll try a= nd describe these below to make sure we are on same page of what the thre= e are then we can try and figurer out pros/cons of each and what to do. I= 'll give examples of the SDP offer for each but I tried and make everythi= ng simple, I'm going to ignore the RTCP mux and such but I think you can = see how that would get added to all the examples. > > > First lets set the baseline of an offer that does not want to multiplex= the audio and video on same port > v=3D0 > o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.c= om > s=3D > c=3DIN IP4 host.atlanta.example.com > t=3D0 0 > m=3Daudio 49170 RTP/AVP 0 > a=3Dmid:foo > a=3Drtpmap:0 PCMU/8000 > m=3Dvideo 49172 RTP/AVP 31 > a=3Dmid:bar > a=3Drtpmap:31 H261/90000 > > > > Proposal "a=3Dbundle same port" > v=3D0 > o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.c= om > s=3D > c=3DIN IP4 host.atlanta.example.com > t=3D0 0 > a=3Dgroup:BUNDLE foo bar > m=3Daudio 49170 RTP/AVP 0 > a=3Dmid:foo > a=3Drtpmap:0 PCMU/8000 > m=3Dvideo 49170 RTP/AVP 31 > a=3Dmid:bar > a=3Drtpmap:31 H261/90000 > > In the above example, note that all the m lines for a mid identified in= the group:BUNLDE have the same port (49170) No issue so far. > > > > Proposal "a=3Dbundle different port" > v=3D0 > o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.c= om > s=3D > c=3DIN IP4 host.atlanta.example.com > t=3D0 0 > a=3Dgroup:BUNDLE foo bar > m=3Daudio 49170 RTP/AVP 0 > a=3Dmid:foo > a=3Drtpmap:0 PCMU/8000 > m=3Dvideo 49172 RTP/AVP 31 > a=3Dmid:bar > a=3Drtpmap:31 H261/90000 > > In the above example, note that the port numbers are the same as baseli= ne - if you device receiving this offer does not support group:BUNLDE, th= en this is identical to the baseline. So one m line has a port of 49170 a= nd the other has a different port. Other than that, it is the same as the= "a=3Dbundle same port". The semantics of group:BUNLDE would be defined t= o be that if the SDP receiver supports BUNDLE and wants to use it, then i= t places a group:BUNDLE line in the answer and it send all the media to t= he mids in the in BUNDLE group to the port number identified for the m-li= ne corresponding to the first mid in the BUNDLE group. In this example, t= he first mid on the a=3Dgroup:BUNDLE lines is foo, which has a m line wit= h a port of 49170, so both the H261 and PCMU (mids foo and bar) would go = to port 49170 if the device creating the answer wanted to use BUNDLE. We = don't have a draft yet that says exactly this thought it is very close to= the one-rtp draft ( and for that matter close to bundle draft ) I believe this is the mechanism described in=20 draft-alvestrand-one-rtp-02, or at least what it was intended to say. So = we can use the name "a=3Dgroup:together" for this without risk of confusi= on. > > > > Proposal "m=3Dbundle" > v=3D0 > o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.c= om > s=3D > c=3DIN IP4 host.atlanta.example.com > t=3D0 0 > a=3Dgroup:BUNDLE foo bar baz > m=3Daudio 49170 RTP/AVP 0 > a=3Dmid:foo > a=3Drtpmap:0 PCMU/8000 > m=3Dvideo 49172 RTP/AVP 31 > a=3Dmid:bar > a=3Drtpmap:31 H261/90000 > m=3Dbundle 10000 RTP/AVP 0 8 97 31 32 > a=3Dmid:baz > a=3Dfull-rtpmap:0 audio/PCMU/8000 > a=3Dfull-rtpmap:31 video/H261/90000 > > > Note in the above example the SDP above the m=3Dbundle line is pretty m= uch the same as the baseline + the group:BUNDLE line. The m=3Dbundle is n= ew media type that indicates many things are bundled together on port 100= 00. A device that understood bundle would know to ignore the m lines corr= esponding to foo and bar mids and would just use the stuff from the bas m= id. Yep. I've suggested calling it "m=3Danytype", but Christer hasn't adopted= =20 that so far :-) > > > So before we start discussing the pros / cons of theses three approache= s, let's spend a few days and make sure that I have correctly characteriz= ed the three approaches under discussion. > > Did I get it right? Do we need more explanation of any of these to see = how they work? > > Lets keep clarifications only on this thread and I'll start a separate = thread for pro/cons once we get this a bit clearer. Remember to change the subject line to a descriptive one for the next=20 thread :-) > > > > > > > > > From fluffy@cisco.com Fri Oct 5 05:28:36 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C111E21F8496; Fri, 5 Oct 2012 05:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.399 X-Spam-Level: X-Spam-Status: No, score=-109.399 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bxnrNTEYfJc; Fri, 5 Oct 2012 05:28:36 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E6A3C21F846D; Fri, 5 Oct 2012 05:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4750; q=dns/txt; s=iport; t=1349440116; x=1350649716; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=82X8XN0T1Fx75ATY/XDPCJoLZOrmkNsjaQkk+ORFspA=; b=fqRRq5Z3sxUgfxRxUaJToX9isXihWGPDx9Gh/9+bf9PaYk7pm+6jxc/1 e3xRcPLhOH4gsF82drkGcz3zsQA/FGHbL3+56dEBulvEwhRZPqkLoaIkU pIf6cLvF8Q6ocQ6/31SZmQYers9ohulO4MrXnO8v5SJdTvvZ7PJ9zTZYj s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMHRblCtJXG+/2dsb2JhbABFvx6BCIIiAQQSASc/EgEqFEIfCAQBDQ0TB4djmDqgCJBnYAOXAI0wgWmCbYIX X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="125640566" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 05 Oct 2012 12:28:35 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q95CSZ0W019845 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Oct 2012 12:28:35 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.62]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Fri, 5 Oct 2012 07:28:34 -0500 From: "Cullen Jennings (fluffy)" To: mmusic WG , "Cullen Jennings (fluffy)" , Harald Tveit Alvestrand , "Justin Uberti" , Eric Rescorla , Christer Holmberg , Bernard Aboba , Jonathan Lennox , Randell Jesup Thread-Topic: path forward on bundle Thread-Index: AQHNovTwIf3O/3MMMESi6UaijuNjfw== Date: Fri, 5 Oct 2012 12:28:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19242.001 x-tm-as-result: No--37.820000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 05 Oct 2012 06:36:59 -0700 Cc: "rtcweb@ietf.org" Subject: [rtcweb] path forward on bundle X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 12:28:36 -0000 I'm trying to figure out how to move forward on bundle stuff. Let me start = by summarizing what I think the three proposals are then we can try and sor= t out pros/cons of each. I think we agree that the goals here is to have so= mething that gets the SDP so that we can negotiate using less ports.=20 I see it as we have three proposed solutions that I will call "a=3Dbundle s= ame port", "a=3Dbundle different port", and "m=3Dbundle". I'll try and des= cribe these below to make sure we are on same page of what the three are th= en we can try and figurer out pros/cons of each and what to do. I'll give e= xamples of the SDP offer for each but I tried and make everything simple, I= 'm going to ignore the RTCP mux and such but I think you can see how that w= ould get added to all the examples.=20 First lets set the baseline of an offer that does not want to multiplex the= audio and video on same port=20 v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.com s=3D c=3DIN IP4 host.atlanta.example.com t=3D0 0 m=3Daudio 49170 RTP/AVP 0=20 a=3Dmid:foo a=3Drtpmap:0 PCMU/8000 m=3Dvideo 49172 RTP/AVP 31=20 a=3Dmid:bar a=3Drtpmap:31 H261/90000 Proposal "a=3Dbundle same port" v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.com s=3D c=3DIN IP4 host.atlanta.example.com t=3D0 0 a=3Dgroup:BUNDLE foo bar m=3Daudio 49170 RTP/AVP 0=20 a=3Dmid:foo a=3Drtpmap:0 PCMU/8000 m=3Dvideo 49170 RTP/AVP 31=20 a=3Dmid:bar a=3Drtpmap:31 H261/90000 In the above example, note that all the m lines for a mid identified in the= group:BUNLDE have the same port (49170) Proposal "a=3Dbundle different port" v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.com s=3D c=3DIN IP4 host.atlanta.example.com t=3D0 0 a=3Dgroup:BUNDLE foo bar m=3Daudio 49170 RTP/AVP 0=20 a=3Dmid:foo a=3Drtpmap:0 PCMU/8000 m=3Dvideo 49172 RTP/AVP 31=20 a=3Dmid:bar a=3Drtpmap:31 H261/90000 In the above example, note that the port numbers are the same as baseline -= if you device receiving this offer does not support group:BUNLDE, then thi= s is identical to the baseline. So one m line has a port of 49170 and the o= ther has a different port. Other than that, it is the same as the "a=3Dbund= le same port". The semantics of group:BUNLDE would be defined to be that if= the SDP receiver supports BUNDLE and wants to use it, then it places a gro= up:BUNDLE line in the answer and it send all the media to the mids in the i= n BUNDLE group to the port number identified for the m-line corresponding t= o the first mid in the BUNDLE group. In this example, the first mid on the = a=3Dgroup:BUNDLE lines is foo, which has a m line with a port of 49170, so = both the H261 and PCMU (mids foo and bar) would go to port 49170 if the dev= ice creating the answer wanted to use BUNDLE. We don't have a draft yet tha= t says exactly this thought it is very close to the one-rtp draft ( and for= that matter close to bundle draft ) Proposal "m=3Dbundle" v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.com s=3D c=3DIN IP4 host.atlanta.example.com t=3D0 0 a=3Dgroup:BUNDLE foo bar baz=20 m=3Daudio 49170 RTP/AVP 0=20 a=3Dmid:foo a=3Drtpmap:0 PCMU/8000 m=3Dvideo 49172 RTP/AVP 31=20 a=3Dmid:bar a=3Drtpmap:31 H261/90000 m=3Dbundle 10000 RTP/AVP 0 8 97 31 32 a=3Dmid:baz a=3Dfull-rtpmap:0 audio/PCMU/8000 a=3Dfull-rtpmap:31 video/H261/90000 Note in the above example the SDP above the m=3Dbundle line is pretty much = the same as the baseline + the group:BUNDLE line. The m=3Dbundle is new med= ia type that indicates many things are bundled together on port 10000. A de= vice that understood bundle would know to ignore the m lines corresponding = to foo and bar mids and would just use the stuff from the bas mid.=20 So before we start discussing the pros / cons of theses three approaches, l= et's spend a few days and make sure that I have correctly characterized the= three approaches under discussion.=20 Did I get it right? Do we need more explanation of any of these to see how = they work?=20 Lets keep clarifications only on this thread and I'll start a separate thre= ad for pro/cons once we get this a bit clearer.=20 From harald@alvestrand.no Fri Oct 5 10:11:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB32221F87AF for ; Fri, 5 Oct 2012 10:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.399 X-Spam-Level: X-Spam-Status: No, score=-110.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7GMHY2GqSes for ; Fri, 5 Oct 2012 10:11:10 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 089B221F875E for ; Fri, 5 Oct 2012 10:11:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 08F9239E1D0 for ; Fri, 5 Oct 2012 19:11:08 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VDAD9irnGH7 for ; Fri, 5 Oct 2012 19:11:07 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id D3F3A39E1BD for ; Fri, 5 Oct 2012 19:11:06 +0200 (CEST) Message-ID: <506F14AA.5020802@alvestrand.no> Date: Fri, 05 Oct 2012 19:11:06 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.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 Subject: Re: [rtcweb] Resolving whether to support additional key management methods X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 17:11:10 -0000 On 10/04/2012 05:32 PM, Ted Hardie wrote: > The Chairs would like to foster resolution of the long-running > discussion of support for additional key management methods, e.g. as > described in draft-ohlsson-rtcweb-sdes-support and the meeting > materials supporting draft-ietf-avtcore-srtp-ekt. Working group > discussion of this matter is, of course, welcome, but the chairs are > also considering a virtual interim meeting in January of 2013, focused > on this specific topic. Comments on this plan or on the relevant > approaches is welcome. What is the proposed outcome space of this discussion? We already have a decision of "MUST do DTLS(-SRTP)", but I'm not sure what the other questions are. I could see the result of the SDES discussion being one of: - MUST do SDES - SHOULD do SDES - MAY do SDES - MUST NOT do SDES I also see another discussion around EKT, which could conclude - MUST do EKT - MAY do EKT - MUST NOT do EKT (I don't see much point in "SHOULD do EKT" - it doesn't give interoperability, so is not much more useful than MAY) Are there other things on the table? Are both of the above on the table? > > regards, > > Ted, Cullen, Magnus > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Fri Oct 5 10:13:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134BB21F87BA for ; Fri, 5 Oct 2012 10:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.419 X-Spam-Level: X-Spam-Status: No, score=-110.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3oR66u3fs5k for ; Fri, 5 Oct 2012 10:13:13 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4992821F87B8 for ; Fri, 5 Oct 2012 10:13:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 55B6639E1D0; Fri, 5 Oct 2012 19:13:12 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CY9DDStXKhdA; Fri, 5 Oct 2012 19:13:11 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7CEC939E1BD; Fri, 5 Oct 2012 19:13:11 +0200 (CEST) Message-ID: <506F1526.4050306@alvestrand.no> Date: Fri, 05 Oct 2012 19:13:10 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <506D4F7A.5020109@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 17:13:14 -0000 On 10/04/2012 08:21 PM, Christer Holmberg wrote: > Hi, > >>> For the Web use case, I think PRANSWER is an unnecessary distraction; if >>> we're writing both initiator and responder, multiple O/A rounds, or use of >>> multiple PeerConnections, is a much cleaner solution for the use cases I can >>> wrap my head around. >> I'd remove that qualifier. We currently have a draft that describes >> both cloning AND PRANSWER, both of which are more cleanly addressed by >> either multiple O/A rounds or multiple independent sessions. >> >> PRANSWER: >> The ability to describe a session that includes receipt capabilities >> that are a superset of send capabilities. SDP O/A doesn't really >> provide a way for me to describe this because the default assumption >> is that items not appearing in the answer are no longer needed. >> With something like bundle involved, we could split m= lines into >> sendonly and recvonly portions to allow for this case to be provided. > I don't think the reason for PRANSWER comes from SDP O/A as such. It's more about supporting serial forking. I've asked that question before, but I don't remember seeing an answer from people who know what they're talking about: Does serial forking, as practiced by SIP UAs, violate the SDP O/A model, or does it not violate the SDP O/A model? I don't understand how it, in the form that has been described as "what we have to support", can be SDP O/A compatible, but then there are many things about SIP that I don't understand, so I may understand it when it's explained to me. Harald From martin.thomson@gmail.com Fri Oct 5 10:14:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93EEC21F8604 for ; Fri, 5 Oct 2012 10:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.691 X-Spam-Level: X-Spam-Status: No, score=-3.691 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhTSRsaytx5w for ; Fri, 5 Oct 2012 10:14:18 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9036221F85E6 for ; Fri, 5 Oct 2012 10:14:17 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so1141140lam.31 for ; Fri, 05 Oct 2012 10:14: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=YKhMY48rMUGmMbxUoWw5yVqzrBKlOQwb1iiEP2s2nvo=; b=aMVbwBElpf7GOBFBjAOhYbsLvYe5Y1KMJdFKvN84Zwr1d5ryUxKDVSWLHgWC0T8aUH V0N9MwZ/YdeC6HeOttGg5MI52a3M7ORIi3/h/L/kd2+Nd927WTZP/4d4aeOiuZJ7kOQv vapaxV40cXf6dx5mSJl7fuWXLwEIoNYcLcnhlzEBuZyJ1ISPABdat85LAKKtxSj7qRFp 68ZOZwQPluUjGFtu0CFs8BoJA+w50XOQmUK7nGP22yr67MkzaYmhK51T8YvTIttzP1CM /oloTZXKwl7DKK8BLtXBO3M/iW9eksDZ7qvXL1lZmDqpBL/egcszh78zB7YzlzpzhDIh KXYQ== MIME-Version: 1.0 Received: by 10.112.40.227 with SMTP id a3mr3902932lbl.91.1349457256563; Fri, 05 Oct 2012 10:14:16 -0700 (PDT) Received: by 10.112.83.2 with HTTP; Fri, 5 Oct 2012 10:14:16 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A7BD0C5@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <506D4F7A.5020109@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BD0C5@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 5 Oct 2012 10:14:16 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 17:14:18 -0000 On 5 October 2012 00:39, Christer Holmberg wrote: >>> If you want to support parallel forking, you need to be able to simultanously perform ICE etc with all remote peers. >> >> Right. You can almost get that by pretending that it's just one >> remote peer with lots of candidates. You can at least get to the >> consent point by doing that. But you aren't going to nominate more >> than one pair. Similarly, this will only generate a single DTLS >> session. > > I was thinking about the same once, but I think I found some issues (unfortunately they don't come to my mind at the moment). It's probably not going to be flawless, true. As you say, media would be a little crazy. You might be able to get one media stream out of it - not multiple. > Can I use the same local descriptor for every setLocal() call? My experience suggests that you can. However, that's not stipulated in the API specification, so it's not an ironclad guarantee. > Can you then at least tell me when I'll be able to buy the Microsoft Surface? :) Yes. When they release it. October 25 apparently. From roman@telurix.com Fri Oct 5 10:46:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC67621F87C9 for ; Fri, 5 Oct 2012 10:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHo-p97J4RTg for ; Fri, 5 Oct 2012 10:46:30 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id DBDAF21F87C1 for ; Fri, 5 Oct 2012 10:46:29 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so2160002pbb.31 for ; Fri, 05 Oct 2012 10:46:26 -0700 (PDT) X-Google-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:x-gm-message-state; bh=ZmTn0Hnq31UY7BsLS+2RZvBsXmNAgjxWBkwfNHUxeJ4=; b=ePla3lhPz2aOVovLEGIus49hbZsU5ULZWdC6GPIuxKc3Mbn9L+TR4Ii94s41/rDJ7/ x390gfcrjBzd0vOdT5g82grb206zGIS4ylGfHg3+GEfJLBC/clR8k8PcgKZnE1KdCj8T +i3VgwZJgQHqXaGtfOhPlb+00YDUpGHsfTUZT0B15uqxbqUXVM82SJMCy2a2V1mjQEOI KIhXGRSvLwTxq8XT06WJE9Dp43kR4rwmFTkUVW5wpgXSfelD2VrqgP5eM8+n77ZHFXtz +lXCjb9c6CQc7cJrslxhHCvc8P4m6Zd166G+UFAq4kvF96GO4sjXUwIi5vP8CThlkHOl Wx0A== Received: by 10.68.213.138 with SMTP id ns10mr32460184pbc.157.1349459186032; Fri, 05 Oct 2012 10:46:26 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by mx.google.com with ESMTPS id f9sm6340134paz.1.2012.10.05.10.46.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 10:46:25 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so2090525pad.31 for ; Fri, 05 Oct 2012 10:46:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.73.6 with SMTP id h6mr23311181pav.69.1349459183548; Fri, 05 Oct 2012 10:46:23 -0700 (PDT) Received: by 10.68.42.8 with HTTP; Fri, 5 Oct 2012 10:46:23 -0700 (PDT) In-Reply-To: <506F1526.4050306@alvestrand.no> References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <506D4F7A.5020109@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> <506F1526.4050306@alvestrand.no> Date: Fri, 5 Oct 2012 13:46:23 -0400 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=f46d042f9f2a4639ea04cb5373d7 X-Gm-Message-State: ALoCoQl9NqyHfdB4bum+NmO00JgMvusKXijpQc6FR6NSQyMBbTLgwIZmNIFd3+WBSh+zChdLfV1F Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 17:46:31 -0000 --f46d042f9f2a4639ea04cb5373d7 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 5, 2012 at 1:13 PM, Harald Alvestrand wrote: > I've asked that question before, but I don't remember seeing an answer > from people who know what they're talking about: > > Does serial forking, as practiced by SIP UAs, violate the SDP O/A model, > or does it not violate the SDP O/A model? > > I don't understand how it, in the form that has been described as "what we > have to support", can be SDP O/A compatible, but then there are many things > about SIP that I don't understand, so I may understand it when it's > explained to me. > > O/A does not describe multiple answers to a single offer. Nothing explicitly prohibits it there but I would argue this is not part of this specification. No standard document that I am aware of describes how serial O/A is supposed to work. Serial forking as practiced by SIP UA does violate SIP RFC 3261 which states that each dialog can only have one answer to each offer. If answer is sent in both provisional and final response, it should be the same. You can, however, create multiple dialogs with the same offer. This normally implies parallel forking, but the most common use case is with early media, where you end up with multiple early dialogs. For instance you call a phone number, phone network sends you SDP in early media and plays a dial tone, then the called number does not answer, and you get connected to a voice mail which uses a completely different SDP in final answer. According to SIP these answers should come with different to-tags and technically would be parts of two different dialogs. What makes this a bit tricky is when the phone network and the voice mail are behind SBC (or some other sort of B2BUA) you only see one dialog which send you multiple answers to the same offer. This scenario is so common that it is more likely to be implemented then parallel forking. This is why PRANSWER was suggested. If cloning can be implemented in WebRTC it would be more standard compliant then PRANSWER and would allow for a lot more use cases. Typical difficulty in parallel forking implementation in SIP is due to RTP from multiple sources coming to the same IP and port with no consent or notification to the receiving side. This makes it very difficult to present this media to the user. There is no way to tie media to actual dialogs since RTP can come from different IP and ports then specified in answer SDPs. This is not an issue with WebRTC where consent to receive media is required. I would argue let's implement cloning and not waste any more time on PRANSWER which in my opinion will always stay a half working hack. _____________ Roman Shpount --f46d042f9f2a4639ea04cb5373d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 5, 2012 at 1:13 PM= , Harald Alvestrand <harald@alvestrand.no> wrote:
I've asked that question before, but I don't remember seeing an ans= wer from people who know what they're talking about:

Does serial forking, as practiced by SIP UAs, violate the SDP O/A model, or= does it not violate the SDP O/A model?

I don't understand how it, in the form that has been described as "= ;what we have to support", can be SDP O/A compatible, but then there a= re many things about SIP that I don't understand, so I may understand i= t when it's explained to me.


O/A does not describe multiple answ= ers to a single offer. Nothing explicitly prohibits it there but I would ar= gue this is not part of this specification. No standard document that I am = aware of describes how serial O/A is supposed to work. Serial forking as pr= acticed by SIP UA does violate SIP RFC 3261 which states that each dialog c= an only have one answer to each offer. If answer is sent in both provisiona= l and final response, it should be the same. You can, however, create multi= ple dialogs with the same offer. This normally implies parallel forking, bu= t the most common use case is with early media, where you end up with multi= ple early dialogs. For instance you call a phone number, phone network send= s you SDP in early media and plays a dial tone, then the called number does= not answer, and you get connected to a voice mail which uses a completely = different SDP in final answer. According to SIP these answers should come w= ith different to-tags and technically would be parts of two different dialo= gs. What makes this a bit tricky is when the phone network and the voice ma= il are behind SBC (or some other sort of B2BUA) you only see one dialog whi= ch send you multiple answers to the same offer. This scenario is so common = that it is more likely to be implemented then parallel forking. This is why= PRANSWER was suggested.

If cloning can be implemented in WebRTC it would be more standard compl= iant then PRANSWER and would allow for a lot more use cases. Typical diffic= ulty in parallel forking implementation in SIP is due to RTP from multiple = sources coming to the same IP and port with no consent or notification to t= he receiving side. This makes it very difficult to present this media to th= e user. There is no way to tie media to actual dialogs since RTP can come f= rom different IP and ports then specified in answer SDPs. This is not an is= sue with WebRTC where consent to receive media is required. I would argue l= et's implement cloning and not waste any more time on PRANSWER which in= my opinion will always stay a half working hack.
_____________
Roman Shpount

--f46d042f9f2a4639ea04cb5373d7-- From ted.ietf@gmail.com Fri Oct 5 11:14:08 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6885C21F8440 for ; Fri, 5 Oct 2012 11:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRHwSx6bWgb8 for ; Fri, 5 Oct 2012 11:14:07 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7987E21F8435 for ; Fri, 5 Oct 2012 11:14:07 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so2645370vcb.31 for ; Fri, 05 Oct 2012 11:14:07 -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=YdMNaTYwZUkxyBm3SkpD9/XigHwaLFgiSfWX4AIpUDA=; b=tMtvTc8n/rOmxMFmSTd/6AasuwvThas8cRdH1TcGUh0sJZgA3FD1hr5ISY+oO4dq1b TlIDzxV/mU+lndEkH8oixrOHe+7vr0Kgvd7KLo5h6fUZ37js0ZoW0x7+o3XaCBchcBTC PnPErUr0KvHRdBlGz+Ye+1e70Ey6qE68X/Qb9Fhn54uLtUj97CJMgBhSkNRUYyXq4C5z ffojxVERbZsw4V2PiWs+4/6822CGdFt6aH5mxYE/cPgLnSdZJqzL+rmbu92E+aL+0mry tOrQLE9OplPqA+ddd7+xAHr5qKv0xwyucukbVcRn21DcCWbaLmfgVyCOIzzxX8Uw44Ti KzGA== MIME-Version: 1.0 Received: by 10.220.220.7 with SMTP id hw7mr5592635vcb.17.1349460846976; Fri, 05 Oct 2012 11:14:06 -0700 (PDT) Received: by 10.58.245.39 with HTTP; Fri, 5 Oct 2012 11:14:06 -0700 (PDT) In-Reply-To: <506F14AA.5020802@alvestrand.no> References: <506F14AA.5020802@alvestrand.no> Date: Fri, 5 Oct 2012 11:14:06 -0700 Message-ID: From: Ted Hardie To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Resolving whether to support additional key management methods X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 18:14:08 -0000 On Fri, Oct 5, 2012 at 10:11 AM, Harald Alvestrand wrote: > On 10/04/2012 05:32 PM, Ted Hardie wrote: > What is the proposed outcome space of this discussion? > We already have a decision of "MUST do DTLS(-SRTP)", Yes, and we are not proposing to re-discuss whether this a MUST; we want to focus on whether there are additional proposals which have consensus. > but I'm not sure what > the other questions are. > > I could see the result of the SDES discussion being one of: > > - MUST do SDES > - SHOULD do SDES > - MAY do SDES > - MUST NOT do SDES > > I also see another discussion around EKT, which could conclude > > - MUST do EKT > - MAY do EKT > - MUST NOT do EKT > > (I don't see much point in "SHOULD do EKT" - it doesn't give > interoperability, so is not much more useful than MAY) > > Are there other things on the table? Are both of the above on the table? > Both of the above discussions have already started, and they have not concluded; we want to conclude them. If there are other proposals, they can be brought forward in the context of this discussion, provided they do not start with "let's ditch DTLS-(SRTP)". regards, Ted >> >> regards, >> >> Ted, Cullen, Magnus >> _______________________________________________ >> 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 kaiduanx@gmail.com Fri Oct 5 11:23:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2CCB21F87EC; Fri, 5 Oct 2012 11:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4VcNX7Mv41T; Fri, 5 Oct 2012 11:23:18 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id EC0B021F87EA; Fri, 5 Oct 2012 11:23:17 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so2440685obq.31 for ; Fri, 05 Oct 2012 11:23:17 -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=ppVEmYa6z+UkNXOn8bFkyY/dOAhNjPCtLAdNuLs1Iok=; b=hIq+Jmgscdi2/30uBCsR0Zf2XUwX2/12Upun6zADu2B/uP76BjJGZN7nyMCkDbyXPb JdUsnbAykWNotMaNzCtdAO6iQs/xqbAmdsOuwwj9x85qXp5VC6UKnnEvp+9io/mK58xl KGxxkqFB4XviTLNEa0XsGJ1MqJVQakDpn9R6f8f2Dqsnr0aDFT8NcxcsVLobKpJb0Tpv oUPZJH43pHm0ttB9FA9623pon/NN5V7nBDNpv7C+bAeW7MM3EO43fohDish/1ym74LO2 G2ToX51WXjLOwELC9XpKyCgjA45YY2txVNpCFQruOfyK8u6VKf5iDRC9oXfjvwC454OP 7Tyw== MIME-Version: 1.0 Received: by 10.60.0.169 with SMTP id 9mr7847606oef.94.1349461397572; Fri, 05 Oct 2012 11:23:17 -0700 (PDT) Received: by 10.76.23.129 with HTTP; Fri, 5 Oct 2012 11:23:17 -0700 (PDT) In-Reply-To: <506ED8C4.6080409@alvestrand.no> References: <506ED8C4.6080409@alvestrand.no> Date: Fri, 5 Oct 2012 14:23:17 -0400 Message-ID: From: Kaiduan Xie To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Cc: "Cullen Jennings \(fluffy\)" , Jonathan Lennox , Randell Jesup , mmusic WG , "rtcweb@ietf.org" Subject: Re: [rtcweb] path forward on bundle X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 18:23:18 -0000 "Note in the above example the SDP above the m=bundle line is pretty much the same as the baseline + the group:BUNDLE line. The m=bundle is new media type that indicates many things are bundled together on port 10000. A device that understood bundle would know to ignore the m lines corresponding to foo and bar mids and would just use the stuff from the bas mid." ^^^ Should it be baz mid? /Kaiduan On Fri, Oct 5, 2012 at 8:55 AM, Harald Alvestrand wrote: > On 10/05/2012 02:28 PM, Cullen Jennings (fluffy) wrote: >> >> I'm trying to figure out how to move forward on bundle stuff. Let me start >> by summarizing what I think the three proposals are then we can try and sort >> out pros/cons of each. I think we agree that the goals here is to have >> something that gets the SDP so that we can negotiate using less ports. >> >> I see it as we have three proposed solutions that I will call "a=bundle >> same port", "a=bundle different port", and "m=bundle". I'll try and >> describe these below to make sure we are on same page of what the three are >> then we can try and figurer out pros/cons of each and what to do. I'll give >> examples of the SDP offer for each but I tried and make everything simple, >> I'm going to ignore the RTCP mux and such but I think you can see how that >> would get added to all the examples. >> >> >> First lets set the baseline of an offer that does not want to multiplex >> the audio and video on same port >> v=0 >> o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com >> s= >> c=IN IP4 host.atlanta.example.com >> t=0 0 >> m=audio 49170 RTP/AVP 0 >> a=mid:foo >> a=rtpmap:0 PCMU/8000 >> m=video 49172 RTP/AVP 31 >> a=mid:bar >> a=rtpmap:31 H261/90000 >> >> >> >> Proposal "a=bundle same port" >> v=0 >> o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com >> s= >> c=IN IP4 host.atlanta.example.com >> t=0 0 >> a=group:BUNDLE foo bar >> m=audio 49170 RTP/AVP 0 >> a=mid:foo >> a=rtpmap:0 PCMU/8000 >> m=video 49170 RTP/AVP 31 >> a=mid:bar >> a=rtpmap:31 H261/90000 >> >> In the above example, note that all the m lines for a mid identified in >> the group:BUNLDE have the same port (49170) > > No issue so far. > >> >> >> >> Proposal "a=bundle different port" >> v=0 >> o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com >> s= >> c=IN IP4 host.atlanta.example.com >> t=0 0 >> a=group:BUNDLE foo bar >> m=audio 49170 RTP/AVP 0 >> a=mid:foo >> a=rtpmap:0 PCMU/8000 >> m=video 49172 RTP/AVP 31 >> a=mid:bar >> a=rtpmap:31 H261/90000 >> >> In the above example, note that the port numbers are the same as baseline >> - if you device receiving this offer does not support group:BUNLDE, then >> this is identical to the baseline. So one m line has a port of 49170 and the >> other has a different port. Other than that, it is the same as the "a=bundle >> same port". The semantics of group:BUNLDE would be defined to be that if the >> SDP receiver supports BUNDLE and wants to use it, then it places a >> group:BUNDLE line in the answer and it send all the media to the mids in the >> in BUNDLE group to the port number identified for the m-line corresponding >> to the first mid in the BUNDLE group. In this example, the first mid on the >> a=group:BUNDLE lines is foo, which has a m line with a port of 49170, so >> both the H261 and PCMU (mids foo and bar) would go to port 49170 if the >> device creating the answer wanted to use BUNDLE. We don't have a draft yet >> that says exactly this thought it is very close to the one-rtp draft ( and >> for that matter clo > > se to bundle draft ) > I believe this is the mechanism described in draft-alvestrand-one-rtp-02, or > at least what it was intended to say. So we can use the name > "a=group:together" for this without risk of confusion. > >> >> >> >> Proposal "m=bundle" >> v=0 >> o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com >> s= >> c=IN IP4 host.atlanta.example.com >> t=0 0 >> a=group:BUNDLE foo bar baz >> m=audio 49170 RTP/AVP 0 >> a=mid:foo >> a=rtpmap:0 PCMU/8000 >> m=video 49172 RTP/AVP 31 >> a=mid:bar >> a=rtpmap:31 H261/90000 >> m=bundle 10000 RTP/AVP 0 8 97 31 32 >> a=mid:baz >> a=full-rtpmap:0 audio/PCMU/8000 >> a=full-rtpmap:31 video/H261/90000 >> >> >> Note in the above example the SDP above the m=bundle line is pretty much >> the same as the baseline + the group:BUNDLE line. The m=bundle is new media >> type that indicates many things are bundled together on port 10000. A device >> that understood bundle would know to ignore the m lines corresponding to foo >> and bar mids and would just use the stuff from the bas mid. > > Yep. I've suggested calling it "m=anytype", but Christer hasn't adopted that > so far :-) > >> >> >> So before we start discussing the pros / cons of theses three approaches, >> let's spend a few days and make sure that I have correctly characterized the >> three approaches under discussion. >> >> Did I get it right? Do we need more explanation of any of these to see how >> they work? >> >> Lets keep clarifications only on this thread and I'll start a separate >> thread for pro/cons once we get this a bit clearer. > > Remember to change the subject line to a descriptive one for the next thread > :-) > >> >> >> >> >> >> >> >> >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Fri Oct 5 11:49:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B71F21F8528; Fri, 5 Oct 2012 11:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.319 X-Spam-Level: X-Spam-Status: No, score=-109.319 tagged_above=-999 required=5 tests=[AWL=-1.120, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZlPNSBCkrBp; Fri, 5 Oct 2012 11:49:00 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3EE21F842B; Fri, 5 Oct 2012 11:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6668; q=dns/txt; s=iport; t=1349462940; x=1350672540; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=REi2TERZC8kt9jiJM/IvIFuXEiIajqTLrvsHr5Y+kl0=; b=hhxtdlFSrxdIGsLcpILzlt+PyziHIhluhytS7uPi5FLuDOVW5QyYqIxL s9jDngLXEBBfORr/jZx3dzG8i/TkCptuOQmtxdT2zkaGZ7WgQqynFbbTG XOaF0h0dr1JZOVXodpuhau904IuZN9IxsdjAwd92uyzYJtXPn8WrlYcJl 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGUqb1CtJXG9/2dsb2JhbABFvyCBCIIgAQEBBAEBAQ8BWwsQAgEIGAokIQYLJQIEDgUIEweHUQMPC5heljANiVSKWGaFKWADiCOLc4Jqig6DIoFpgm2CFw X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="128819004" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 05 Oct 2012 18:49:00 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q95ImxYs027533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Oct 2012 18:48:59 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.62]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.001; Fri, 5 Oct 2012 13:48:59 -0500 From: "Cullen Jennings (fluffy)" To: Kaiduan Xie Thread-Topic: [rtcweb] path forward on bundle Thread-Index: AQHNoyaEp4nhhdwyxEuzOdZlbOlWD5erYa2A Date: Fri, 5 Oct 2012 18:48:59 +0000 Message-ID: References: <506ED8C4.6080409@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19242.001 x-tm-as-result: No--58.071700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <483558E4CF5F74448414E1D3F1C4175E@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , Randell Jesup , mmusic WG , Jonathan Lennox Subject: Re: [rtcweb] path forward on bundle X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 18:49:01 -0000 On Oct 5, 2012, at 12:23 PM, Kaiduan Xie wrote: > "Note in the above example the SDP above the m=3Dbundle line is pretty > much the same as the baseline + the group:BUNDLE line. The m=3Dbundle is > new media type that indicates many things are bundled together on port > 10000. A device that understood bundle would know to ignore the m > lines corresponding to foo and bar mids and would just use the stuff > from the bas mid." > ^^^ >=20 > Should it be baz mid? oops - yes - that should be baz , sorry >=20 > /Kaiduan >=20 > On Fri, Oct 5, 2012 at 8:55 AM, Harald Alvestrand = wrote: >> On 10/05/2012 02:28 PM, Cullen Jennings (fluffy) wrote: >>>=20 >>> I'm trying to figure out how to move forward on bundle stuff. Let me st= art >>> by summarizing what I think the three proposals are then we can try and= sort >>> out pros/cons of each. I think we agree that the goals here is to have >>> something that gets the SDP so that we can negotiate using less ports. >>>=20 >>> I see it as we have three proposed solutions that I will call "a=3Dbund= le >>> same port", "a=3Dbundle different port", and "m=3Dbundle". I'll try an= d >>> describe these below to make sure we are on same page of what the three= are >>> then we can try and figurer out pros/cons of each and what to do. I'll = give >>> examples of the SDP offer for each but I tried and make everything simp= le, >>> I'm going to ignore the RTCP mux and such but I think you can see how t= hat >>> would get added to all the examples. >>>=20 >>>=20 >>> First lets set the baseline of an offer that does not want to multiplex >>> the audio and video on same port >>> v=3D0 >>> o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.co= m >>> s=3D >>> c=3DIN IP4 host.atlanta.example.com >>> t=3D0 0 >>> m=3Daudio 49170 RTP/AVP 0 >>> a=3Dmid:foo >>> a=3Drtpmap:0 PCMU/8000 >>> m=3Dvideo 49172 RTP/AVP 31 >>> a=3Dmid:bar >>> a=3Drtpmap:31 H261/90000 >>>=20 >>>=20 >>>=20 >>> Proposal "a=3Dbundle same port" >>> v=3D0 >>> o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.co= m >>> s=3D >>> c=3DIN IP4 host.atlanta.example.com >>> t=3D0 0 >>> a=3Dgroup:BUNDLE foo bar >>> m=3Daudio 49170 RTP/AVP 0 >>> a=3Dmid:foo >>> a=3Drtpmap:0 PCMU/8000 >>> m=3Dvideo 49170 RTP/AVP 31 >>> a=3Dmid:bar >>> a=3Drtpmap:31 H261/90000 >>>=20 >>> In the above example, note that all the m lines for a mid identified in >>> the group:BUNLDE have the same port (49170) >>=20 >> No issue so far. >>=20 >>>=20 >>>=20 >>>=20 >>> Proposal "a=3Dbundle different port" >>> v=3D0 >>> o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.co= m >>> s=3D >>> c=3DIN IP4 host.atlanta.example.com >>> t=3D0 0 >>> a=3Dgroup:BUNDLE foo bar >>> m=3Daudio 49170 RTP/AVP 0 >>> a=3Dmid:foo >>> a=3Drtpmap:0 PCMU/8000 >>> m=3Dvideo 49172 RTP/AVP 31 >>> a=3Dmid:bar >>> a=3Drtpmap:31 H261/90000 >>>=20 >>> In the above example, note that the port numbers are the same as baseli= ne >>> - if you device receiving this offer does not support group:BUNLDE, the= n >>> this is identical to the baseline. So one m line has a port of 49170 an= d the >>> other has a different port. Other than that, it is the same as the "a= =3Dbundle >>> same port". The semantics of group:BUNLDE would be defined to be that i= f the >>> SDP receiver supports BUNDLE and wants to use it, then it places a >>> group:BUNDLE line in the answer and it send all the media to the mids i= n the >>> in BUNDLE group to the port number identified for the m-line correspond= ing >>> to the first mid in the BUNDLE group. In this example, the first mid on= the >>> a=3Dgroup:BUNDLE lines is foo, which has a m line with a port of 49170,= so >>> both the H261 and PCMU (mids foo and bar) would go to port 49170 if the >>> device creating the answer wanted to use BUNDLE. We don't have a draft = yet >>> that says exactly this thought it is very close to the one-rtp draft ( = and >>> for that matter clo >>=20 >> se to bundle draft ) >> I believe this is the mechanism described in draft-alvestrand-one-rtp-02= , or >> at least what it was intended to say. So we can use the name >> "a=3Dgroup:together" for this without risk of confusion. >>=20 >>>=20 >>>=20 >>>=20 >>> Proposal "m=3Dbundle" >>> v=3D0 >>> o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.co= m >>> s=3D >>> c=3DIN IP4 host.atlanta.example.com >>> t=3D0 0 >>> a=3Dgroup:BUNDLE foo bar baz >>> m=3Daudio 49170 RTP/AVP 0 >>> a=3Dmid:foo >>> a=3Drtpmap:0 PCMU/8000 >>> m=3Dvideo 49172 RTP/AVP 31 >>> a=3Dmid:bar >>> a=3Drtpmap:31 H261/90000 >>> m=3Dbundle 10000 RTP/AVP 0 8 97 31 32 >>> a=3Dmid:baz >>> a=3Dfull-rtpmap:0 audio/PCMU/8000 >>> a=3Dfull-rtpmap:31 video/H261/90000 >>>=20 >>>=20 >>> Note in the above example the SDP above the m=3Dbundle line is pretty m= uch >>> the same as the baseline + the group:BUNDLE line. The m=3Dbundle is new= media >>> type that indicates many things are bundled together on port 10000. A d= evice >>> that understood bundle would know to ignore the m lines corresponding t= o foo >>> and bar mids and would just use the stuff from the bas mid. >>=20 >> Yep. I've suggested calling it "m=3Danytype", but Christer hasn't adopte= d that >> so far :-) >>=20 >>>=20 >>>=20 >>> So before we start discussing the pros / cons of theses three approache= s, >>> let's spend a few days and make sure that I have correctly characterize= d the >>> three approaches under discussion. >>>=20 >>> Did I get it right? Do we need more explanation of any of these to see = how >>> they work? >>>=20 >>> Lets keep clarifications only on this thread and I'll start a separate >>> thread for pro/cons once we get this a bit clearer. >>=20 >> Remember to change the subject line to a descriptive one for the next th= read >> :-) >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Fri Oct 5 14:26:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A3C21F871A for ; Fri, 5 Oct 2012 14:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODxH3Mc9rUMu for ; Fri, 5 Oct 2012 14:26:40 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5728C21F870A for ; Fri, 5 Oct 2012 14:26:40 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-26-506f508ee05a Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 6F.86.25676.E805F605; Fri, 5 Oct 2012 23:26:38 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Fri, 5 Oct 2012 23:26:38 +0200 From: Christer Holmberg To: Roman Shpount , Harald Alvestrand Date: Fri, 5 Oct 2012 23:26:38 +0200 Thread-Topic: [rtcweb] JSEP: Relaxing SDP O/A rules? Thread-Index: Ac2jIl5U0vHy8cGURFCyHvO/YwW4ugAHP8MW Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FE4@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <506D4F7A.5020109@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> <506F1526.4050306@alvestrand.no>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+JvrW5fQH6AwcGn1hbH+rrYLGZcmMps sfZfO7sDs8eVCVdYPZYs+cnkcWtKQQBzFJdNSmpOZllqkb5dAlfGr9v7GQumSlZ0bJzE3sA4 WaSLkZNDQsBEYuHM/8wQtpjEhXvr2UBsIYFTjBIzWnO6GLmA7NmMEvu3r2DpYuTgYBOwkOj+ pw1SIyIQKPH88ARWEJtZQF3izuJz7CA2i4CKxNJXX8BsYQFjic7Px5gg6k0k1uxYwwJhG0ls uv6BEcTmFQiXuNK0kBFi12UWiXOfn4IdxAm04N+RjWBFjEDHfT+1hglimbjErSfzmSCOFpBY suc81AOiEi8f/2OFqBeVuNO+nhGiXk/ixtQpbBC2tsSyha+ZIRYLSpyc+YRlAqPYLCRjZyFp mYWkZRaSlgWMLKsYhXMTM3PSy430Uosyk4uL8/P0ilM3MQKj6eCW36o7GO+cEznEKM3BoiTO a711j7+QQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxjXzPbe1+Z405X/I9ujYsePfJBjESxIY 71g9fbr8OFvnkglXFM9mVJnG3+Av9zSwYu4s1omoKtat/MecYb7aO/df9GvDUnHfgpCL2xN6 uFinCH2/eXducOdHW/WqWOnj0oJrZAK2cYdt2iOxdVrMBCWTjVYvhGb91VvPvkLc5GSS4cXS gtlflFiKMxINtZiLihMB/57c/nQCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 21:26:41 -0000 Hi, Roman is correct. The SDP O/A doesn't consider forking, because each forked SIP leg creates a= unique early dialog, and each early dialog has its own O/A state machine. Regards, Christer ________________________________ From: Roman Shpount [roman@telurix.com] Sent: Friday, October 05, 2012 8:46 PM To: Harald Alvestrand Cc: Christer Holmberg; rtcweb@ietf.org Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? On Fri, Oct 5, 2012 at 1:13 PM, Harald Alvestrand > wrote: I've asked that question before, but I don't remember seeing an answer from= people who know what they're talking about: Does serial forking, as practiced by SIP UAs, violate the SDP O/A model, or= does it not violate the SDP O/A model? I don't understand how it, in the form that has been described as "what we = have to support", can be SDP O/A compatible, but then there are many things= about SIP that I don't understand, so I may understand it when it's explai= ned to me. O/A does not describe multiple answers to a single offer. Nothing explicitl= y prohibits it there but I would argue this is not part of this specificati= on. No standard document that I am aware of describes how serial O/A is sup= posed to work. Serial forking as practiced by SIP UA does violate SIP RFC 3= 261 which states that each dialog can only have one answer to each offer. I= f answer is sent in both provisional and final response, it should be the s= ame. You can, however, create multiple dialogs with the same offer. This no= rmally implies parallel forking, but the most common use case is with early= media, where you end up with multiple early dialogs. For instance you call= a phone number, phone network sends you SDP in early media and plays a dia= l tone, then the called number does not answer, and you get connected to a = voice mail which uses a completely different SDP in final answer. According= to SIP these answers should come with different to-tags and technically wo= uld be parts of two different dialogs. What makes this a bit tricky is when= the phone network and the voice mail are behind SBC (or some other sort of= B2BUA) you only see one dialog which send you multiple answers to the same= offer. This scenario is so common that it is more likely to be implemented= then parallel forking. This is why PRANSWER was suggested. If cloning can be implemented in WebRTC it would be more standard compliant= then PRANSWER and would allow for a lot more use cases. Typical difficulty= in parallel forking implementation in SIP is due to RTP from multiple sour= ces coming to the same IP and port with no consent or notification to the r= eceiving side. This makes it very difficult to present this media to the us= er. There is no way to tie media to actual dialogs since RTP can come from = different IP and ports then specified in answer SDPs. This is not an issue = with WebRTC where consent to receive media is required. I would argue let's= implement cloning and not waste any more time on PRANSWER which in my opin= ion will always stay a half working hack. _____________ Roman Shpount From christer.holmberg@ericsson.com Fri Oct 5 14:31:03 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5450521F8692 for ; Fri, 5 Oct 2012 14:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axxYol4gx2m3 for ; Fri, 5 Oct 2012 14:31:02 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 501B021F864A for ; Fri, 5 Oct 2012 14:31:02 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-a5-506f5195ae49 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 69.C6.25676.5915F605; Fri, 5 Oct 2012 23:31:01 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 5 Oct 2012 23:31:00 +0200 From: Christer Holmberg To: Martin Thomson Date: Fri, 5 Oct 2012 23:26:59 +0200 Thread-Topic: [rtcweb] JSEP: Relaxing SDP O/A rules? Thread-Index: Ac2jHNmSiGoPoyvRSteGrpcBNsQtAgAI03ch Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FE5@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <506D4F7A.5020109@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BD0C5@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvre7UwPwAg0m7ZS2O9XWxWVw784/R Yu2/dnYHZo8rE66weuycdZfdY8mSn0wBzFFcNimpOZllqUX6dglcGRPe72AueMZZ0b/PuoHx MnsXIyeHhICJxMrTR6FsMYkL99azgdhCAqcYJd7djOxi5AKy5zNK3Gq8BFTEwcEmYCHR/U8b pEZEQFdi0dkHYL3MAsESvV2TWUFsFgEVibnb54HZwgLGEp2fjzFB1JtIrNmxhgXCNpK4Om8J mM0rEC4x4cVPVohdR1klfh/8CdbAKRAosam1gRHEZgQ67vupNUwQy8Qlbj2ZzwRxtIDEkj3n mSFsUYmXj/+xQtSLStxpX88IUa8jsWD3JzYIW1ti2cLXzBCLBSVOznzCMoFRbBaSsbOQtMxC 0jILScsCRpZVjMK5iZk56eVGeqlFmcnFxfl5esWpmxiB0XRwy2/VHYx3zokcYpTmYFES57Xe usdfSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2PG+kntR99vXjhTfzlzWp38mh/7trNvU9ec Wfab8xOXma5E5sonZz0fHu6av/9x8Laidx7LvOy2ixm4pAb2x52cevbHupUbuHaIiH/kuZnz 8riUXOfUf295CztWL392SWW27dkitt9JSdOc3Cv2/fCRTZlqnbm4yMgxNeC8Z0WLwwGlHVz3 /ixRYinOSDTUYi4qTgQA6RGWd3QCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 21:31:03 -0000 Hi, >>>> If you want to support parallel forking, you need to be able to simult= anously perform ICE etc with all remote peers. >>> >>> Right. You can almost get that by pretending that it's just one >>> remote peer with lots of candidates. You can at least get to the >>> consent point by doing that. But you aren't going to nominate more >>> than one pair. Similarly, this will only generate a single DTLS >>> session. >> >> I was thinking about the same once, but I think I found some issues (unf= ortunately they don't come to my mind at the moment). > > It's probably not going to be flawless, true. As you say, media would > be a little crazy. You might be able to get one media stream out of > it - not multiple. And, I guess it would still require to be able to update the answer, as add= itional early dialogs (with associated remote ICE candidates) may be create= d. >> Can I use the same local descriptor for every setLocal() call? > > My experience suggests that you can. However, that's not stipulated > in the API specification, so it's not an ironclad guarantee. If it doesn't, and a new local descripor is created, you would need to send= that one to the remote endpoint. Regards, Christer= From martin.thomson@gmail.com Fri Oct 5 16:19:59 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF16F21F8605 for ; Fri, 5 Oct 2012 16:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.925 X-Spam-Level: X-Spam-Status: No, score=-3.925 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFW-Mt4Ics4z for ; Fri, 5 Oct 2012 16:19:59 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id F0A6121F85F9 for ; Fri, 5 Oct 2012 16:19:58 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so1929788lbo.31 for ; Fri, 05 Oct 2012 16:19: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=HIW8kW62zVDIjQP6FFVBdkBQlGtJluR+9h4ChY2gFXQ=; b=Wo3kDHZMKbLuEE6bjreYBVk+++CSxYoZ747IA8LpmaunPtAYkA7/kt3bpa39cL78qC PTMzOQZIrgsvPqwyQSj4Mk6pr+5mqwndrGzNsuMdUeJilP3ev1om6GSOPzmP6pfpLIW4 u29IPGWV7rNb6lil2jT8Pj1V1nOVh9AIvVwwpF+DJPlEkwab65cQIGtM2bmSKXZIpCRx qMdPFqu/P8P6Z9vhe91V1gvDMdSvkPq5AQBRY9H8v6Kvjv+lAFjyf3dXhShgavd593MQ A6pRqQpmsQNG4lLMHE3P5T7vHzGacWKAb+x0M6bJ1ThCPQORMlhfs4xahoxyZWkH9x28 8bYw== MIME-Version: 1.0 Received: by 10.112.14.161 with SMTP id q1mr10037lbc.123.1349479197735; Fri, 05 Oct 2012 16:19:57 -0700 (PDT) Received: by 10.112.83.2 with HTTP; Fri, 5 Oct 2012 16:19:57 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FE5@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <506D4F7A.5020109@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BD0C5@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FE5@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 5 Oct 2012 16:19:57 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 23:19:59 -0000 On 5 October 2012 14:26, Christer Holmberg wrote: >>> Can I use the same local descriptor for every setLocal() call? >> >> My experience suggests that you can. However, that's not stipulated >> in the API specification, so it's not an ironclad guarantee. > > If it doesn't, and a new local descripor is created, you would need to send that one to the remote endpoint. You don't create a new description, you just set one. The only problem arises when you can't set the local description because something broke since you last set it. (Maybe setting the answer caused the browser to release something that you need to set the offer.) If that happens, you are hosed. You could try to make a new PeerConnection, but you'll have to resend your INVITE because you will get a new set of candidates, ufrag, pwd, etc... From partha@parthasarathi.co.in Fri Oct 5 22:56:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB5021F865C for ; Fri, 5 Oct 2012 22:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVf4jsCKEPjU for ; Fri, 5 Oct 2012 22:56:32 -0700 (PDT) Received: from outbound-us1.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.231]) by ietfa.amsl.com (Postfix) with ESMTP id 62D8121F8550 for ; Fri, 5 Oct 2012 22:56:26 -0700 (PDT) Received: from userPC (unknown [122.179.34.7]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us1.mailhostbox.com (Postfix) with ESMTPA id C8EA91908721; Sat, 6 Oct 2012 05:56:11 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1349502976; bh=lRSHmS9bzTjSUPjiHAxggvucprlIMhmu9bixVXTmDt4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=R4TrzjYz6/qLAi2iC8j4gJVwfPkDkBMgpSUnaUJ8siDe4SDkwm2IZkgG6Mof8yuk6 AwR1Si6R+0tjCfS8sggCYDq5wgS+2iuu9qJ6sfU5r3CSF+haML+8dOs5NlxDldszjF ztNsu1miSDbqsKwOVwWoeh86n0wVj4hCdZgRG/kM= From: "Parthasarathi R" To: "'Christer Holmberg'" , "'Roman Shpount'" , "'Harald Alvestrand'" References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <506D4F7A.5020109@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> <506F1526.4050306@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2FE4@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FE4@ESESSCMS0356.eemea.ericsson.se> Date: Sat, 6 Oct 2012 11:26:06 +0530 Message-ID: <000701cda387$4abc4fa0$e034eee0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2jIl5U0vHy8cGURFCyHvO/YwW4ugAHP8MWABGg9BA= Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A020208.506FC800.00C2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 05:56:33 -0000 We discussed earlier that PRANSWER states complicates SIP offer/answer mechanism as the mapping with SIP offer/answer is not well defined. For Example: "UPDATE with SDP from SIP UAS after sending 18x with SDP has to be considered as PRANSWER or OFFER or ANSWER in originating JSEP side" ? I agree with Roman that Cloning is the solution for serial forking as well. Thanks Partha -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Saturday, October 06, 2012 2:57 AM To: Roman Shpount; Harald Alvestrand Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Hi, Roman is correct. The SDP O/A doesn't consider forking, because each forked SIP leg creates a unique early dialog, and each early dialog has its own O/A state machine. Regards, Christer ________________________________ From: Roman Shpount [roman@telurix.com] Sent: Friday, October 05, 2012 8:46 PM To: Harald Alvestrand Cc: Christer Holmberg; rtcweb@ietf.org Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? On Fri, Oct 5, 2012 at 1:13 PM, Harald Alvestrand > wrote: I've asked that question before, but I don't remember seeing an answer from people who know what they're talking about: Does serial forking, as practiced by SIP UAs, violate the SDP O/A model, or does it not violate the SDP O/A model? I don't understand how it, in the form that has been described as "what we have to support", can be SDP O/A compatible, but then there are many things about SIP that I don't understand, so I may understand it when it's explained to me. O/A does not describe multiple answers to a single offer. Nothing explicitly prohibits it there but I would argue this is not part of this specification. No standard document that I am aware of describes how serial O/A is supposed to work. Serial forking as practiced by SIP UA does violate SIP RFC 3261 which states that each dialog can only have one answer to each offer. If answer is sent in both provisional and final response, it should be the same. You can, however, create multiple dialogs with the same offer. This normally implies parallel forking, but the most common use case is with early media, where you end up with multiple early dialogs. For instance you call a phone number, phone network sends you SDP in early media and plays a dial tone, then the called number does not answer, and you get connected to a voice mail which uses a completely different SDP in final answer. According to SIP these answers should come with different to-tags and technically would be parts of two different dialogs. What makes this a bit tricky is when the phone network and the voice mail are behind SBC (or some other sort of B2BUA) you only see one dialog which send you multiple answers to the same offer. This scenario is so common that it is more likely to be implemented then parallel forking. This is why PRANSWER was suggested. If cloning can be implemented in WebRTC it would be more standard compliant then PRANSWER and would allow for a lot more use cases. Typical difficulty in parallel forking implementation in SIP is due to RTP from multiple sources coming to the same IP and port with no consent or notification to the receiving side. This makes it very difficult to present this media to the user. There is no way to tie media to actual dialogs since RTP can come from different IP and ports then specified in answer SDPs. This is not an issue with WebRTC where consent to receive media is required. I would argue let's implement cloning and not waste any more time on PRANSWER which in my opinion will always stay a half working hack. _____________ Roman Shpount _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Sat Oct 6 11:28:57 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DC021F84C5 for ; Sat, 6 Oct 2012 11:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.103 X-Spam-Level: X-Spam-Status: No, score=-6.103 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvDMMYIknO-J for ; Sat, 6 Oct 2012 11:28:56 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5063821F84C4 for ; Sat, 6 Oct 2012 11:28:56 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-9f-507078661f0c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F8.35.17130.66870705; Sat, 6 Oct 2012 20:28:54 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Sat, 6 Oct 2012 20:28:54 +0200 From: Christer Holmberg To: Parthasarathi R , 'Roman Shpount' , 'Harald Alvestrand' Date: Sat, 6 Oct 2012 20:24:40 +0200 Thread-Topic: [rtcweb] JSEP: Relaxing SDP O/A rules? Thread-Index: Ac2jIl5U0vHy8cGURFCyHvO/YwW4ugAHP8MWABGg9BAAGn4UwA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA5D@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <506D4F7A.5020109@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> <506F1526.4050306@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2FE4@ESESSCMS0356.eemea.ericsson.se>, <000701cda387$4abc4fa0$e034eee0$@co.in> In-Reply-To: <000701cda387$4abc4fa0$e034eee0$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+JvrW5aRUGAwa03ihbH+rrYLCZ/6mO1 mHFhKrPF2n/t7A4sHlcmXGH1WLLkJ5PHh/lf2D1uTSkIYInisklJzcksSy3St0vgylh0oY29 4JhixYwz09kbGPukuxg5OSQETCRWfr3HDGGLSVy4t56ti5GLQ0jgFKPEs4Y3zBDOHEaJ+6/+ sncxcnCwCVhIdP/TBomLCDQzSky8vIYFpJtZQF3izuJz7CA2i4CKxK0Fs8GmCgsYS3R+PsYE YosAbVuzA6SeA8h2krgwMxckzCsQLrH56yk2EFtI4AyrxJG1xiA2J1D5+7d7wcYwAh33/dQa JohV4hK3nsxngjhaQGLJnvNQD4hKvHz8jxWiXlTiTvt6Roh6HYkFuz+xQdjaEssWvmaG2Cso cXLmE5YJjGKzkIydhaRlFpKWWUhaFjCyrGIUzk3MzEkvN9dLLcpMLi7Oz9MrTt3ECIywg1t+ G+xg3HRf7BCjNAeLkjivnup+fyGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MGf07xLN9xe4E SwZyXbe3U7rhKG2t/uvF9guHHkRqnD4h3Khc0Phkg0/8QuH5+27eSt/feUt1yk79O1enLFPm +9prqcOqqvH++XKV+0sNVrosnOXdcCK94ExnUusZNw+vs+fkZ+74HR3dUmZwR5K72SSif1G9 7kS1Rq+cg9JiydeeaZi1Sy1RYinOSDTUYi4qTgQAkJ5nmH4CAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 18:28:57 -0000 Hi, >We discussed earlier that PRANSWER states complicates SIP offer/answer >mechanism as the mapping with SIP offer/answer is not well defined. For >Example: "UPDATE with SDP from SIP UAS after sending 18x with SDP has to b= e >considered as PRANSWER or OFFER or ANSWER in originating JSEP side" ? > >I agree with Roman that Cloning is the solution for serial forking as well= . If we support cloning (no matter whether it's a separate function call, or = simply creating a new session with the same local descriptor), I agree that= PRANSWER probably could be removed. At least I have never thought of any other use of it than to support serial= forking. Regards, Christer -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Saturday, October 06, 2012 2:57 AM To: Roman Shpount; Harald Alvestrand Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Hi, Roman is correct. The SDP O/A doesn't consider forking, because each forked SIP leg creates a unique early dialog, and each early dialog has its own O/A state machine. Regards, Christer ________________________________ From: Roman Shpount [roman@telurix.com] Sent: Friday, October 05, 2012 8:46 PM To: Harald Alvestrand Cc: Christer Holmberg; rtcweb@ietf.org Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? On Fri, Oct 5, 2012 at 1:13 PM, Harald Alvestrand > wrote: I've asked that question before, but I don't remember seeing an answer from people who know what they're talking about: Does serial forking, as practiced by SIP UAs, violate the SDP O/A model, or does it not violate the SDP O/A model? I don't understand how it, in the form that has been described as "what we have to support", can be SDP O/A compatible, but then there are many things about SIP that I don't understand, so I may understand it when it's explained to me. O/A does not describe multiple answers to a single offer. Nothing explicitl= y prohibits it there but I would argue this is not part of this specification= . No standard document that I am aware of describes how serial O/A is suppose= d to work. Serial forking as practiced by SIP UA does violate SIP RFC 3261 which states that each dialog can only have one answer to each offer. If answer is sent in both provisional and final response, it should be the same. You can, however, create multiple dialogs with the same offer. This normally implies parallel forking, but the most common use case is with early media, where you end up with multiple early dialogs. For instance you call a phone number, phone network sends you SDP in early media and plays a dial tone, then the called number does not answer, and you get connected to a voice mail which uses a completely different SDP in final answer. According to SIP these answers should come with different to-tags and technically would be parts of two different dialogs. What makes this a bit tricky is when the phone network and the voice mail are behind SBC (or some other sort of B2BUA) you only see one dialog which send you multiple answers to the same offer. This scenario is so common that it is more likely to be implemented then paralle= l forking. This is why PRANSWER was suggested. If cloning can be implemented in WebRTC it would be more standard compliant then PRANSWER and would allow for a lot more use cases. Typical difficulty in parallel forking implementation in SIP is due to RTP from multiple sources coming to the same IP and port with no consent or notification to the receiving side. This makes it very difficult to present this media to the user. There is no way to tie media to actual dialogs since RTP can come from different IP and ports then specified in answer SDPs. This is not an issue with WebRTC where consent to receive media is required. I would argue let's implement cloning and not waste any more time on PRANSWER which in my opinion will always stay a half working hack. _____________ Roman Shpount _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb= From christer.holmberg@ericsson.com Sat Oct 6 11:38:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E94721F8455 for ; Sat, 6 Oct 2012 11:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.105 X-Spam-Level: X-Spam-Status: No, score=-6.105 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7H1BO+eo7v4o for ; Sat, 6 Oct 2012 11:38:51 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8B421F8452 for ; Sat, 6 Oct 2012 11:38:51 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-e5-50707ab90304 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 23.49.25676.9BA70705; Sat, 6 Oct 2012 20:38:49 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sat, 6 Oct 2012 20:38:49 +0200 From: Christer Holmberg To: Martin Thomson Date: Sat, 6 Oct 2012 20:38:49 +0200 Thread-Topic: [rtcweb] JSEP: Relaxing SDP O/A rules? Thread-Index: Ac2jT++0dz09b0CmTciyh3RNj762sQAoJQ4b Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA5E@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <506D4F7A.5020109@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BD0C5@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FE5@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvre7OqoIAg+6/uhbH+rrYLK6d+cdo sfZfO7sDs8eVCVdYPXbOusvusWTJT6YA5igum5TUnMyy1CJ9uwSujNu/m1gK3nFWtKx/zNrA +Ji9i5GTQ0LARGLegW+MELaYxIV769m6GLk4hAROMUo8bT3GAuEsYJRYt76dtYuRg4NNwEKi +582SIOIgK7EorMPwAYxCwRL9HZNZgWxWQRUJBZsvs4CYgsLGEt0fj7GBFFvIrFmxxoWCNtI YuXUBWC9vALhErOOv2WE2HWLTWLq9LdgCU6BQIl3rW1sIDYj0HXfT61hglgmLnHryXwmiKsF JJbsOc8MYYtKvHz8jxWiXlTiTvt6Roh6HYkFuz+xQdjaEssWvmaGWCwocXLmE5YJjGKzkIyd haRlFpKWWUhaFjCyrGIUzk3MzEkvN9JLLcpMLi7Oz9MrTt3ECIyog1t+q+5gvHNO5BCjNAeL kjiv9dY9/kIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYeVtFOrc+Vzt2buvvRi6TpOBOwYd5 v0t0lqzfEWevV/6A/dcKjYi1u95s+ZJ7MchgxdSo2hMWT+VSDFN6Ct79WHp3lVm4q9SKfZ2t h7rPNd93sX7+Tj2CzU7L+9Qpmf3nN/5yWc76pefO312Ghoo181nLNk3sOFx3atPjm8rCz872 3vijqPCKSYmlOCPRUIu5qDgRAIP4T+92AgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 18:38:52 -0000 Hi, >>>> Can I use the same local descriptor for every setLocal() call? >>> >>> My experience suggests that you can. However, that's not stipulated >>> in the API specification, so it's not an ironclad guarantee. >> >> If it doesn't, and a new local descripor is created, you would need to s= end that one to the remote=20 >> endpoint. > > You don't create a new description, you just set one. Correct. > The only problem arises when you can't set the local description because > something broke since you last set it. (Maybe setting the answer > caused the browser to release something that you need to set the > offer.) That is the main difference between PRANSWER and ANSWER: PRANSWER does not = release local resources based on the answer. > If that happens, you are hosed. You could try to make a new PeerConnecti= on, but you'll have to resend your INVITE because you will > get a new set of candidates, ufrag, pwd, etc... Or, you could set the new local descriptor BEFORE you apply the answer to t= he previous one. I think that is how the cloning is currently described in = JSEP: the cloning happens first (eventhough it may never be used, if no add= itional remote peers are contacted). Regards, Christer= From salvatore.loreto@ericsson.com Mon Oct 8 01:22:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C644621F8753 for ; Mon, 8 Oct 2012 01:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.611 X-Spam-Level: X-Spam-Status: No, score=-106.611 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9cdSxVLfGrK for ; Mon, 8 Oct 2012 01:22:34 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 929BF21F8732 for ; Mon, 8 Oct 2012 01:22:33 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-ee-50728d48b74b Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A6.FE.25676.84D82705; Mon, 8 Oct 2012 10:22:32 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012 10:22:29 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B934922F6 for ; Mon, 8 Oct 2012 11:22:29 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 16B98538FC for ; Mon, 8 Oct 2012 11:22:29 +0300 (EEST) Received: from n94.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C9F2F53192 for ; Mon, 8 Oct 2012 11:22:28 +0300 (EEST) Message-ID: <50728D45.7000105@ericsson.com> Date: Mon, 8 Oct 2012 11:22:29 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUyM+Jvra5Hb1GAweFjqhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr49yRxawFE1grrvRtZ21gnM7SxcjJISFgIrHtywNmCFtM4sK9 9WxdjFwcQgKnGCW2TW1jh3DWM0oseD2DCcK5yCix5sZEKOcIo8Sbf/ugyvYwSlw+9ZkVZBiv gLbE/TfHwQazCKhItM84BxZnEzCTeP5wC1hcVCBZonf+TkaIekGJkzOfgB0lIiAssfVVLxOI LSwgLTHr1kewXmYBW4kLc66zQNjyEtvfzoE6XE3i6rlNYLaQgJZE79lOpgmMQrOQjJ2FpH0W kvYFjMyrGIVzEzNz0suN9FKLMpOLi/Pz9IpTNzECw/bglt+qOxjvnBM5xCjNwaIkzmu9dY+/ kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsZZB9I7DsTnbnrrf0FI9EbZ5BbuY+Z/ji7kzFL9 c6zh1d2YR2XL+g84M56cXe7/uX7SdknVvAgB7trfP1blTl5kUdG5bdvSPdySdw11ivn2a03i rVkkqZp0htuWVWoTc7rqc5fu6BvqM20/yv9Y/OHN830Wvvwi8tkmKipnmiMPrAn4qLri6RMl luKMREMt5qLiRACxV7utKQIAAA== Subject: [rtcweb] SDP and datachanel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Oct 2012 08:22:34 -0000 Hi there, I have just sent an email to the mmusic mailing list to restart the discussion of what should go in SDP for the SCTP (over DTLS) association setup: http://www.ietf.org/mail-archive/web/mmusic/current/msg09667.html In particular what is general enough to be inserted in the current wg item (http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp) and what is specific of the Datachannel protocol but needs to be eventually specified in a separate draft. Please go to the mmusic mailing list and discuss the (SDP related )issues there without cross-posting thanks Salvatore -- Salvatore Loreto, PhD www.sloreto.com From christer.holmberg@ericsson.com Mon Oct 8 01:57:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B13121F8712 for ; Mon, 8 Oct 2012 01:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.117 X-Spam-Level: X-Spam-Status: No, score=-6.117 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fqPn7j9Bfiu for ; Mon, 8 Oct 2012 01:57:11 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 414EE21F86EA for ; Mon, 8 Oct 2012 01:56:56 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-db-507295562289 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A3.AB.11467.65592705; Mon, 8 Oct 2012 10:56:55 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 8 Oct 2012 10:56:54 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Date: Mon, 8 Oct 2012 10:56:53 +0200 Thread-Topic: Draft new: draft-holmberg-mmusic-sdp-mmt-negotiation-00 Thread-Index: Ac2lMfyN5xbhjaInQoWNm7/ewW3hIAAALyvg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAD0313@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340BAD030B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAD030B@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_7F2072F1E0DE894DA4B517B93C6A0585340BAD0313ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM+JvrW741KIAg74VbBZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4+X+PewFFzQrPi03amC8r9rFyMkhIWAi8fPLa2YIW0ziwr31 bF2MXBxCAqcYJY6cO8IC4SxglNh0ayJTFyMHB5uAhUT3P22QBhEBdYnLDy+wg9gsAioSnYe6 WEBKhAVcJA7e9IcocZV4OOMXC4RtJNF8oZMRxOYVCJe4dPIKE4gtBGTvvz8RLM4pECGx9up9 VhCbEeie76fWgNUwC4hL3HoynwniThGJhxdPs0HYohIvH/+DqheVuNO+nhGiPlPi46ZDbBC7 BCVOznzCMoFRZBaSUbOQlM1CUgYRz5fYcXUNO4StI7Fg9yc2CFtbYtnC18ww9pkDj5kwxXUl jpw/BtWrKNG2vRmqdwWjxMs3cjDxKd0P2Rcw8qxiFM5NzMxJLzfUSy3KTC4uzs/TK07dxAiM 2YNbfuvuYDx1TuQQozQHi5I4L1fSfn8hgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjFq7zY5H iy5M+O6cyJl/fs+Nrrt9eQuNfP9/k/9ddfj23YhE47UHxUSW6m3at+7D49BV1RHeTks3nNZd tOrG//bmRiWVroKYjCOiGebBbMseeHyd+zts51Q/k7MlplxXzPdYrl2gveNE33ou025p98cZ Zd6OitGySswLLm8rNFmjtLDa/Y2dnhJLcUaioRZzUXEiALpjSuWnAgAA Subject: [rtcweb] FW: Draft new: draft-holmberg-mmusic-sdp-mmt-negotiation-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Oct 2012 08:57:12 -0000 --_004_7F2072F1E0DE894DA4B517B93C6A0585340BAD0313ESESSCMS0356e_ Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585340BAD0313ESESSCMS0356e_" --_000_7F2072F1E0DE894DA4B517B93C6A0585340BAD0313ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, For those of you interested in media multiplexing. Regards, Christer From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: 8. lokakuuta 2012 11:55 To: mmusic@ietf.org Subject: [MMUSIC] Draft new: draft-holmberg-mmusic-sdp-mmt-negotiation-00 Hi, We've submitted a new draft, which describes the 'm=3Dbundle' mechanism. In order to avoid confusion, we're not using bundle terminology in the draf= t. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585340BAD0313ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI,

 

For those of you interested in media multiplexing.=

&n= bsp;

Reg= ards,

 

Christer

 

From= : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Christer Holmberg
Sent: 8. lokakuuta 2012 11:55
To:<= /b> mmusic@ietf.org
Subject: [MMUSIC] Draft new: draft-holmberg-m= music-sdp-mmt-negotiation-00

 

Hi,<= /o:p>

 

We’ve submitted a new draft, which describ= es the ’m=3Dbundle’ mechanism.

 

In order to avoid confusion, w= e’re not using bundle terminology in the draft.

 

Regards,=

 

Christer=

= --_000_7F2072F1E0DE894DA4B517B93C6A0585340BAD0313ESESSCMS0356e_-- --_004_7F2072F1E0DE894DA4B517B93C6A0585340BAD0313ESESSCMS0356e_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=133; creation-date="Mon, 08 Oct 2012 08:54:56 GMT"; modification-date="Mon, 08 Oct 2012 08:54:56 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBt YWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tbXVzaWMNCg== --_004_7F2072F1E0DE894DA4B517B93C6A0585340BAD0313ESESSCMS0356e_-- From christer.holmberg@ericsson.com Mon Oct 8 02:47:25 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F338E21F86B2 for ; Mon, 8 Oct 2012 02:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.121 X-Spam-Level: X-Spam-Status: No, score=-6.121 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0ZwU8ZOGrNx for ; Mon, 8 Oct 2012 02:47:24 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D255621F8770 for ; Mon, 8 Oct 2012 02:47:23 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-89-5072a12afdd6 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 50.7C.17130.A21A2705; Mon, 8 Oct 2012 11:47:22 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 8 Oct 2012 11:47:22 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" , "rtcweb@ietf.org" Date: Mon, 8 Oct 2012 11:47:20 +0200 Thread-Topic: [rtcweb] Agenda requests for Atlanta meeting Thread-Index: AQHNokcVmKX2z94GUkOz6A2FaADmtpevLXrA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> References: <506B0367.4000103@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyM+Jvra7WwqIAg/5vVhYdk9ks1v5rZ3dg 8pjyeyOrx5IlP5kCmKK4bFJSczLLUov07RK4Mo5+/cpS8FegYv6iXqYGxje8XYycHBICJhKt Kx8wQthiEhfurWfrYuTiEBI4xShx4c5hsISQwAJGiTsvBboYOTjYBCwkuv9pg4RFBCIkJl6/ wAYSZhFQkdh6UQMkLCxgKbFo8342iBIriTW3rjODlIgIGEl8/mUKYvIKhEvMO5EIMTtPYuGG ZhYQm1PAV2LSg0vsIDYj0DHfT61hArGZBcQlbj2ZzwRxpIDEkj3nmSFsUYmXj/+xQtSLStxp X88IUa8ncWPqFDYIW1ti2cLXYPW8AoISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkbh3MTM nPRyc73Uoszk4uL8PL3i1E2MwMg4uOW3wQ7GTffFDjFKc7AoifPqqe73FxJITyxJzU5NLUgt ii8qzUktPsTIxMEp1cB4fIb7ZEul2im5F3kaqlXzxM+ZtjxblepUzF/dFM+dqX4h+fCib4cE hV4svGjkpbXpvZeYa7ra1JWdqhmdLNfOzT3HGqH/r9NK5ecpYZvJIV8uzTxw/dKBPy2aB3Ym /lom6C7X4ubkWXNJ1GQdv33TzBiR7wuZpgmddQvdYy9XeqFFVpNxhqgSS3FGoqEWc1FxIgAT yin2WgIAAA== Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Oct 2012 09:47:25 -0000 Hi, I would like to discuss the different alternatives in order to support fork= ing, e.g. whether we use cloning, whether we simply set additional local de= scriptor, and whether we can get rid of PRANSWER. As it is related to JSEP and SDP, I guess it should be part of the JSEP dis= cussion. I am willing to help with material. Regards, Christer -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Cullen Jennings (fluffy) Sent: 4. lokakuuta 2012 18:44 To: rtcweb@ietf.org Subject: Re: [rtcweb] Agenda requests for Atlanta meeting With my individual contributor hat on . Justin and I would like to have some time for JSEP. I think there are a bun= ch of issues, particularly around the use of SDP and timing of various thin= gs that need discussion.=20 Thanks, Cullen On Oct 2, 2012, at 9:08 AM, Magnus Westerlund wrote: > WG, >=20 > We chairs like to have input into what you see should be on the Agenda=20 > for our two meeting slots in Atlanta. Both document editors/authors=20 > and participant are welcome to request or inform the WG or the chairs=20 > only about issues that needs to be discussed in the meeting. >=20 > Two items we chairs believe should be on the agenda are: >=20 > - Video codec selection > - JSEP >=20 >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > 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 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Mon Oct 8 15:51:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D78811E8100 for ; Mon, 8 Oct 2012 15:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.519 X-Spam-Level: X-Spam-Status: No, score=-110.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPlISULtU37v for ; Mon, 8 Oct 2012 15:51:46 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id BA91C11E80CC for ; Mon, 8 Oct 2012 15:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=459; q=dns/txt; s=iport; t=1349736707; x=1350946307; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BhFh5Wi5PK52Usy+R6Y7tONs7SPsHn8t+lAf3dutud8=; b=gWTNgSrXcT2bfA7KLGTbxxZts33gVP2tToeuqQ90IiKAKdrsuHsideIb nNZi+jXhHthH/Zu2H9IC9mCcVBFIAPjgHbJn/Mf7zg4hv6d5sLAjQzZ3Z DcBmQU1W8GJQ5Laufl37kOgGV3+9p84F5zotIYjj53lNQ5mylbcfQLa49 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAEBYc1CtJXG+/2dsb2JhbABFhUq5Z4EIgiABAQEDARIBJy4REAIBCCIUEDIlAgQOBQgah10Gmj+gAItHgzqBeWADpDCBaYJgDYIX X-IronPort-AV: E=Sophos;i="4.80,556,1344211200"; d="scan'208";a="129508495" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 08 Oct 2012 22:51:40 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q98MpdVo029825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Oct 2012 22:51:39 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Mon, 8 Oct 2012 17:51:39 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [rtcweb] JSEP: Relaxing SDP O/A rules? Thread-Index: AQHNpad6aenXLuIV20+kkVz1nsB6Xg== Date: Mon, 8 Oct 2012 22:51:39 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <506D4F7A.5020109@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> <506F1526.4050306@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2FE4@ESESSCMS0356.eemea.ericsson.se>, <000701cda387$4abc4fa0$e034eee0$@co.in> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA5D@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA5D@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.86.152] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19252.004 x-tm-as-result: No--34.344400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <594042BE1003784DAEC5D9DC4B6950F8@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Oct 2012 22:51:47 -0000 On Oct 6, 2012, at 11:24 , Christer Holmberg wrote: >=20 > At least I have never thought of any other use of it than to support seri= al forking. Other use cases were raised when connecting to a conference bridge where th= e initial contact point wanted to keep the options for video codecs open un= til after the actually MCU was connected. I think there were other uses cas= es when gatewaying to H.323.=20 From fluffy@cisco.com Mon Oct 8 15:51:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8768711E80CC for ; Mon, 8 Oct 2012 15:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4loF1cApG6qF for ; Mon, 8 Oct 2012 15:51:46 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 492EF11E809B for ; Mon, 8 Oct 2012 15:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3972; q=dns/txt; s=iport; t=1349736693; x=1350946293; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DYsKXV8oByP6fJYKodPQ1PkzwJhnNoIcSzPDKCZszwg=; b=Gjpn3P6kyODvxMJPuMX9AnEWidZCJ7xZasXb7lHF3y3AppymGdCrGyaR vZgdUGEGanulha5kmjNG36dDcdKz1QR9ZtCy+/akErGuvlNJq41zMqxnL mGlj0kANDRtcl4Tj81dGY7tr6PYlFJzHRBnSNM77Zzm+xQaY4Xr6WyYzH Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEBYc1CtJV2a/2dsb2JhbABFvzGBCIIgAQEBAwEBAQEPASc0CwULAgEIEQQBAQEKFAkHJwsUCQgCBA4FCBqHXQYLmjSffASLRxqDIIF5YAOkMIFpgmANgVoGAzQ X-IronPort-AV: E=Sophos;i="4.80,556,1344211200"; d="scan'208";a="129528132" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 08 Oct 2012 22:51:32 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q98MpWQ3022383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Oct 2012 22:51:32 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Mon, 8 Oct 2012 17:51:32 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [rtcweb] JSEP: Relaxing SDP O/A rules? Thread-Index: AQHNpad1aenXLuIV20+kkVz1nsB6Xg== Date: Mon, 8 Oct 2012 22:51:31 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <506D4F7A.5020109@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> <506F1526.4050306@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2FE4@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FE4@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.86.152] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19252.004 x-tm-as-result: No--39.592400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Oct 2012 22:51:47 -0000 Uh, sort of - if you send an offer that says you could get early media, yo= u may get early media from two places even thought you have not received an= y answer. Yes, I realize you can't do ICE till you get the answer but I thi= nk the above is still the case in non ICE case an with ICE case you may end= up with two dialogs formed but dialogs are really a Sip level concept not = an RTP concept.=20 On Oct 5, 2012, at 14:26 , Christer Holmberg wrote: > Hi, >=20 > Roman is correct. >=20 > The SDP O/A doesn't consider forking, because each forked SIP leg creates= a unique early dialog, and each early dialog has its own O/A state machine= . >=20 > Regards, >=20 > Christer >=20 >=20 > ________________________________ > From: Roman Shpount [roman@telurix.com] > Sent: Friday, October 05, 2012 8:46 PM > To: Harald Alvestrand > Cc: Christer Holmberg; rtcweb@ietf.org > Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? >=20 >=20 > On Fri, Oct 5, 2012 at 1:13 PM, Harald Alvestrand > wrote: > I've asked that question before, but I don't remember seeing an answer fr= om people who know what they're talking about: >=20 > Does serial forking, as practiced by SIP UAs, violate the SDP O/A model, = or does it not violate the SDP O/A model? >=20 > I don't understand how it, in the form that has been described as "what w= e have to support", can be SDP O/A compatible, but then there are many thin= gs about SIP that I don't understand, so I may understand it when it's expl= ained to me. >=20 >=20 > O/A does not describe multiple answers to a single offer. Nothing explici= tly prohibits it there but I would argue this is not part of this specifica= tion. No standard document that I am aware of describes how serial O/A is s= upposed to work. Serial forking as practiced by SIP UA does violate SIP RFC= 3261 which states that each dialog can only have one answer to each offer.= If answer is sent in both provisional and final response, it should be the= same. You can, however, create multiple dialogs with the same offer. This = normally implies parallel forking, but the most common use case is with ear= ly media, where you end up with multiple early dialogs. For instance you ca= ll a phone number, phone network sends you SDP in early media and plays a d= ial tone, then the called number does not answer, and you get connected to = a voice mail which uses a completely different SDP in final answer. Accordi= ng to SIP these answers should come with different to-tags and technically = would be parts of > two different dialogs. What makes this a bit tricky is when the phone ne= twork and the voice mail are behind SBC (or some other sort of B2BUA) you o= nly see one dialog which send you multiple answers to the same offer. This = scenario is so common that it is more likely to be implemented then paralle= l forking. This is why PRANSWER was suggested. >=20 > If cloning can be implemented in WebRTC it would be more standard complia= nt then PRANSWER and would allow for a lot more use cases. Typical difficul= ty in parallel forking implementation in SIP is due to RTP from multiple so= urces coming to the same IP and port with no consent or notification to the= receiving side. This makes it very difficult to present this media to the = user. There is no way to tie media to actual dialogs since RTP can come fro= m different IP and ports then specified in answer SDPs. This is not an issu= e with WebRTC where consent to receive media is required. I would argue let= 's implement cloning and not waste any more time on PRANSWER which in my op= inion will always stay a half working hack. > _____________ > Roman Shpount >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Mon Oct 8 15:51:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F273111E809B for ; Mon, 8 Oct 2012 15:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.458 X-Spam-Level: X-Spam-Status: No, score=-110.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OV0grsB7Sp6X for ; Mon, 8 Oct 2012 15:51:47 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1BA11E80FF for ; Mon, 8 Oct 2012 15:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2136; q=dns/txt; s=iport; t=1349736707; x=1350946307; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=T79wS4EY2O6hRYd1/3LjPXYnS+wxBt7w1v1kRc9f83w=; b=EpR6ZVbfawzAFR2qZKZveb+aJoV9gd4KjF+eEPo1k5MDH+si/JHZMTHR srDPFYFRHSP0hO+BYA/drtlKyd5eLdPk9yxpxLrlV88OJgfs+vld0oIAq Etg+rQoLYaphnMbAjlSUvE6idpgNltLAEffqqHUVhj5Ezd7DezFv9zPMj E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEBYc1CtJV2b/2dsb2JhbABFvzGBCIIgAQEBAwEBAQEPASc0BAcFCwIBCCIUECcLJQIEDgUIGoddBguaNJ98BItHgzqBeWADpDCBaYJgDYIX X-IronPort-AV: E=Sophos;i="4.80,556,1344211200"; d="scan'208";a="126526569" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 08 Oct 2012 22:51:47 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q98MpkLa027072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Oct 2012 22:51:46 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Mon, 8 Oct 2012 17:51:46 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [rtcweb] JSEP: Relaxing SDP O/A rules? Thread-Index: AQHNpad+aenXLuIV20+kkVz1nsB6Xg== Date: Mon, 8 Oct 2012 22:51:46 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <506D4F7A.5020109@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BD0C5@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FE5@ESESSCMS0356.eemea.ericsson.se>, <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA5E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA5E@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.86.152] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19252.004 x-tm-as-result: No--39.268400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <15BD22D3CF4FC74D8CB177EBDE0F722F@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Oct 2012 22:51:48 -0000 On Oct 6, 2012, at 11:38 , Christer Holmberg wrote: > Hi, >=20 >>>>> Can I use the same local descriptor for every setLocal() call? >>>>=20 >>>> My experience suggests that you can. However, that's not stipulated >>>> in the API specification, so it's not an ironclad guarantee. >>>=20 >>> If it doesn't, and a new local descripor is created, you would need to = send that one to the remote=20 >>> endpoint. >>=20 >> You don't create a new description, you just set one. >=20 > Correct. >=20 >> The only problem arises when you can't set the local description because >> something broke since you last set it. (Maybe setting the answer >> caused the browser to release something that you need to set the If you send an answer that has not relation to the offer, you are equally h= osed. We are keeping the pairing of the offers and answers in the JS state = so there are ways that the JS can mess things up if it is buggy but that no= t really a PRANSWER problem - it's just as much a issue with offers and ans= wers.=20 >> offer.) >=20 > That is the main difference between PRANSWER and ANSWER: PRANSWER does no= t release local resources based on the answer. Exactly - and the important implication of this is that the far end can kee= p using the resources that were in the Offer. Sequential forking is a post= er child for one of the cases where you need to do this but there are other= s. =20 >=20 >> If that happens, you are hosed. You could try to make a new PeerConnect= ion, but you'll have to resend your INVITE because you will >> get a new set of candidates, ufrag, pwd, etc... >=20 > Or, you could set the new local descriptor BEFORE you apply the answer to= the previous one. I think that is how the cloning is currently described i= n JSEP: the cloning happens first (eventhough it may never be used, if no a= dditional remote peers are contacted). >=20 > Regards, >=20 > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Mon Oct 8 15:51:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5938811E810D for ; Mon, 8 Oct 2012 15:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.466 X-Spam-Level: X-Spam-Status: No, score=-110.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjhWnVlQmVjc for ; Mon, 8 Oct 2012 15:51:54 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A6F3D11E810C for ; Mon, 8 Oct 2012 15:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=524; q=dns/txt; s=iport; t=1349736714; x=1350946314; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QCgI1+ku2mjfVigo7lD/WPeC9N6A6z8s9cU4zdXZLts=; b=KxZMJrBqMAIxIlr43wYJJj92yoDioP0w8NHsWIukrhYG7IFt3m4ha+Gq E20d4Kq5DWZTbdChpz0Gye4OnaUOzfFdlWfKZHlKG2SJhUVhdOkUWjJC9 kbVRV/NKGxFuAXDTz6kf5S3a/NjFcTidLdqs1SBbo9dBzWTLiQ+YZH9sV w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAEBYc1CtJV2Y/2dsb2JhbABFhUq5Z4EIgiABAQEDAQEBAQ8BWwsFCwIBCCIkJwslAgQOBQgah10GC5o0n3wEi0eDOoF5YAOkMIFpgmANghc X-IronPort-AV: E=Sophos;i="4.80,556,1344211200"; d="scan'208";a="129528347" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 08 Oct 2012 22:51:54 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q98Mps0m014616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Oct 2012 22:51:54 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Mon, 8 Oct 2012 17:51:53 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [rtcweb] JSEP-02: SDP line Thread-Index: AQHNpaeCbEGADE12P0+l1nA7avE9ng== Date: Mon, 8 Oct 2012 22:51:52 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A0585340A7BCEF1@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A7BCEF1@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.86.152] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19252.004 x-tm-as-result: No--35.080500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <775FF29D08892A43A407D55D2F34236F@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-02: SDP line X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Oct 2012 22:51:55 -0000 On Oct 4, 2012, at 7:33 , Christer Holmberg wrote: > Hi, > =20 > What is a =94SDP line=94? The same thing as a =93SDP blob=94? > =20 > Regards, > =20 > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb this is poorly defined and we need to fix that - it's probably the wrong te= rm=20 I think it was trying to get at the m-line matching issues in SDP so the te= rm=20 From fluffy@cisco.com Mon Oct 8 15:53:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B6B11E809B for ; Mon, 8 Oct 2012 15:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQ9D82LZlwCj for ; Mon, 8 Oct 2012 15:53:04 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 09E3B11E80CC for ; Mon, 8 Oct 2012 15:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1516; q=dns/txt; s=iport; t=1349736784; x=1350946384; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ltvglJ2VV0IwsJPDw4GMEe4wkDdgysFCROUIn7gXLDE=; b=OAuLnT+3a6Wk0R2xkRDOSW/WzMLibLuBzPD+ZQWoMIRmbPAA10zqFb4q zGe2CnYUMT+ZXG5C7hWpm5sywQBurJpLXIT37UuqaamHHqz9ufUKSx0Uj BrI2KmAmvhvX14MXzYU38wKMOP6Mtu3musqpvqKsdzfnC+FzWhI4WJS1C w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEBYc1CtJV2c/2dsb2JhbABFvzGBCIIgAQEBAwESATQyBQsCAQgiJDIlAgQOBQgTB4ddBpo/kQyOdItHgzqBeWADiCOKF5F2gWmCYA2CFw X-IronPort-AV: E=Sophos;i="4.80,556,1344211200"; d="scan'208";a="129528539" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 08 Oct 2012 22:52:55 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q98MqsQi019772 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Oct 2012 22:52:54 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Mon, 8 Oct 2012 17:52:54 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [rtcweb] Agenda requests for Atlanta meeting Thread-Index: AQHNpaenkG2ADNG+3EO5+NGGgdEEeg== Date: Mon, 8 Oct 2012 22:52:54 +0000 Message-ID: References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.86.152] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19252.004 x-tm-as-result: No--30.105700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Oct 2012 22:53:05 -0000 On Oct 8, 2012, at 2:47 , Christer Holmberg wrote: > Hi, >=20 > I would like to discuss the different alternatives in order to support fo= rking, e.g. whether we use cloning, whether we simply set additional local = descriptor, and whether we can get rid of PRANSWER. Seriously? we have discussed this so many times and always come to the same= conclusion. I have not seen anything on the list that suggests why we need= to remove this or how mapping to SIP 180 with sequential forking is going = to work without it. It also has other important uses. There are a bunch of = changes that are needed to the JSEP draft to remove some of the inconsisten= cies in this and clarify some parts but I'd rather wait till we had that up= dated before we got into a whole discussion about exploding it yet again.=20 Why don't we have a phone call to try and outline what the problems you are= trying to solve that the current solution does not work for then figure ou= t how much we want to explode this.=20 I'll note that current clone text has lots of "miracles happen here, insert= supper fluffy hand wave" in it and plenty of weasel room on failure to all= ocate required resources on the clone. It's more or less a sketch of an ide= a at this point. I'm perfectly happy to see people try and sort out the det= ails on clone but using it explode the consensus we have come to around PRA= NSWER seems like a really bad idea at this point.=20 Cullen From fluffy@cisco.com Mon Oct 8 15:53:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88CFB11E8106 for ; Mon, 8 Oct 2012 15:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCrGSW2qd8cZ for ; Mon, 8 Oct 2012 15:53:06 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5339711E8101 for ; Mon, 8 Oct 2012 15:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1516; q=dns/txt; s=iport; t=1349736786; x=1350946386; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ltvglJ2VV0IwsJPDw4GMEe4wkDdgysFCROUIn7gXLDE=; b=JTe2QFNBlTARv8+AirqErsb/IPnvmf0huisjyPFtT744Grxk/+1IvjEW qM0cKDQ0oKipEFCgPAjZ9s2w8YQW4pyy3soWXL6bcnN7gJsM56jAImUQ3 8rSpCGSbRg6vb22V4luR9RV9IDVQcwApZcFo23MQLXpfp5bQ1CW+c90Sl Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEBYc1CtJV2b/2dsb2JhbABFvzGBCIIgAQEBAwESATQyBQsCAQgiJDIlAgQOBQgTB4ddBpo/kQyOdItHgzqBeWADiCOKF5F2gWmCYA2CFw X-IronPort-AV: E=Sophos;i="4.80,556,1344211200"; d="scan'208";a="129508755" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 08 Oct 2012 22:53:06 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q98Mr56H028009 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Oct 2012 22:53:05 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Mon, 8 Oct 2012 17:53:05 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [rtcweb] Agenda requests for Atlanta meeting Thread-Index: AQHNpaetkG2ADNG+3EO5+NGGgdEEeg== Date: Mon, 8 Oct 2012 22:53:05 +0000 Message-ID: References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.86.152] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19252.004 x-tm-as-result: No--30.105700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <548D5D74B4EA52439E92E97B70B9740C@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Oct 2012 22:53:06 -0000 On Oct 8, 2012, at 2:47 , Christer Holmberg wrote: > Hi, >=20 > I would like to discuss the different alternatives in order to support fo= rking, e.g. whether we use cloning, whether we simply set additional local = descriptor, and whether we can get rid of PRANSWER. Seriously? we have discussed this so many times and always come to the same= conclusion. I have not seen anything on the list that suggests why we need= to remove this or how mapping to SIP 180 with sequential forking is going = to work without it. It also has other important uses. There are a bunch of = changes that are needed to the JSEP draft to remove some of the inconsisten= cies in this and clarify some parts but I'd rather wait till we had that up= dated before we got into a whole discussion about exploding it yet again.=20 Why don't we have a phone call to try and outline what the problems you are= trying to solve that the current solution does not work for then figure ou= t how much we want to explode this.=20 I'll note that current clone text has lots of "miracles happen here, insert= supper fluffy hand wave" in it and plenty of weasel room on failure to all= ocate required resources on the clone. It's more or less a sketch of an ide= a at this point. I'm perfectly happy to see people try and sort out the det= ails on clone but using it explode the consensus we have come to around PRA= NSWER seems like a really bad idea at this point.=20 Cullen From roman@telurix.com Mon Oct 8 15:58:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CA721F84B5 for ; Mon, 8 Oct 2012 15:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVmYbiER0IJm for ; Mon, 8 Oct 2012 15:58:58 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1963C21F84A7 for ; Mon, 8 Oct 2012 15:58:58 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so1814713dan.31 for ; Mon, 08 Oct 2012 15:58:57 -0700 (PDT) X-Google-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:x-gm-message-state; bh=k1XV8XgbnnZMIQHjCI9IrM2nadpnuRMfhYvBw1Upejo=; b=Fh72SfnWknuyn7S0eUeHmC+nIWoeTK96J8OK5Quu7j3JOwG1jEQA+fdbiTO0Rs4qqu 3/G4z93XZPJT9bjOppwGiXXM4puaCii5GZRyWxol7yq+CmtzdW24FkjVpDucCSkc5Ssk OrZkl5SxYXlhnyKPSctbLCofs2OtH6mefmsowdLe+3KQJv/BxZRAetoO2z5PRebbhuEt KTm9bFP/kAS/Ux5HRmhn6J9Gy5PFVZvmsSyN70uGv9LT0AxgUmlHc+ff24QJf8diL7ug 6k0xtw2h8e9w0+QyAO2guRZVEVEK6IrTO2hZ4flSDClsDrPxewUuulo+TvcvwyEnfYfD xfbw== Received: by 10.66.84.229 with SMTP id c5mr46902166paz.76.1349737137871; Mon, 08 Oct 2012 15:58:57 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id rr6sm11336508pbc.47.2012.10.08.15.58.55 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Oct 2012 15:58:56 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so4532066pbb.31 for ; Mon, 08 Oct 2012 15:58:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.225.7 with SMTP id rg7mr58630116pbc.32.1349737135328; Mon, 08 Oct 2012 15:58:55 -0700 (PDT) Received: by 10.68.42.8 with HTTP; Mon, 8 Oct 2012 15:58:55 -0700 (PDT) In-Reply-To: References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 8 Oct 2012 18:58:55 -0400 Message-ID: From: Roman Shpount To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=047d7b2e79887dcc9004cb942afd X-Gm-Message-State: ALoCoQkqfwovdcJrB0ekfSsJYJ9I0cy19FtJ+wUqoG2TDS8H7O6ezcA7R6eiiMWtncVuN/uEj4bS Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Oct 2012 22:58:58 -0000 --047d7b2e79887dcc9004cb942afd Content-Type: text/plain; charset=ISO-8859-1 Cullen, I have an existing interop problem with SIP serial forking that I cannot solve with the proposed schema. With PRANSWER, how would I handle SIP UPDATE sith SDP received in early dialog? Regards, _____________ Roman Shpount On Mon, Oct 8, 2012 at 6:53 PM, Cullen Jennings (fluffy) wrote: > > On Oct 8, 2012, at 2:47 , Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > Hi, > > > > I would like to discuss the different alternatives in order to support > forking, e.g. whether we use cloning, whether we simply set additional > local descriptor, and whether we can get rid of PRANSWER. > > Seriously? we have discussed this so many times and always come to the > same conclusion. I have not seen anything on the list that suggests why we > need to remove this or how mapping to SIP 180 with sequential forking is > going to work without it. It also has other important uses. There are a > bunch of changes that are needed to the JSEP draft to remove some of the > inconsistencies in this and clarify some parts but I'd rather wait till we > had that updated before we got into a whole discussion about exploding it > yet again. > > Why don't we have a phone call to try and outline what the problems you > are trying to solve that the current solution does not work for then figure > out how much we want to explode this. > > I'll note that current clone text has lots of "miracles happen here, > insert supper fluffy hand wave" in it and plenty of weasel room on failure > to allocate required resources on the clone. It's more or less a sketch of > an idea at this point. I'm perfectly happy to see people try and sort out > the details on clone but using it explode the consensus we have come to > around PRANSWER seems like a really bad idea at this point. > > Cullen > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b2e79887dcc9004cb942afd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cullen,

I have an existing interop problem with SIP seri= al forking that I cannot solve with the proposed schema. With PRANSWER, how= would I handle SIP UPDATE sith SDP received in early dialog?

Regards,
_____________
Roman Shpount


On Mon, Oct 8, 2012 at 6:53 PM, Cullen J= ennings (fluffy) <fluffy@cisco.com> wrote:

On Oct 8, 2012, at 2:47 , Christer Holmberg <christer.holmberg@ericsson.com> wrote:

> Hi,
>
> I would like to discuss the different alternatives in order to support= forking, e.g. whether we use cloning, whether we simply set additional loc= al descriptor, and whether we can get rid of PRANSWER.

Seriously? we have discussed this so many times and always come to the same= conclusion. I have not seen anything on the list that suggests why we need= to remove this or how mapping to SIP 180 with sequential forking is going = to work without it. It also has other important uses. There are a bunch of = changes that are needed to the JSEP draft to remove some of the inconsisten= cies in this and clarify some parts but I'd rather wait till we had tha= t updated before we got into a whole discussion about exploding it yet agai= n.

Why don't we have a phone call to try and outline what the problems you= are trying to solve that the current solution does not work for then figur= e out how much we want to explode this.

I'll note that current clone text has lots of "miracles happen her= e, insert supper fluffy hand wave" in it and plenty of weasel room on = failure to allocate required resources on the clone. It's more or less = a sketch of an idea at this point. I'm perfectly happy to see people tr= y and sort out the details on clone but using it explode the consensus we h= ave come to around PRANSWER seems like a really bad idea at this point.

Cullen

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

--047d7b2e79887dcc9004cb942afd-- From ekr@rtfm.com Mon Oct 8 16:01:40 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641FF21F84C8 for ; Mon, 8 Oct 2012 16:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.765 X-Spam-Level: X-Spam-Status: No, score=-102.765 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aft1PqmDju2p for ; Mon, 8 Oct 2012 16:01:39 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7D78421F84C5 for ; Mon, 8 Oct 2012 16:01:39 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so249806eaa.31 for ; Mon, 08 Oct 2012 16:01:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=OBMx519hJ1+LZqNQBO9yBG75ZvA4F55c/YWn1vWhX5U=; b=a+nodJdMlWZ2T8cpZCh4jMgx0k2jMnVBubm9dULAjfLIan4qExgNNncFPCi+0gbJM/ LtNOd7zHTlp9hrSafVltWMf/leLaQj8Gw/7LIBDKfYhPXRac9EqRc9lCYDqEyjFAqoTw gmRB5uzd0s1hefi/b9YsbcV8+4bbjaMEhAZMIKB2dKuK3lB66ZR34eSs/Wfpl6E7wGI2 rtJPMiLhtP9mcyT75DZ7pSiMdd4xqUqEH0GeZFYui0+zOSxC99AWQEz0zxEh+mIWNqb8 HJMrnRMRIlKHSC7eN1LkmMhO2Dcav2UIi8vrERrxo5S3go9jGE3XatfWVn28YLQZIB/e i62g== Received: by 10.14.207.5 with SMTP id m5mr25223436eeo.22.1349737298630; Mon, 08 Oct 2012 16:01:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.144.77 with HTTP; Mon, 8 Oct 2012 16:00:58 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> From: Eric Rescorla Date: Mon, 8 Oct 2012 16:00:58 -0700 Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk61b+4S/No9vsqQFoZR+UH4SQmPORlPq7U8YntppfuzbAyorAsIGo4teJbqgtzpu2dPwDJ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Oct 2012 23:01:40 -0000 I would attend such a phone call if it were held. My immediate reaction is that from an implementor's perspective. PRANSWER is a lot easier to address than cloning. I feel like cloning pulls in a lot= of difficult lifetime and ownership semantics. By contrast, supporting PRANSWE= R is very easy. Before deciding that cloning is the answer I'd like to see tw= o things: 1. A clear set of use cases that shows what cloning does well that PRANSWER does not. 2. A fairly complete defn of the clone semantics. Otherwise I worry that we'll detour to cloning and then only after 6 months discover it doesn't work. Best, -Ekr On Mon, Oct 8, 2012 at 3:52 PM, Cullen Jennings (fluffy) wrote: > > On Oct 8, 2012, at 2:47 , Christer Holmberg wrote: > >> Hi, >> >> I would like to discuss the different alternatives in order to support f= orking, e.g. whether we use cloning, whether we simply set additional local= descriptor, and whether we can get rid of PRANSWER. > > Seriously? we have discussed this so many times and always come to the sa= me conclusion. I have not seen anything on the list that suggests why we ne= ed to remove this or how mapping to SIP 180 with sequential forking is goin= g to work without it. It also has other important uses. There are a bunch o= f changes that are needed to the JSEP draft to remove some of the inconsist= encies in this and clarify some parts but I'd rather wait till we had that = updated before we got into a whole discussion about exploding it yet again. > > Why don't we have a phone call to try and outline what the problems you a= re trying to solve that the current solution does not work for then figure = out how much we want to explode this. > > I'll note that current clone text has lots of "miracles happen here, inse= rt supper fluffy hand wave" in it and plenty of weasel room on failure to a= llocate required resources on the clone. It's more or less a sketch of an i= dea at this point. I'm perfectly happy to see people try and sort out the d= etails on clone but using it explode the consensus we have come to around P= RANSWER seems like a really bad idea at this point. > > Cullen > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From roman@telurix.com Mon Oct 8 16:04:11 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6F71F0C5C for ; Mon, 8 Oct 2012 16:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Af26iUcpImW9 for ; Mon, 8 Oct 2012 16:04:10 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id F036D21F86EE for ; Mon, 8 Oct 2012 16:04:07 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so4476142pad.31 for ; Mon, 08 Oct 2012 16:04:02 -0700 (PDT) X-Google-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:x-gm-message-state; bh=d8QgptatpHvC9uHqTU0gTlL3tkshc/DVAjjgEdke0+k=; b=UEV1ShWAeU2RCgdSlZK13EvJMG+7BZpYYiR2vHYph3WQTpCMtjPZ8WhRgPBzQCmc4J TRWduibfWwodrfC7QSLHzh5MJkBacfzZ8qsqNKsyWu5lQq5dTDF0Za34UZ9xZO9DeXWZ QdVp9JCg1++j1VG4OSIqssACkzBeIflHoDZLcX+fxSmm/wofWeCuCTTN0wbPNU9RuP6c KilBqNrCnmKJMXFTMeVMjp9CHrH5E2HO+bVoJfH3c54vO1VTSRdrbK+Q6Ep5w1N2WfSA vU/cse9/KU7i8dfrBaGPbANm1DmCLol9TZxuOcOgQxqd1ync8h1rPvCHhDyQlkMvCp98 cHIQ== Received: by 10.68.211.99 with SMTP id nb3mr58163384pbc.16.1349737442362; Mon, 08 Oct 2012 16:04:02 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id it6sm11349440pbc.14.2012.10.08.16.04.01 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Oct 2012 16:04:01 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so1816463dan.31 for ; Mon, 08 Oct 2012 16:04:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.225.7 with SMTP id rg7mr58662932pbc.32.1349737440616; Mon, 08 Oct 2012 16:04:00 -0700 (PDT) Received: by 10.68.42.8 with HTTP; Mon, 8 Oct 2012 16:04:00 -0700 (PDT) In-Reply-To: References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <506D4F7A.5020109@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> <506F1526.4050306@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FE4@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 8 Oct 2012 19:04:00 -0400 Message-ID: From: Roman Shpount To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=047d7b2e7988b0201604cb943cb5 X-Gm-Message-State: ALoCoQnsOBr6+P4hYOC1ij1oQlQlySDUbLuqsjYigeZi5BL4rsjhvEQ+8Hqxc2yd4z8Dz21NjrqM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Oct 2012 23:04:11 -0000 --047d7b2e7988b0201604cb943cb5 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 8, 2012 at 6:51 PM, Cullen Jennings (fluffy) wrote: > > Uh, sort of - if you send an offer that says you could get early media, > you may get early media from two places even thought you have not received > any answer. Yes, I realize you can't do ICE till you get the answer but I > think the above is still the case in non ICE case an with ICE case you may > end up with two dialogs formed but dialogs are really a Sip level concept > not an RTP concept. > > Dialogs are entirely SIP level concept, but what I am arguing is that with ICE and WebRTC you can associate RTP streams with a particular answer. This means you can clone connection, provide it with the answer and each connection would be able to filter out only the media that is intended for it. If I am missing something and ICE is not enough then msid should be. _____________ Roman Shpount --047d7b2e7988b0201604cb943cb5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 8, 2012 at 6:51 PM, Cullen Jenni= ngs (fluffy) <fluffy@cisco.com> wrote:

Uh, sort of =A0- if you send an offer that says you could get early media, = you may get early media from two places even thought you have not received = any answer. Yes, I realize you can't do ICE till you get the answer but= I think the above is still the case in non ICE case an with ICE case you m= ay end up with two dialogs formed but dialogs are really a Sip level concep= t not an RTP concept.

<= br>
Dialogs=A0are=A0entirely SIP level concept, but what I am arg= uing is that with ICE and WebRTC you can associate RTP streams with a parti= cular answer. This means you can clone connection, provide it with the answ= er and each connection would be able to filter out only the media that is i= ntended for it.=A0If I am missing something and ICE is not enough then msid= should be.
_____________
Roman Shpount
=A0
--047d7b2e7988b0201604cb943cb5-- From fluffy@iii.ca Mon Oct 8 16:08:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC6121F8715 for ; Mon, 8 Oct 2012 16:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bM1g5m4SBko7 for ; Mon, 8 Oct 2012 16:08:56 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id E615421F8703 for ; Mon, 8 Oct 2012 16:08:55 -0700 (PDT) Received: from [10.21.86.152] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F3F4B22E253; Mon, 8 Oct 2012 19:08:48 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Cullen Jennings In-Reply-To: Date: Mon, 8 Oct 2012 16:09:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <723C9B03-B45B-4214-9A36-7B4CEBD2FC2E@iii.ca> References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> To: Roman Shpount X-Mailer: Apple Mail (2.1499) Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Oct 2012 23:08:56 -0000 Walk me through what the call flow would like it both endpoints were SIP = UA's so I understand it better.=20 Note - I'm not against folks trying to figure out clone. I'm saying that = we should not get rid of PRANSWER. On Oct 8, 2012, at 15:58 , Roman Shpount wrote: > Cullen, >=20 > I have an existing interop problem with SIP serial forking that I = cannot solve with the proposed schema. With PRANSWER, how would I handle = SIP UPDATE sith SDP received in early dialog? >=20 > Regards, > _____________ > Roman Shpount >=20 >=20 > On Mon, Oct 8, 2012 at 6:53 PM, Cullen Jennings (fluffy) = wrote: >=20 > On Oct 8, 2012, at 2:47 , Christer Holmberg = wrote: >=20 > > Hi, > > > > I would like to discuss the different alternatives in order to = support forking, e.g. whether we use cloning, whether we simply set = additional local descriptor, and whether we can get rid of PRANSWER. >=20 > Seriously? we have discussed this so many times and always come to the = same conclusion. I have not seen anything on the list that suggests why = we need to remove this or how mapping to SIP 180 with sequential forking = is going to work without it. It also has other important uses. There are = a bunch of changes that are needed to the JSEP draft to remove some of = the inconsistencies in this and clarify some parts but I'd rather wait = till we had that updated before we got into a whole discussion about = exploding it yet again. >=20 > Why don't we have a phone call to try and outline what the problems = you are trying to solve that the current solution does not work for then = figure out how much we want to explode this. >=20 > I'll note that current clone text has lots of "miracles happen here, = insert supper fluffy hand wave" in it and plenty of weasel room on = failure to allocate required resources on the clone. It's more or less a = sketch of an idea at this point. I'm perfectly happy to see people try = and sort out the details on clone but using it explode the consensus we = have come to around PRANSWER seems like a really bad idea at this point. >=20 > Cullen >=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 roman@telurix.com Mon Oct 8 16:21:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6EE1F0C61 for ; Mon, 8 Oct 2012 16:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YyitiqIuXhc for ; Mon, 8 Oct 2012 16:21:57 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id C8FD51F0417 for ; Mon, 8 Oct 2012 16:21:56 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so1822721dan.31 for ; Mon, 08 Oct 2012 16:21:56 -0700 (PDT) X-Google-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:x-gm-message-state; bh=Qt5FqnclnY6D9MYbHGVKJhT/W4vvjZkbZAgNZG2DKmg=; b=WDJjN6RyrsxzUeawMz7ZHfiMM2Ant1pqcUdZDipDVbqRHaJqt49RhxyDr/MR9BbZRq rY6NFlKfqWGX0hsUF2Y9KgpV5l73UJvCNYULz2Xwtlv/JcHo6GGxTuNLYQeTTmg4bjSI 8K3czZDnhwLoe/ejCZp2uM1uTf34yh5I48jqaZdnj06l4YFVLs3vDgBYLrQhHHUCpKhZ sHzB8rJ14UKUrGifdmij0JGjzRVkSWOnWFOSSlOtRX7TrFTWMddoqxgkiItbpXilPfpu cbBmGg6QinxYI1UcY4X7JO+Yyd8/cvSu7LYltRhMDms/liLPCqdVXGx7qYyqsrWkSrpy sA9g== Received: by 10.68.116.239 with SMTP id jz15mr57148830pbb.43.1349738516372; Mon, 08 Oct 2012 16:21:56 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by mx.google.com with ESMTPS id vu7sm11370706pbc.9.2012.10.08.16.21.54 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Oct 2012 16:21:54 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so4487134pad.31 for ; Mon, 08 Oct 2012 16:21:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.86.133 with SMTP id p5mr46855536paz.35.1349738513762; Mon, 08 Oct 2012 16:21:53 -0700 (PDT) Received: by 10.68.42.8 with HTTP; Mon, 8 Oct 2012 16:21:53 -0700 (PDT) In-Reply-To: <723C9B03-B45B-4214-9A36-7B4CEBD2FC2E@iii.ca> References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <723C9B03-B45B-4214-9A36-7B4CEBD2FC2E@iii.ca> Date: Mon, 8 Oct 2012 19:21:53 -0400 Message-ID: From: Roman Shpount To: Cullen Jennings Content-Type: multipart/alternative; boundary=f46d042de40ba70a3404cb947ca7 X-Gm-Message-State: ALoCoQkJnTrHTn/+uqhWgBO6e1toWzhMwbVy5ScNdEtxRlsD1dUQElN+8J+12JXEKg4C3ETfdEOu Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Oct 2012 23:21:58 -0000 --f46d042de40ba70a3404cb947ca7 Content-Type: text/plain; charset=ISO-8859-1 The scenario is: WebRTC is placing a call through some sort of gateway to a SIP end point. It sends an offer that gets translated into INVITE with SDP. SIP end point sends back 183 with SDP that gets delivered to the WebRTC end point as PRANSWER. Then SIP end point sends an UPDATE with SDP in early dialog. And then finally SIP end point sends 200 OK with different SDP. I am not sure how to translate the SDP in UPDATE and the final answer in WebRTC API calls. I would guess this is not something that can be supported without cloning. _____________ Roman Shpount On Mon, Oct 8, 2012 at 7:09 PM, Cullen Jennings wrote: > > Walk me through what the call flow would like it both endpoints were SIP > UA's so I understand it better. > > > Note - I'm not against folks trying to figure out clone. I'm saying that > we should not get rid of PRANSWER. > > > On Oct 8, 2012, at 15:58 , Roman Shpount wrote: > > > Cullen, > > > > I have an existing interop problem with SIP serial forking that I cannot > solve with the proposed schema. With PRANSWER, how would I handle SIP > UPDATE sith SDP received in early dialog? > > > > Regards, > > _____________ > > Roman Shpount > > > > > > On Mon, Oct 8, 2012 at 6:53 PM, Cullen Jennings (fluffy) < > fluffy@cisco.com> wrote: > > > > On Oct 8, 2012, at 2:47 , Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > > > Hi, > > > > > > I would like to discuss the different alternatives in order to support > forking, e.g. whether we use cloning, whether we simply set additional > local descriptor, and whether we can get rid of PRANSWER. > > > > Seriously? we have discussed this so many times and always come to the > same conclusion. I have not seen anything on the list that suggests why we > need to remove this or how mapping to SIP 180 with sequential forking is > going to work without it. It also has other important uses. There are a > bunch of changes that are needed to the JSEP draft to remove some of the > inconsistencies in this and clarify some parts but I'd rather wait till we > had that updated before we got into a whole discussion about exploding it > yet again. > > > > Why don't we have a phone call to try and outline what the problems you > are trying to solve that the current solution does not work for then figure > out how much we want to explode this. > > > > I'll note that current clone text has lots of "miracles happen here, > insert supper fluffy hand wave" in it and plenty of weasel room on failure > to allocate required resources on the clone. It's more or less a sketch of > an idea at this point. I'm perfectly happy to see people try and sort out > the details on clone but using it explode the consensus we have come to > around PRANSWER seems like a really bad idea at this point. > > > > 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 > > --f46d042de40ba70a3404cb947ca7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The scenario is:

WebRTC is placing a call through some s= ort of gateway to a SIP end point. It sends an offer that gets translated i= nto INVITE with SDP. SIP end point sends back 183 with SDP that gets delive= red to the WebRTC end point as PRANSWER. Then SIP end point sends an UPDATE= with SDP in early dialog. And then finally SIP end point sends 200 OK with= different SDP. I am not sure how to translate the SDP in UPDATE and the fi= nal answer in WebRTC API calls. I would guess this is not something that ca= n be supported without cloning.
_____________
Roman Shpount


On Mon, Oct 8, 2012 at 7:09 PM, Cullen J= ennings <fluffy@iii.ca> wrote:

Walk me through what the call flow would like it both endpoints were SIP UA= 's so I understand it better.


Note - I'm not against folks trying to figure out clone. I'm saying= that we should not get rid of PRANSWER.


On Oct 8, 2012, at 15:58 , Roman Shpount <roman@telurix.com> wrote:

> Cullen,
>
> I have an existing interop problem with SIP serial forking that I cann= ot solve with the proposed schema. With PRANSWER, how would I handle SIP UP= DATE sith SDP received in early dialog?
>
> Regards,
> _____________
> Roman Shpount
>
>
> On Mon, Oct 8, 2012 at 6:53 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
>
> On Oct 8, 2012, at 2:47 , Christer Holmberg <christer.holmberg@ericsson.com> wrote: >
> > Hi,
> >
> > I would like to discuss the different alternatives in order to su= pport forking, e.g. whether we use cloning, whether we simply set additiona= l local descriptor, and whether we can get rid of PRANSWER.
>
> Seriously? we have discussed this so many times and always come to the= same conclusion. I have not seen anything on the list that suggests why we= need to remove this or how mapping to SIP 180 with sequential forking is g= oing to work without it. It also has other important uses. There are a bunc= h of changes that are needed to the JSEP draft to remove some of the incons= istencies in this and clarify some parts but I'd rather wait till we ha= d that updated before we got into a whole discussion about exploding it yet= again.
>
> Why don't we have a phone call to try and outline what the problem= s you are trying to solve that the current solution does not work for then = figure out how much we want to explode this.
>
> I'll note that current clone text has lots of "miracles happe= n here, insert supper fluffy hand wave" in it and plenty of weasel roo= m on failure to allocate required resources on the clone. It's more or = less a sketch of an idea at this point. I'm perfectly happy to see peop= le try and sort out the details on clone but using it explode the consensus= we have come to around PRANSWER seems like a really bad idea at this point= .
>
> 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


--f46d042de40ba70a3404cb947ca7-- From fluffy@cisco.com Mon Oct 8 17:42:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D2E1F0C89 for ; Mon, 8 Oct 2012 17:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.479 X-Spam-Level: X-Spam-Status: No, score=-110.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hgKRfIhLydi for ; Mon, 8 Oct 2012 17:42:50 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C75B31F0C88 for ; Mon, 8 Oct 2012 17:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4193; q=dns/txt; s=iport; t=1349743369; x=1350952969; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RoEunSHusciaxKzMVqn/C5lteTf3PFl1QDiok7i133g=; b=DJhmV9HFaR4QXVOKEhSjn8hxkiGxoLG9rgvPyI6fZ8AOtmUJf75osm76 PNEWu+VnjnbqGHhmP3/2c5TN+wn5I7/hKE35qrhrMmIw8MSeL5O5FFp+1 kPuYxsaDnJCXMzld0J5/3AJnYFjz9T09B1tRWu1jgR3I6cKEz4B2kbfdk s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIJyc1CtJV2b/2dsb2JhbABFvzKBCIIgAQEBAwEBAQEPATQnCwULAgEIGAokJwslAgQOBQgTB4ddBguaRI9WgTaOdASLR4UzYAOII4oXkXaBaYJtghc X-IronPort-AV: E=Sophos;i="4.80,556,1344211200"; d="scan'208";a="129592453" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 09 Oct 2012 00:42:49 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q990gnTW022178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 00:42:49 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.001; Mon, 8 Oct 2012 19:42:49 -0500 From: "Cullen Jennings (fluffy)" To: Roman Shpount Thread-Topic: [rtcweb] Agenda requests for Atlanta meeting Thread-Index: AQHNpaetkG2ADNG+3EO5+NGGgdEEepewWX6AgAAC9ICAAAN2gIAAFs4A Date: Tue, 9 Oct 2012 00:42:48 +0000 Message-ID: References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <723C9B03-B45B-4214-9A36-7B4CEBD2FC2E@iii.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.86.152] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19252.004 x-tm-as-result: No--56.191700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6EC6EDDA272F1B45894CE545A2ED2EB9@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Oct 2012 00:42:51 -0000 Check out text from RFC 3311 that says=20 o If the UPDATE is being sent before the completion of the INVITE transaction, and the initial INVITE contained an offer, the UPDATE cannot be sent with an offer unless the callee has generated an answer in a reliable provisional response, has received a PRACK for that reliable provisional response, has not received any requests (PRACK or UPDATE) with offers that it has not answered, and has not sent any UPDATE requests containing offers that have not been answered. So the 183 would be need to be sent reliably at which case I would expect t= he gateways to map it to a final offer in RTCWeb not a provisional one. At = that point when the update comes along with an offer, it just mapped to RTC= web offer.=20 On Oct 8, 2012, at 16:21 , Roman Shpount wrote: > The scenario is: >=20 > WebRTC is placing a call through some sort of gateway to a SIP end point.= It sends an offer that gets translated into INVITE with SDP. SIP end point= sends back 183 with SDP that gets delivered to the WebRTC end point as PRA= NSWER. Then SIP end point sends an UPDATE with SDP in early dialog. And the= n finally SIP end point sends 200 OK with different SDP. I am not sure how = to translate the SDP in UPDATE and the final answer in WebRTC API calls. I = would guess this is not something that can be supported without cloning. > _____________ > Roman Shpount >=20 >=20 > On Mon, Oct 8, 2012 at 7:09 PM, Cullen Jennings wrote: >=20 > Walk me through what the call flow would like it both endpoints were SIP = UA's so I understand it better. >=20 >=20 > Note - I'm not against folks trying to figure out clone. I'm saying that = we should not get rid of PRANSWER. >=20 >=20 > On Oct 8, 2012, at 15:58 , Roman Shpount wrote: >=20 > > Cullen, > > > > I have an existing interop problem with SIP serial forking that I canno= t solve with the proposed schema. With PRANSWER, how would I handle SIP UPD= ATE sith SDP received in early dialog? > > > > Regards, > > _____________ > > Roman Shpount > > > > > > On Mon, Oct 8, 2012 at 6:53 PM, Cullen Jennings (fluffy) wrote: > > > > On Oct 8, 2012, at 2:47 , Christer Holmberg wrote: > > > > > Hi, > > > > > > I would like to discuss the different alternatives in order to suppor= t forking, e.g. whether we use cloning, whether we simply set additional lo= cal descriptor, and whether we can get rid of PRANSWER. > > > > Seriously? we have discussed this so many times and always come to the = same conclusion. I have not seen anything on the list that suggests why we = need to remove this or how mapping to SIP 180 with sequential forking is go= ing to work without it. It also has other important uses. There are a bunch= of changes that are needed to the JSEP draft to remove some of the inconsi= stencies in this and clarify some parts but I'd rather wait till we had tha= t updated before we got into a whole discussion about exploding it yet agai= n. > > > > Why don't we have a phone call to try and outline what the problems you= are trying to solve that the current solution does not work for then figur= e out how much we want to explode this. > > > > I'll note that current clone text has lots of "miracles happen here, in= sert supper fluffy hand wave" in it and plenty of weasel room on failure to= allocate required resources on the clone. It's more or less a sketch of an= idea at this point. I'm perfectly happy to see people try and sort out the= details on clone but using it explode the consensus we have come to around= PRANSWER seems like a really bad idea at this point. > > > > 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 From fluffy@iii.ca Mon Oct 8 17:47:09 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F45011E80DF for ; Mon, 8 Oct 2012 17:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QK1XqzAQalKA for ; Mon, 8 Oct 2012 17:47:08 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id E75CE11E809B for ; Mon, 8 Oct 2012 17:47:06 -0700 (PDT) Received: from [10.21.86.152] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 074A522E253; Mon, 8 Oct 2012 20:46:56 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Cullen Jennings In-Reply-To: <17E29D7C-A9D9-4AF9-9514-F44DB54CDEAA@cisco.com> Date: Mon, 8 Oct 2012 17:47:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <723C9B03-B45B-4214-9A36-7B4CEBD2FC2E@iii.ca> <17E29D7C-A9D9-4AF9-9514-F44DB54CDEAA@cisco.com> To: Roman Shpount X-Mailer: Apple Mail (2.1499) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Oct 2012 00:47:09 -0000 One other thought on this. I think this just points out that it would be = really nice to have a draft that showed how to build a RTCWeb / SIP = gateway.=20 =20 On Oct 8, 2012, at 17:42 , Cullen Jennings wrote: >=20 > Check out text from RFC 3311 that says=20 >=20 > o If the UPDATE is being sent before the completion of the = INVITE > transaction, and the initial INVITE contained an offer, the > UPDATE cannot be sent with an offer unless the callee has > generated an answer in a reliable provisional response, has > received a PRACK for that reliable provisional response, has > not received any requests (PRACK or UPDATE) with offers that = it > has not answered, and has not sent any UPDATE requests > containing offers that have not been answered. >=20 > So the 183 would be need to be sent reliably at which case I would = expect the gateways to map it to a final offer in RTCWeb not a = provisional one. At that point when the update comes along with an = offer, it just mapped to RTCweb offer.=20 >=20 >=20 > On Oct 8, 2012, at 16:21 , Roman Shpount > wrote: >=20 >> The scenario is: >>=20 >> WebRTC is placing a call through some sort of gateway to a SIP end = point. It sends an offer that gets translated into INVITE with SDP. SIP = end point sends back 183 with SDP that gets delivered to the WebRTC end = point as PRANSWER. Then SIP end point sends an UPDATE with SDP in early = dialog. And then finally SIP end point sends 200 OK with different SDP. = I am not sure how to translate the SDP in UPDATE and the final answer in = WebRTC API calls. I would guess this is not something that can be = supported without cloning. >> _____________ >> Roman Shpount >>=20 >>=20 >> On Mon, Oct 8, 2012 at 7:09 PM, Cullen Jennings = wrote: >>=20 >> Walk me through what the call flow would like it both endpoints were = SIP UA's so I understand it better. >>=20 >>=20 >> Note - I'm not against folks trying to figure out clone. I'm saying = that we should not get rid of PRANSWER. >>=20 >>=20 >> On Oct 8, 2012, at 15:58 , Roman Shpount wrote: >>=20 >>> Cullen, >>>=20 >>> I have an existing interop problem with SIP serial forking that I = cannot solve with the proposed schema. With PRANSWER, how would I handle = SIP UPDATE sith SDP received in early dialog? >>>=20 >>> Regards, >>> _____________ >>> Roman Shpount >>>=20 >>>=20 >>> On Mon, Oct 8, 2012 at 6:53 PM, Cullen Jennings (fluffy) = wrote: >>>=20 >>> On Oct 8, 2012, at 2:47 , Christer Holmberg = wrote: >>>=20 >>>> Hi, >>>>=20 >>>> I would like to discuss the different alternatives in order to = support forking, e.g. whether we use cloning, whether we simply set = additional local descriptor, and whether we can get rid of PRANSWER. >>>=20 >>> Seriously? we have discussed this so many times and always come to = the same conclusion. I have not seen anything on the list that suggests = why we need to remove this or how mapping to SIP 180 with sequential = forking is going to work without it. It also has other important uses. = There are a bunch of changes that are needed to the JSEP draft to remove = some of the inconsistencies in this and clarify some parts but I'd = rather wait till we had that updated before we got into a whole = discussion about exploding it yet again. >>>=20 >>> Why don't we have a phone call to try and outline what the problems = you are trying to solve that the current solution does not work for then = figure out how much we want to explode this. >>>=20 >>> I'll note that current clone text has lots of "miracles happen here, = insert supper fluffy hand wave" in it and plenty of weasel room on = failure to allocate required resources on the clone. It's more or less a = sketch of an idea at this point. I'm perfectly happy to see people try = and sort out the details on clone but using it explode the consensus we = have come to around PRANSWER seems like a really bad idea at this point. >>>=20 >>> Cullen >>>=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 >>=20 >=20 From roman@telurix.com Mon Oct 8 18:24:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D661F0420 for ; Mon, 8 Oct 2012 18:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJ6vkkbyaUqH for ; Mon, 8 Oct 2012 18:24:12 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8E74E21F87E3 for ; Mon, 8 Oct 2012 18:24:08 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so4621762pbb.31 for ; Mon, 08 Oct 2012 18:24:08 -0700 (PDT) X-Google-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:x-gm-message-state; bh=xkpyf4l/OeXzDfDwjAx3uvq+aMGXRxVIcuAK+hnICcw=; b=ZN5ADD9XNQ1m4NUf9ZnDfnaPhlntFnDeMkU69qSUKAYEaR9WMVSeyYGAJ9maZQOpvu o6cSxpvvuBmieDYp6XV6DCACwJn8c4carAMWAHLDTV3esVoIUJq4bIljHZkI+3OFE+BA /aaou3DpJ72jlcuL2rY1g5KB0tn/1aUk7vlyLxTjQONfKHEFlQ97kDYFDdgGlRWyQCHp RAZeeDj/jHPMr/9842GJhCT1EtMzxV/dEqZqwxdfyY1JPDl2RBYn1Y+LOt80si+0Sy43 gHEg/593wwmbLJDqvTRv2aaaVVTZ7kfgi4IQKqtwggFyQWKoklLGm+Ys1H54dwXumFFW Y+lA== Received: by 10.68.228.98 with SMTP id sh2mr58646524pbc.95.1349745848133; Mon, 08 Oct 2012 18:24:08 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id ih2sm11500125pbc.65.2012.10.08.18.24.06 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Oct 2012 18:24:07 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so4621742pbb.31 for ; Mon, 08 Oct 2012 18:24:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.189.70 with SMTP id gg6mr58965670pbc.125.1349745846162; Mon, 08 Oct 2012 18:24:06 -0700 (PDT) Received: by 10.68.42.8 with HTTP; Mon, 8 Oct 2012 18:24:06 -0700 (PDT) In-Reply-To: References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <723C9B03-B45B-4214-9A36-7B4CEBD2FC2E@iii.ca> Date: Mon, 8 Oct 2012 21:24:06 -0400 Message-ID: From: Roman Shpount To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=e89a8ff1c03eb2966904cb963184 X-Gm-Message-State: ALoCoQkzOIZdpuzbRnCMYFQLrONP39qJ3xtmM2nz3K7jrlCqLU4F92xO8N4lbCsTY4vylr/zXIYo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Oct 2012 01:24:13 -0000 --e89a8ff1c03eb2966904cb963184 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 8, 2012 at 8:42 PM, Cullen Jennings (fluffy) wrote: > > Check out text from RFC 3311 that says > > o If the UPDATE is being sent before the completion of the INVITE > transaction, and the initial INVITE contained an offer, the > UPDATE cannot be sent with an offer unless the callee has > generated an answer in a reliable provisional response, has > received a PRACK for that reliable provisional response, has > not received any requests (PRACK or UPDATE) with offers that it > has not answered, and has not sent any UPDATE requests > containing offers that have not been answered. > > So the 183 would be need to be sent reliably at which case I would expect > the gateways to map it to a final offer in RTCWeb not a provisional one. At > that point when the update comes along with an offer, it just mapped to > RTCweb offer. > > And what happens with the next 183 or 200 OK sent reliably in a different dialog? When we are dealing with serial forking we are dealing with different sequential dialogs created by the same offer, aren't we? Otherwise this is not really standard compliant. _____________ Roman Shpount --e89a8ff1c03eb2966904cb963184 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Oct 8, 2012 at 8:4= 2 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Check out text from RFC 3311 that says

=A0 =A0 =A0 o =A0If the UPDATE is being sent before the completion of the I= NVITE
=A0 =A0 =A0 =A0 =A0transaction, and the initial INVITE contained an offer, = the
=A0 =A0 =A0 =A0 =A0UPDATE cannot be sent with an offer unless the callee ha= s
=A0 =A0 =A0 =A0 =A0generated an answer in a reliable provisional response, = has
=A0 =A0 =A0 =A0 =A0received a PRACK for that reliable provisional response,= has
=A0 =A0 =A0 =A0 =A0not received any requests (PRACK or UPDATE) with offers = that it
=A0 =A0 =A0 =A0 =A0has not answered, and has not sent any UPDATE requests =A0 =A0 =A0 =A0 =A0containing offers that have not been answered.

So the 183 would be need to be sent reliably at which case I would expect t= he gateways to map it to a final offer in RTCWeb not a provisional one. At = that point when the update comes along with an offer, it just mapped to RTC= web offer.


And what happens with the next 183 or = 200 OK sent reliably in a different dialog? When we are dealing with serial= forking we are dealing with different sequential dialogs created by the sa= me offer, aren't we? Otherwise this is not really standard compliant.= =A0
_____________
Roman Shpount

=A0
--e89a8ff1c03eb2966904cb963184-- From fluffy@cisco.com Mon Oct 8 18:26:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD8C11E80DF for ; Mon, 8 Oct 2012 18:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.485 X-Spam-Level: X-Spam-Status: No, score=-110.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-9Np30xLamr for ; Mon, 8 Oct 2012 18:26:51 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 9C07411E80F0 for ; Mon, 8 Oct 2012 18:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1657; q=dns/txt; s=iport; t=1349746011; x=1350955611; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YaY36D7fs71kC0UundiABtwUlrUs1K7HuzI1Mw3mBXs=; b=O0p6bqPYT5TEpR9ZIcRQb3hzBiQK9Wfgxo97OizwPh5J/+sTjeWdaFTi R+LsauAnNOywR+zQuUUh44fSy0IRJhzdl0LvSmeT9fewxhL7anofHDxjN /UoY1vM6Qg5h3EzfIAVEcKrRMZcK+md6uiuw5CVOPe8uotCYL1Uy+u3Tt I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAIl8c1CtJXHB/2dsb2JhbABFvzKBCIIgAQEBAwESAWYQAgEIGAokMiUCBA4FCBqHXQaaYY9WkDKLR4UzYAOII5wNgWmCbYIX X-IronPort-AV: E=Sophos;i="4.80,556,1344211200"; d="scan'208";a="129543553" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 09 Oct 2012 01:26:51 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q991QpEb010379 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 01:26:51 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Mon, 8 Oct 2012 20:26:50 -0500 From: "Cullen Jennings (fluffy)" To: Roman Shpount Thread-Topic: [rtcweb] Agenda requests for Atlanta meeting Thread-Index: AQHNpaetkG2ADNG+3EO5+NGGgdEEepewWX6AgAAC9ICAAAN2gIAAFs4AgAALWACAAAD2AA== Date: Tue, 9 Oct 2012 01:26:50 +0000 Message-ID: References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <723C9B03-B45B-4214-9A36-7B4CEBD2FC2E@iii.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.86.152] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19252.004 x-tm-as-result: No--38.416600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <550F2861923FC947B18371ABFB342B3B@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Oct 2012 01:26:52 -0000 Well, what's the end user experience you're trying to achieve - lets say w= e are talking about audio. Do you want to play the first one or the last on= e? If you want to bridge them into a party line, this is probably not how y= ou want the SIP side to happen.=20 On Oct 8, 2012, at 18:24 , Roman Shpount wrote: >=20 >=20 > On Mon, Oct 8, 2012 at 8:42 PM, Cullen Jennings (fluffy) wrote: >=20 > Check out text from RFC 3311 that says >=20 > o If the UPDATE is being sent before the completion of the INVITE > transaction, and the initial INVITE contained an offer, the > UPDATE cannot be sent with an offer unless the callee has > generated an answer in a reliable provisional response, has > received a PRACK for that reliable provisional response, has > not received any requests (PRACK or UPDATE) with offers that it > has not answered, and has not sent any UPDATE requests > containing offers that have not been answered. >=20 > So the 183 would be need to be sent reliably at which case I would expect= the gateways to map it to a final offer in RTCWeb not a provisional one. A= t that point when the update comes along with an offer, it just mapped to R= TCweb offer. >=20 >=20 > And what happens with the next 183 or 200 OK sent reliably in a different= dialog? When we are dealing with serial forking we are dealing with differ= ent sequential dialogs created by the same offer, aren't we? Otherwise this= is not really standard compliant.=20 > _____________ > Roman Shpount >=20 > =20 From roman@telurix.com Mon Oct 8 18:31:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F3221F87FF for ; Mon, 8 Oct 2012 18:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7HkQcSd+DPE for ; Mon, 8 Oct 2012 18:31:54 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC51921F87E3 for ; Mon, 8 Oct 2012 18:31:54 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so1870476dan.31 for ; Mon, 08 Oct 2012 18:31:54 -0700 (PDT) X-Google-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:x-gm-message-state; bh=mnw4DSzXxRbyW9DmvX+uV9Yeqjqb0z7BjrNH3wQrmAM=; b=HKDTAihyAejVZ2e05Lp4do1bdcCLSv6ZKfPLJs8DWxUqi3A/pG614AdjehIErnCvun hIa9lgoGPqaza30wiPSyYGCJUFoJkjGXL0w4MEPjN50QRg4cLDucoJ+GR1J8/3pK7JuY UF1yhP86FUWi0zCx76s2f30R+g/1HFVCLv3CT84J4f9he17F4tP60M7FSAHFWkMm3Vno WZozqNjcmaEQbB7hQ+g5lLEXHEI1daRNjsHyGMSKC+VvkQ3VtTl0QC7YKvt5QuCBmwSt vUsBUBEencB6XWvYyVWFPqccUrf5UvOBs52dornG5sMRGagnhic29wizj9CIQNGASYXa EM5A== Received: by 10.68.135.168 with SMTP id pt8mr59654866pbb.24.1349746314365; Mon, 08 Oct 2012 18:31:54 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id w4sm11668925paz.38.2012.10.08.18.31.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Oct 2012 18:31:53 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so4627081pbb.31 for ; Mon, 08 Oct 2012 18:31:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.141.46 with SMTP id rl14mr58591224pbb.2.1349746312714; Mon, 08 Oct 2012 18:31:52 -0700 (PDT) Received: by 10.68.42.8 with HTTP; Mon, 8 Oct 2012 18:31:52 -0700 (PDT) In-Reply-To: References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <723C9B03-B45B-4214-9A36-7B4CEBD2FC2E@iii.ca> Date: Mon, 8 Oct 2012 21:31:52 -0400 Message-ID: From: Roman Shpount To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=047d7b1121a581984504cb964d2a X-Gm-Message-State: ALoCoQnc+HlPEto08cz6rqTBogD5NCGpZQiAnA94ZUdZXH2H3Ahyi4BKLwiAlhQSCxZW+I1+3x7A Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Oct 2012 01:31:55 -0000 --047d7b1121a581984504cb964d2a Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 8, 2012 at 9:26 PM, Cullen Jennings (fluffy) wrote: > > Well, what's the end user experience you're trying to achieve - lets say > we are talking about audio. Do you want to play the first one or the last > one? If you want to bridge them into a party line, this is probably not how > you want the SIP side to happen. > > This is still serial forking. Imagine the following scenario: You are calling a phone number, you dial first provider who starts playing a dial tone then uses an UPDATE to connect you to a media server to play an announcement after which your call goes to voice mail (another dialog and another SDP). This is all fairly legal and not unusual for SIP scenarios. Nothing to do with party lines. _____________ Roman Shpount --047d7b1121a581984504cb964d2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 8, 2012 at 9:26 PM, Cullen Jennings (fluffy) = <fluffy@cisco.com<= /a>> wrote:

Well, what's the end user experience you're trying to achieve =A0- = lets say we are talking about audio. Do you want to play the first one or t= he last one? If you want to bridge them into a party line, this is probably= not how you want the SIP side to happen.


This is still serial forking. Imagine the f= ollowing scenario: You are calling a phone number, you dial first provider = who starts playing a dial tone then uses an UPDATE to connect you to a medi= a server to play an announcement after which your call goes to voice mail (= another dialog and another SDP). This is all fairly legal and not unusual f= or SIP scenarios. Nothing to do with party lines.
_____________
Roman Shpount

=A0
--047d7b1121a581984504cb964d2a-- From fluffy@iii.ca Mon Oct 8 18:41:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB02F11E80DF for ; Mon, 8 Oct 2012 18:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxDoeO9RuSW1 for ; Mon, 8 Oct 2012 18:41:01 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5660211E80DE for ; Mon, 8 Oct 2012 18:41:01 -0700 (PDT) Received: from [10.21.86.152] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1668E22E25C; Mon, 8 Oct 2012 21:40:52 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Cullen Jennings In-Reply-To: Date: Mon, 8 Oct 2012 18:41:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <98BB750F-F263-44BB-9CC3-1F0816C11061@iii.ca> References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <723C9B03-B45B-4214-9A36-7B4CEBD2FC2E@iii.ca> To: Roman Shpount X-Mailer: Apple Mail (2.1499) Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Oct 2012 01:41:01 -0000 On Oct 8, 2012, at 18:31 , Roman Shpount wrote: > On Mon, Oct 8, 2012 at 9:26 PM, Cullen Jennings (fluffy) = wrote: >=20 > Well, what's the end user experience you're trying to achieve - lets = say we are talking about audio. Do you want to play the first one or the = last one? If you want to bridge them into a party line, this is probably = not how you want the SIP side to happen. >=20 >=20 > This is still serial forking. Imagine the following scenario: You are = calling a phone number, you dial first provider who starts playing a = dial tone then uses an UPDATE to connect you to a media server to play = an announcement after which your call goes to voice mail (another dialog = and another SDP). This is all fairly legal and not unusual for SIP = scenarios. Nothing to do with party lines. > _____________ > Roman Shpount >=20 Ok, serial forking with early media seems like it should work. Seems = like the browser would make the offer, that gateway turned into SIP = invite that then went to sequential forking proxy that send sent the = invite to UA A. UA A returns a 180 that gets mapped to PRANSWER, the = proxy then forks to UA B that sends a 200 on a different dialog that = gets mapped to answer.=20= From roman@telurix.com Mon Oct 8 18:56:30 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877771F041F for ; Mon, 8 Oct 2012 18:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koF18A2C5QTu for ; Mon, 8 Oct 2012 18:56:29 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 824641F0417 for ; Mon, 8 Oct 2012 18:56:29 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so6157311vcb.31 for ; Mon, 08 Oct 2012 18:56:29 -0700 (PDT) X-Google-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:x-gm-message-state; bh=+Irm/tNDLXNKc3LzxiTxzUWLDl5FW9pBph6fBtYLoBo=; b=n88Oo8EsMGd/7OTlrAFsgjOzMuTooiPXMTJj+j2jmev4vCSrFh5fjB5jfwkI1IH2sh VgUZ43WUVvuNmea1Ft6ZQKiHFuRRMaKRPecThaxHxsbBwlXzn5hNUcKQUrMQ3qeCGKF9 LlLJSFc6j2f2pDKsv8ZSlHju+oZl93rG0P8AYKTUoD2ekMNqapojQYoKyJijLV6ari1S u0mWq5rKRL5J8QqRAHiF06K7nEfusnyDMblyz5Erk7BfupLgwGBswjlpt5uCT9hsQJcQ ozUGaaZuSgBxph3N0VXcdCJzNFuTUspjWVmJXMMLYkDcyVERc8wXJtbORWrxZlWObk9v figQ== Received: by 10.220.208.210 with SMTP id gd18mr10764049vcb.43.1349747788986; Mon, 08 Oct 2012 18:56:28 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by mx.google.com with ESMTPS id b3sm1466874vec.11.2012.10.08.18.56.28 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Oct 2012 18:56:28 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so6157283vcb.31 for ; Mon, 08 Oct 2012 18:56:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.230.133 with SMTP id jm5mr10915592vcb.4.1349747787692; Mon, 08 Oct 2012 18:56:27 -0700 (PDT) Received: by 10.58.240.84 with HTTP; Mon, 8 Oct 2012 18:56:27 -0700 (PDT) In-Reply-To: <98BB750F-F263-44BB-9CC3-1F0816C11061@iii.ca> References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <723C9B03-B45B-4214-9A36-7B4CEBD2FC2E@iii.ca> <98BB750F-F263-44BB-9CC3-1F0816C11061@iii.ca> Date: Mon, 8 Oct 2012 21:56:27 -0400 Message-ID: From: Roman Shpount To: Cullen Jennings Content-Type: multipart/alternative; boundary=14dae9cdc6c16bfa2e04cb96a5b4 X-Gm-Message-State: ALoCoQmfjxrCwRhZL2nf7c9JBlTC+A9LtlmQa20xYSBtzO5heS+Y2GI8nWEs6vMfaHom/6FtGTJ0 Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Oct 2012 01:56:30 -0000 --14dae9cdc6c16bfa2e04cb96a5b4 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 8, 2012 at 9:41 PM, Cullen Jennings wrote: > > On Oct 8, 2012, at 18:31 , Roman Shpount wrote: > > > On Mon, Oct 8, 2012 at 9:26 PM, Cullen Jennings (fluffy) < > fluffy@cisco.com> wrote: > > > > Well, what's the end user experience you're trying to achieve - lets > say we are talking about audio. Do you want to play the first one or the > last one? If you want to bridge them into a party line, this is probably > not how you want the SIP side to happen. > > > > > > This is still serial forking. Imagine the following scenario: You are > calling a phone number, you dial first provider who starts playing a dial > tone then uses an UPDATE to connect you to a media server to play an > announcement after which your call goes to voice mail (another dialog and > another SDP). This is all fairly legal and not unusual for SIP scenarios. > Nothing to do with party lines. > > Ok, serial forking with early media seems like it should work. Seems like > the browser would make the offer, that gateway turned into SIP invite that > then went to sequential forking proxy that send sent the invite to UA A. UA > A returns a 180 that gets mapped to PRANSWER, the proxy then forks to UA B > that sends a 200 on a different dialog that gets mapped to answer. The only issue is the there is currently no way to map an UPDATE received in the early dialog to WebRTC API calls. I am probably OK with it not being handled until the cloning is implemented, but this shows that PRANSWER is not very useful even for the serial forking. _____________ Roman Shpount --14dae9cdc6c16bfa2e04cb96a5b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 8, 2012 at 9:41 PM, Cullen Jennings <fluffy@iii.ca> = wrote:

On Oct 8, 2012, at 18:31 , Roman Shpount <roman@telurix.com> wrote:

> On Mon, Oct 8, 2012 at 9:26 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
>
> Well, what's the end user experience you're trying to achieve = =A0- lets say we are talking about audio. Do you want to play the first one= or the last one? If you want to bridge them into a party line, this is pro= bably not how you want the SIP side to happen.
>
>
> This is still serial forking. Imagine the following scenario: You are = calling a phone number, you dial first provider who starts playing a dial t= one then uses an UPDATE to connect you to a media server to play an announc= ement after which your call goes to voice mail (another dialog and another = SDP). This is all fairly legal and not unusual for SIP scenarios. Nothing t= o do with party lines.

Ok, serial forking with early media seems like it should work. = Seems like the browser would make the offer, that gateway turned into SIP i= nvite that then went to sequential forking proxy that send sent the invite = to UA A. UA A returns a 180 that gets mapped to PRANSWER, the proxy then fo= rks to UA B that sends a 200 on a different dialog that gets mapped to answ= er.

=A0The only issue is the there is currently no way to map an UPDA= TE received in the early dialog to WebRTC API calls. I am probably OK with = it not being handled until the cloning is implemented, but this shows that = PRANSWER is not very useful even for the serial forking.
_____________
Roman Shpount


--14dae9cdc6c16bfa2e04cb96a5b4-- From fluffy@iii.ca Mon Oct 8 19:30:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E911F0C54 for ; Mon, 8 Oct 2012 19:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X43zr83cY8pi for ; Mon, 8 Oct 2012 19:30:11 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 58DEF1F0423 for ; Mon, 8 Oct 2012 19:30:11 -0700 (PDT) Received: from [10.21.86.152] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C3A1022E259; Mon, 8 Oct 2012 22:30:04 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Cullen Jennings In-Reply-To: Date: Mon, 8 Oct 2012 19:30:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <86A92683-F9C3-45AB-B985-573811436850@iii.ca> References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <723C9B03-B45B-4214-9A36-7B4CEBD2FC2E@iii.ca> <98BB750F-F263-44BB-9CC3-1F0816C11061@iii.ca> To: Roman Shpount X-Mailer: Apple Mail (2.1499) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Oct 2012 02:30:12 -0000 On Oct 8, 2012, at 18:56 , Roman Shpount wrote: > On Mon, Oct 8, 2012 at 9:41 PM, Cullen Jennings wrote: >=20 > On Oct 8, 2012, at 18:31 , Roman Shpount wrote: >=20 > > On Mon, Oct 8, 2012 at 9:26 PM, Cullen Jennings (fluffy) = wrote: > > > > Well, what's the end user experience you're trying to achieve - = lets say we are talking about audio. Do you want to play the first one = or the last one? If you want to bridge them into a party line, this is = probably not how you want the SIP side to happen. > > > > > > This is still serial forking. Imagine the following scenario: You = are calling a phone number, you dial first provider who starts playing a = dial tone then uses an UPDATE to connect you to a media server to play = an announcement after which your call goes to voice mail (another dialog = and another SDP). This is all fairly legal and not unusual for SIP = scenarios. Nothing to do with party lines. >=20 > Ok, serial forking with early media seems like it should work. Seems = like the browser would make the offer, that gateway turned into SIP = invite that then went to sequential forking proxy that send sent the = invite to UA A. UA A returns a 180 that gets mapped to PRANSWER, the = proxy then forks to UA B that sends a 200 on a different dialog that = gets mapped to answer. >=20 > The only issue is the there is currently no way to map an UPDATE = received in the early dialog to WebRTC API calls. I am probably OK with = it not being handled until the cloning is implemented, but this shows = that PRANSWER is not very useful even for the serial forking. >=20 How do you think this work in a SIP only system? Lets say A sends the = invite with offer to proxy that forks to B. Then B does 180Rel followed = by an update. Then the proxy forks to C on a new dialog. Do you think C = can send send early media to A and A is actually going to play it? And = what if B use still sending media - it that case A will be getting media = from B and C at the same time. Do you have devices that do that? Most = people just seem to make voicemail work fine without needing to = introduce this type of complexity. If you know what you want A to do in = this case, I think we can figure out how to make that happen - there's = been a lot of discussion about what a SIP device receiving early media = from two places should do and there was never any really great answer = other than don't do that. =20 The meta issue here is thought this is serial forking at the signalling = level in SIP, it is actually parallel forking from a SDP / media point = of view.=20 The case that started this all was use UPDATE in awaited RFC says is not = allowed. I'm not arguing there are not cases where clone would be = useful, but I do think all the voicemail systems I am familiar with = would work fine with the the simple PRANSWER.=20 From roman@telurix.com Mon Oct 8 19:46:30 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0592011E809B for ; Mon, 8 Oct 2012 19:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zT3L8DzboD69 for ; Mon, 8 Oct 2012 19:46:29 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA6B1F0423 for ; Mon, 8 Oct 2012 19:46:28 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so6219282vcb.31 for ; Mon, 08 Oct 2012 19:46:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=zWx1Yic89ZQpk++XLhc6T4Y8PUJtvl9ZBWl1yxBO/sI=; b=KXmhrEOLockZu3/YbLeq0cStI4Dzq5lfVXYobunStywgUX+2Bglup5Rc/p08J3a7/G b+f9KYIleYOWwqXaDUDNAsNAqbFcwuK6WyVEfqnfoJSkJgE30glhgkUuWsqVPbppBEvD UifeGFO9rghNRzgzoQ5zDh+uJNcCa14QWYOo4NfNlYJfskT6i3JFYTDcKMCRqPYpeUgE 3Z/WL+EA/caAGIsZOHUA1y1JBjpoJemOqdu/AfTDDxQ/HZrTxe9B6MkH9+bJN+ss5K9v JgYL23m873SBWl/20QWVSlQKi+As1Dhn7nRCfwzmXF/kunuvOIwhWkzMkaM2s5AHvJQb 4Wjg== Received: by 10.58.144.232 with SMTP id sp8mr11221706veb.56.1349750785762; Mon, 08 Oct 2012 19:46:25 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by mx.google.com with ESMTPS id v4sm2619038vds.3.2012.10.08.19.46.24 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Oct 2012 19:46:25 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so6219229vcb.31 for ; Mon, 08 Oct 2012 19:46:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.231.8 with SMTP id tc8mr11248180vec.52.1349750783673; Mon, 08 Oct 2012 19:46:23 -0700 (PDT) Received: by 10.58.240.84 with HTTP; Mon, 8 Oct 2012 19:46:23 -0700 (PDT) Date: Mon, 8 Oct 2012 22:46:23 -0400 Message-ID: From: Roman Shpount To: Cullen Jennings Content-Type: multipart/alternative; boundary=047d7bf0d174ff06d204cb97577c X-Gm-Message-State: ALoCoQmZ4SCoYSRpJWZ2aW7XTq/rCGIA0oUAetonmmUO8otZ5oSH7aKL9cXhjkJTpeiT3Gj7kDHe Cc: rtcweb@ietf.org Subject: [rtcweb] PRANSWER is unusable for serial forking X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Oct 2012 02:46:30 -0000 --047d7bf0d174ff06d204cb97577c Content-Type: text/plain; charset=ISO-8859-1 Changing subject On Mon, Oct 8, 2012 at 10:30 PM, Cullen Jennings wrote: > > The only issue is the there is currently no way to map an UPDATE > received in the early dialog to WebRTC API calls. I am probably OK with it > not being handled until the cloning is implemented, but this shows that > PRANSWER is not very useful even for the serial forking. > > > > How do you think this work in a SIP only system? Lets say A sends the > invite with offer to proxy that forks to B. Then B does 180Rel followed by > an update. Then the proxy forks to C on a new dialog. Do you think C can > send send early media to A and A is actually going to play it? And what if > B use still sending media - it that case A will be getting media from B and > C at the same time. Do you have devices that do that? Most people just > seem to make voicemail work fine without needing to introduce this type of > complexity. If you know what you want A to do in this case, I think we can > figure out how to make that happen - there's been a lot of discussion about > what a SIP device receiving early media from two places should do and there > was never any really great answer other than don't do that. > > The meta issue here is thought this is serial forking at the signalling > level in SIP, it is actually parallel forking from a SDP / media point of > view. > > The case that started this all was use UPDATE in awaited RFC says is not > allowed. I'm not arguing there are not cases where clone would be useful, > but I do think all the voicemail systems I am familiar with would work fine > with the the simple PRANSWER. > > This actually works fairly well in the current systems. The fact that UPDATE is used does not mean there are multiple media streams flowing at any given time. And, I am familiar with a couple of systems that do exactly what I have described. Typically some sort of announcement or color-ring-back system followed by a voice mail. I think the problem is that this group picked one interop scenario and added something to support it while arbitrarily deciding that other scenarios should not be supported. SIP does not have serial forking. Offer/Answer does not describe something like this. We either need to define it and make it something that describes some set of existing scenarios or add support for something that is defined. _____________ Roman Shpount --047d7bf0d174ff06d204cb97577c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Changing subject

On Mon, Oct 8, 2012 at = 10:30 PM, Cullen Jennings <fluffy@iii.ca> wrote:
> =A0The only issue is the there= is currently no way to map an UPDATE received in the early dialog to WebRT= C API calls. I am probably OK with it not being handled until the cloning i= s implemented, but this shows that PRANSWER is not very useful even for the= serial forking.
>

How do you think this work in a SIP only system? Lets say A sen= ds the invite with offer to proxy that forks to B. Then B does 180Rel follo= wed by an update. Then the proxy forks to C on a new dialog. Do you think C= can send send early media to A and A is actually going to play it? And wha= t if B use still sending media - it that case A will be getting media from = B and C at the same time. Do you have devices that do that? =A0Most people = just seem to make voicemail work fine without needing to introduce this typ= e of complexity. If you know what you want A to do in this case, I think we= can figure out how to make that happen - there's been a lot of discuss= ion about what a SIP device receiving early media from two places should do= and there was never any really great answer other than don't do that.<= br>
The meta issue here is thought this is serial forking at the signalling lev= el in SIP, it is actually parallel forking from a SDP / media =A0point of v= iew.

The case that started this all was use UPDATE in awaited RFC says is not al= lowed. I'm not arguing there are not cases where clone would be useful,= but I do think all the voicemail systems I am familiar with would work fin= e with the the simple PRANSWER.


This actually works fairly well in the= current systems. The fact that UPDATE is used does not mean there are mult= iple media streams flowing at any given time. And, I am familiar with a cou= ple of systems that do exactly what I have described. Typically some sort o= f announcement or color-ring-back system followed by a voice mail. I think = the problem is that this group picked one interop scenario and added someth= ing to support it while arbitrarily deciding that other scenarios should no= t be supported. SIP does not have serial forking. Offer/Answer does not des= cribe something like this. We either need to define it and make it somethin= g that describes some set of existing scenarios or add support for somethin= g that is defined.
_____________
Roman Shpount

=A0
--047d7bf0d174ff06d204cb97577c-- From christer.holmberg@ericsson.com Mon Oct 8 23:23:36 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 182CE21F8413 for ; Mon, 8 Oct 2012 23:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.123 X-Spam-Level: X-Spam-Status: No, score=-6.123 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYfzMo5F5HcY for ; Mon, 8 Oct 2012 23:23:35 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A977121F84CE for ; Mon, 8 Oct 2012 23:23:34 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-5a-5073c2e37314 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 62.A5.17130.3E2C3705; Tue, 9 Oct 2012 08:23:31 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 9 Oct 2012 08:23:31 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" Date: Tue, 9 Oct 2012 08:23:29 +0200 Thread-Topic: [rtcweb] JSEP: Relaxing SDP O/A rules? Thread-Index: AQHNpad1aenXLuIV20+kkVz1nsB6XpewgaKQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAD0858@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <506D4F7A.5020109@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> <506F1526.4050306@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2FE4@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvre7jQ8UBBpdnyFl0TGazONbXxWYx 48JUZou1/9rZHVg8rky4wuox5fdGVo8lS34yedyaUhDAEsVlk5Kak1mWWqRvl8CV0XZ+EWNB j1zFgn9rmBsYOyS6GDk4JARMJDZetexi5AQyxSQu3FvP1sXIxSEkcIpR4vfWu6wQzgJGie7m JkaQBjYBC4nuf9ogDSIChhJNe+YxgdjMAmUS0y80soDYLAIqEpcezmEFsYUFjCU6Px9jgqg3 kVizYw0LhG0kcfLBa0YQm1cgXGLly69MELues0pM6/4O1sAp4Ctx7sJjdhCbEei676fWQC0T l7j1ZD4TxNUCEkv2nGeGsEUlXj7+xwpRLypxp309I0S9jsSC3Z/YIGxtiWULXzNDLBaUODnz CcsERrFZSMbOQtIyC0nLLCQtCxhZVjEK5yZm5qSXm+ulFmUmFxfn5+kVp25iBMbXwS2/DXYw brovdohRmoNFSZxXT3W/v5BAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGZSyKOfdd3slPCzQ+ EpNvuiVG9bSBcnnsrtKrRm2cEybHxySoqW2N3rZJ/l1AidWMNQ0vw+blb9lxyvtySk3DgxNd OgsuMxvEHZgwi4tpYthDPp+7T03NEnkNj9f++jt5Fr/fqUlbuUSs6mTP7XUpMxazk5ov+9ho hersL7NL5uVmqU2vUTFWYinOSDTUYi4qTgQA9PCsPX0CAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Oct 2012 06:23:36 -0000 Hi, > Uh, sort of - if you send an offer that says you could get early media, = you may get early media from two places even thought you have not received = any answer.=20 Sure, but that's separate from the O/A state machine, which is still per di= alog. Regards, Christer On Oct 5, 2012, at 14:26 , Christer Holmberg wrote: > Hi, >=20 > Roman is correct. >=20 > The SDP O/A doesn't consider forking, because each forked SIP leg creates= a unique early dialog, and each early dialog has its own O/A state machine= . >=20 > Regards, >=20 > Christer >=20 >=20 > ________________________________ > From: Roman Shpount [roman@telurix.com] > Sent: Friday, October 05, 2012 8:46 PM > To: Harald Alvestrand > Cc: Christer Holmberg; rtcweb@ietf.org > Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? >=20 >=20 > On Fri, Oct 5, 2012 at 1:13 PM, Harald Alvestrand > wrote: > I've asked that question before, but I don't remember seeing an answer fr= om people who know what they're talking about: >=20 > Does serial forking, as practiced by SIP UAs, violate the SDP O/A model, = or does it not violate the SDP O/A model? >=20 > I don't understand how it, in the form that has been described as "what w= e have to support", can be SDP O/A compatible, but then there are many thin= gs about SIP that I don't understand, so I may understand it when it's expl= ained to me. >=20 >=20 > O/A does not describe multiple answers to a single offer. Nothing=20 > explicitly prohibits it there but I would argue this is not part of this = specification. No standard document that I am aware of describes how serial= O/A is supposed to work. Serial forking as practiced by SIP UA does violat= e SIP RFC 3261 which states that each dialog can only have one answer to ea= ch offer. If answer is sent in both provisional and final response, it shou= ld be the same. You can, however, create multiple dialogs with the same off= er. This normally implies parallel forking, but the most common use case is= with early media, where you end up with multiple early dialogs. For instan= ce you call a phone number, phone network sends you SDP in early media and = plays a dial tone, then the called number does not answer, and you get conn= ected to a voice mail which uses a completely different SDP in final answer= . According to SIP these answers should come with different to-tags and tec= hnically would be parts of two different dialogs. What makes this a bit tr= icky is when the phone network and the voice mail are behind SBC (or some o= ther sort of B2BUA) you only see one dialog which send you multiple answers= to the same offer. This scenario is so common that it is more likely to be= implemented then parallel forking. This is why PRANSWER was suggested. >=20 > If cloning can be implemented in WebRTC it would be more standard complia= nt then PRANSWER and would allow for a lot more use cases. Typical difficul= ty in parallel forking implementation in SIP is due to RTP from multiple so= urces coming to the same IP and port with no consent or notification to the= receiving side. This makes it very difficult to present this media to the = user. There is no way to tie media to actual dialogs since RTP can come fro= m different IP and ports then specified in answer SDPs. This is not an issu= e with WebRTC where consent to receive media is required. I would argue let= 's implement cloning and not waste any more time on PRANSWER which in my op= inion will always stay a half working hack. > _____________ > Roman Shpount >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Mon Oct 8 23:26:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63CA221F884A for ; Mon, 8 Oct 2012 23:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.124 X-Spam-Level: X-Spam-Status: No, score=-6.124 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIFXzL68X5ok for ; Mon, 8 Oct 2012 23:26:40 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6D28C21F852E for ; Mon, 8 Oct 2012 23:26:40 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-4e-5073c39f28ec Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C6.DA.11467.F93C3705; Tue, 9 Oct 2012 08:26:39 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Tue, 9 Oct 2012 08:26:38 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" Date: Tue, 9 Oct 2012 08:26:37 +0200 Thread-Topic: [rtcweb] JSEP: Relaxing SDP O/A rules? Thread-Index: AQHNpad+aenXLuIV20+kkVz1nsB6XpewgfNA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAD0861@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <506D4F7A.5020109@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BD0C5@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FE5@ESESSCMS0356.eemea.ericsson.se>, <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA5E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvre78w8UBBqt/81t0TGazuHbmH6PF 2n/t7A7MHlN+b2T12DnrLrvHkiU/mQKYo7hsUlJzMstSi/TtErgyenZfYCuYzFlxYeNu5gbG mexdjJwcEgImEleXrWKGsMUkLtxbz9bFyMUhJHCKUWLTnz5GCGcBo8Tjp8dYuxg5ONgELCS6 /2mDNIgIGEo07ZnHBGIzC4RIPDz7DmwQi4CKxL6ve1lAbGEBY4nOz8eYIOpNJNbsWMMCYRtJ zGq/yQpi8wqES9yefZYFYtc7domHk56AXccp4Cvx7MpVsKGMQNd9P7UGapm4xK0n85kgrhaQ WLLnPNQHohIvH/9jhagXlbjTvp4Rol5HYsHuT2wQtrbEsoWvmSEWC0qcnPmEZQKj2CwkY2ch aZmFpGUWkpYFjCyrGIVzEzNz0ssN9VKLMpOLi/Pz9IpTNzEC4+nglt+6OxhPnRM5xCjNwaIk zsuVtN9fSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6PBAQXjb+GrOSS0vGMEM1p25fAK9h2I +cjq+fFU113H83/3mYVf7Xy29FsRb+6CuS1a5s97Gq9WsXDLOM6f/blJVLnr2qWPr/ckikTb Lp5UJiL7defC67+1zvJknMzkCsmYdZFV8O+deZOKzOw/RWx6si6ZNWIVS7Y1v4Z5vDkjS/fk 89u1Q5RYijMSDbWYi4oTAYpWCPp1AgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Oct 2012 06:26:41 -0000 Hi, >>>>>> Can I use the same local descriptor for every setLocal() call? >>>>>=20 >>>>> My experience suggests that you can. However, that's not=20 >>>>> stipulated in the API specification, so it's not an ironclad guarante= e. >>>>=20 >>>> If it doesn't, and a new local descripor is created, you would need=20 >>>> to send that one to the remote endpoint. >>>=20 >>> You don't create a new description, you just set one. >>=20 >> Correct. > >> The only problem arises when you can't set the local description=20 >> because something broke since you last set it. (Maybe setting the=20 >> answer caused the browser to release something that you need to set=20 >> the > > If you send an answer that has not relation to the offer, you are equally= hosed. We are keeping the pairing of the offers and answers in the JS stat= e so there are ways that the JS can mess things up if it is buggy but that = not really a PRANSWER problem -=20 > it's just as much a issue with offers and answers.=20 I am not sure what you mean by "an answer that has not relation to the offe= r". Answers are always related to the Offers. Regards, Christer From christer.holmberg@ericsson.com Mon Oct 8 23:28:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4626B21F84F9 for ; Mon, 8 Oct 2012 23:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.126 X-Spam-Level: X-Spam-Status: No, score=-6.126 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6xTQ+rrL1jB for ; Mon, 8 Oct 2012 23:28:42 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 11C5721F849A for ; Mon, 8 Oct 2012 23:28:41 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-ca-5073c418dbf0 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 90.1B.11467.814C3705; Tue, 9 Oct 2012 08:28:41 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Tue, 9 Oct 2012 08:28:40 +0200 From: Christer Holmberg To: Eric Rescorla , "Cullen Jennings (fluffy)" Date: Tue, 9 Oct 2012 08:28:39 +0200 Thread-Topic: [rtcweb] Agenda requests for Atlanta meeting Thread-Index: Ac2lqN/V0WBQ/IXCSdqzySCpE8ZrOgAPjxBA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAD0867@ESESSCMS0356.eemea.ericsson.se> References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvra7kkeIAg7t1Fiten2O36JjMZrH2 Xzu7A7PHlN8bWT2WLPnJ5DH5cRtzAHMUl01Kak5mWWqRvl0CV8bvNX/ZC6awVXzZsYu5gfEt SxcjJ4eEgInEoemfmSFsMYkL99azdTFycQgJnGKU+PBqLQuEM4dRoq1nF2sXIwcHm4CFRPc/ bZAGEYFAiakTJoMNYhZQl7iz+Bw7iM0ioCLx8d1sMFtYwFJi0eb9bBD1VhJrbl1nhrCNJKZO eQoW5xUIl7iw8TgTxK5jTBKXP08E28UJtODFPCaQGkag476fWsMEsUtc4taT+UwQRwtILNlz HuoBUYmXj/+xQtSLStxpX88IUa8jsWD3JzYIW1ti2cLXzBB7BSVOznzCMoFRbBaSsbOQtMxC 0jILScsCRpZVjMK5iZk56eWGeqlFmcnFxfl5esWpmxiBsXRwy2/dHYynzokcYpTmYFES5+VK 2u8vJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVFm9fqZ+e2O7ecy+MJim7Z4CD+ynOTY3829 r4jvxYE7i/sfKxk7zdPdJ2v5Mf1M9Z8fEziPSUv+/mPecOfvkflv5l7Y7mSs8MAhKIXJ5GNB I4vyc8m/IaKbVga37om+YF/Syvv+sSPDLet7HVMN5ufe096leypI43a+7JkLf58rHmQXKxOV /qPEUpyRaKjFXFScCAB7bGzAcwIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Oct 2012 06:28:43 -0000 Hi Ekr, >I would attend such a phone call if it were held. > >My immediate reaction is that from an implementor's perspective. PRANSWER = is a lot easier to address than cloning. I feel like cloning pulls in a lot= of difficult lifetime and ownership semantics. By contrast, supporting PRA= NSWER is very easy. Before >deciding that cloning is the answer I'd like to= see two >things: > >1. A clear set of use cases that shows what cloning does well that PRANSWE= R does not. >2. A fairly complete defn of the clone semantics. > >Otherwise I worry that we'll detour to cloning and then only after 6 month= s discover it doesn't work. Please note that JSEP-02 already supports cloning (the details on how it's = done are missing, though). Regards, Christer From christer.holmberg@ericsson.com Mon Oct 8 23:41:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42FE221F873E for ; Mon, 8 Oct 2012 23:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.127 X-Spam-Level: X-Spam-Status: No, score=-6.127 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIwc3+pJZJ3c for ; Mon, 8 Oct 2012 23:41:03 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E626F21F8737 for ; Mon, 8 Oct 2012 23:41:02 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-c0-5073c6fdcbd6 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 7C.8C.11467.DF6C3705; Tue, 9 Oct 2012 08:41:01 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 9 Oct 2012 08:41:01 +0200 From: Christer Holmberg To: Roman Shpount , Cullen Jennings Date: Tue, 9 Oct 2012 08:40:59 +0200 Thread-Topic: [rtcweb] PRANSWER is unusable for serial forking Thread-Index: Ac2lyEt4PP2ZmsRWR5SrEKyXeCpPxwAH1vuQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAD087C@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvre7fY8UBBrNW2lh8WP+D0WLGhanM Fmv/tbM7MHssWfKTyePy+Y+MHremFAQwR3HZpKTmZJalFunbJXBltEz/x1pwUabi0eFZjA2M i8S6GDk5JARMJJqO3WOBsMUkLtxbz9bFyMUhJHCKUeLphH9MEM4CRolrJxcCVXFwsAlYSHT/ 0wZpEBFwk3g74w0riM0soC5xZ/E5dhCbRUBF4tH/w4wgtrCArUTj2xlMEPV2EhM+7GOHsI0k Tnw6BRbnFQiXmPrnBVi9kECAxOWtX8FmcgoEStz6cBQszgh03PdTa5ggdolL3HoynwniaAGJ JXvOM0PYohIvH/9jhagXlbjTvp4Rol5P4sbUKWwQtrbEsoWvmSH2CkqcnPmEZQKj2CwkY2ch aZmFpGUWkpYFjCyrGIVzEzNz0ssN9VKLMpOLi/Pz9IpTNzECo+nglt+6OxhPnRM5xCjNwaIk zsuVtN9fSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2PNwazTco1ZlpOOyXtzsiuUvr/saFzF NzeDTf3aGoG4npg55aFlsk0l2z5efuPTbyD91+6G00VPndj1Fp37dqU/DrioeuL/DZbDEdy7 c1de8Vu/Omftnom3V/37ddt+/teMlnKhG2vO5Mbf9jfo8tySpLlx68UTEY/FJA7off1VWVZk Mn+F0H8lluKMREMt5qLiRAB6H4A3dAIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] PRANSWER is unusable for serial forking X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Oct 2012 06:41:04 -0000 Hi, I THINK Roman is talking about the following flow: BROWSER JS APP FORKING PROXY SIP UA 1 SIP UA 2 ------- OFFER ---------------> ----- INVITE (OFFER 1) --= -------> ----- INVITE (OFFER 1) ---------> ----- INVITE (OFFER 1) ---------------------------------------------= -------> <----180 (ANSWER 1a) ---------- <----180 (ANSWER 1a) ---------- <----PRANSWER ----------- <----UPDATE (OFFER 2) -------- <----UPDATE (OFFER 2) --------- <----???? -------------------- <----200 (ANSWER 1b) -----------------------------------------------= ------- <----200 (ANSWER 1b) ---------- <----ANSWER --------------- What is "????"? Note that this is NOT about parallel forking, and which media is played to = the user - the JS APP can make that decision based on whatever policy. The = question is how the UPDATE is mapped to the JSEP API. Regards, Christer From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Roman Shpount Sent: 9. lokakuuta 2012 5:46 To: Cullen Jennings Cc: rtcweb@ietf.org Subject: [rtcweb] PRANSWER is unusable for serial forking Changing subject On Mon, Oct 8, 2012 at 10:30 PM, Cullen Jennings wrote: > =A0The only issue is the there is currently no way to map an UPDATE recei= ved in the early dialog to WebRTC API calls. I am probably OK with it not b= eing handled until the cloning is implemented, but this shows that PRANSWER= is not very useful even for the serial forking. > How do you think this work in a SIP only system? Lets say A sends the invit= e with offer to proxy that forks to B. Then B does 180Rel followed by an up= date. Then the proxy forks to C on a new dialog. Do you think C can send se= nd early media to A and A is actually going to play it? And what if B use s= till sending media - it that case A will be getting media from B and C at t= he same time. Do you have devices that do that? =A0Most people just seem to= make voicemail work fine without needing to introduce this type of complex= ity. If you know what you want A to do in this case, I think we can figure = out how to make that happen - there's been a lot of discussion about what a= SIP device receiving early media from two places should do and there was n= ever any really great answer other than don't do that. The meta issue here is thought this is serial forking at the signalling lev= el in SIP, it is actually parallel forking from a SDP / media =A0point of v= iew. The case that started this all was use UPDATE in awaited RFC says is not al= lowed. I'm not arguing there are not cases where clone would be useful, but= I do think all the voicemail systems I am familiar with would work fine wi= th the the simple PRANSWER. This actually works fairly well in the current systems. The fact that UPDAT= E is used does not mean there are multiple media streams flowing at any giv= en time. And, I am familiar with a couple of systems that do exactly what I= have described. Typically some sort of announcement or color-ring-back sys= tem followed by a voice mail. I think the problem is that this group picked= one interop scenario and added something to support it while arbitrarily d= eciding that other scenarios should not be supported. SIP does not have ser= ial forking. Offer/Answer does not describe something like this. We either = need to define it and make it something that describes some set of existing= scenarios or add support for something that is defined. _____________ Roman Shpount =A0 From christer.holmberg@ericsson.com Mon Oct 8 23:41:21 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAF621F87C7 for ; Mon, 8 Oct 2012 23:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.129 X-Spam-Level: X-Spam-Status: No, score=-6.129 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGUMmnoh77Ty for ; Mon, 8 Oct 2012 23:41:20 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 11EF821F8737 for ; Mon, 8 Oct 2012 23:41:19 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-fb-5073c70e071a Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A6.9C.11467.E07C3705; Tue, 9 Oct 2012 08:41:19 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Tue, 9 Oct 2012 08:41:19 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" Date: Tue, 9 Oct 2012 08:41:17 +0200 Thread-Topic: [rtcweb] Agenda requests for Atlanta meeting Thread-Index: AQHNpaenkG2ADNG+3EO5+NGGgdEEepewfwQw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAD087E@ESESSCMS0356.eemea.ericsson.se> References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+JvrS7/8eIAg5OzeC06JrNZrP3Xzu7A 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZdzedZGp4DBPxfZmmwbGV5xdjJwcEgImEn8b 1jJC2GISF+6tZ+ti5OIQEjjFKHG6s50JwlnAKPFjymvmLkYODjYBC4nuf9ogDSIChhJNe+Yx gdjMAuoSdxafYwexWQRUJKYd3Qs2VFjAUmLR5v1sEPVWEmtuXWeGsI0k1p25ywoyklcgXOJc GzPEqv+MEsde/mEHiXMK+EpcnuEIUs4IdNv3U2ugVolL3HoynwniZgGJJXvOM0PYohIvH/9j hagXlbjTvp4Rol5HYsHuT2wQtrbEsoWvwep5BQQlTs58wjKBUWwWkrGzkLTMQtIyC0nLAkaW VYzCuYmZOenlhnqpRZnJxcX5eXrFqZsYgVFzcMtv3R2Mp86JHGKU5mBREuflStrvLySQnliS mp2aWpBaFF9UmpNafIiRiYNTqoEx5rdKeK3xVtOfqe81rZ4dYZCUY7pXLvJkpkqch1C2bIvU vlORR0Rrl63VZTi+muvO5gMnRNcdCueS+/qmjEFzhd6SZf+uH4xmTG/92ivkKxgS/nD12q8n zk5wffstxfpvWYvcstOHQ4J27N7yvP7Fj4R7E848E5Y75/2pdc3Zp0+NZqvemy/er8RSnJFo qMVcVJwIABmmTlZoAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Oct 2012 06:41:21 -0000 Hi, >> I would like to discuss the different alternatives in order to support f= orking, e.g. whether we use cloning, whether we simply set additional local= descriptor, and whether we can get rid of PRANSWER. > > Seriously? we have discussed this so many times and always come to the sa= me conclusion. I have not seen anything on the list that suggests why we ne= ed to remove this or how mapping to SIP 180 with sequential forking is goin= g to work without it. You CAN do serial forking also with cloning (or, as suggested by Martin, si= mply setting additional local descriptors). I am not blindly suggesting to remove PRANSWER (I have been one of the defe= nders for having it). It's part of the more general "JSEP Offer/Answer Usag= e" issue, which we DO need to make sure we get right. > It also has other important uses. There are a bunch of changes that are n= eeded to the JSEP draft to remove some of the inconsistencies in this and c= larify some parts but I'd rather wait till we had that updated before we go= t into a whole discussion about=20 > exploding it yet again.=20 I have no problem with that. But, again, we do need to get the JSEP O/A sor= ted out. My suggesting is still that the base should be RFC 3264, and if we= need to "relax" things we should very carefully look at those cases. > Why don't we have a phone call to try and outline what the problems you a= re trying to solve that the current solution does not work for then figure = out how much we want to explode this.=20 Sure. I'd attend such call. Regards, Christer From paalh@ifi.uio.no Tue Oct 9 01:30:32 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B50921F8839; Tue, 9 Oct 2012 01:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoYfaV6KmdCx; Tue, 9 Oct 2012 01:30:32 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id A66A621F883E; Tue, 9 Oct 2012 01:30:31 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TLVCu-0003wj-Jk; Tue, 09 Oct 2012 10:30:28 +0200 Received: from [77.88.71.190] (helo=mbpal.simula.no) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user paalh (Exim 4.80) (envelope-from ) id 1TLVCu-0000ke-1d; Tue, 09 Oct 2012 10:30:28 +0200 From: =?iso-8859-1?Q?P=E5l_Halvorsen?= Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Oct 2012 10:30:26 +0200 Message-Id: <2D7DEBDF-11E1-4794-96E8-3FEAF500A5CD@ifi.uio.no> To: bloat@lists.bufferbloat.net, iccrg@cs.ucl.ac.uk, rmcat@ietf.org, rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 50 msgs/h 18 sum rcpts/h 51 sum msgs/h 19 total rcpts 24832 max rcpts/h 4849 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A72A9F7ADC04AC3EE44E54370BD8B8FA8699EEE0 X-UiO-SPAM-Test: remote_host: 77.88.71.190 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 18 total 24 max/h 18 blacklist 0 greylist 0 ratelimit 0 Subject: [rtcweb] PhD position available in the area of in Time-Dependent Networking X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Oct 2012 08:30:33 -0000 AVAILABLE PHD POSITION At Simula Research Laboratory (Norway) there is an available PhD = position in the area of in Time-Dependent Networking. The PhD Student = will work in the area of networking support for time-dependent = applications, focusing on thin streams. Thin streams are generated by = applications that send data with high interarrival time and also often = small packet sizes. These traffic patterns are in stark contrast to = greedy streams where the application always has data to send and the = sending rate is limited by congestion control. Typical for thin streams = is that they are generated by interactive applications with a need for = low latency communication. The following topics are central for the work in this position: =95 Develop mechanisms to improve thin-stream latency when transmitted = via different buffer types with varying drop schemes. =95 Investigate the congestion control support of conditionally thin = streams (i.e. not everything must be sent at all times) via per-packet = priorities. =95 Work towards a formal definition of the concept of thin streams. =95 Work towards defining what TCP fairness must mean in thin-stream = scenarios. The position is connected to the "Traffic behaviour of interactive = time-dependent thin streams on the modern Internet" (TimeIn) research = project cooperating with partners like UNINETT, University of Oslo, = Karlstad University, University of Kaiserslautern, CAIDA San Diego, = Cisco and Funcom. It is planned to align the research with, and possibly contribute to, = ongoing standardization efforts in the RTP Media Congestion Avoidance = Techniques (RMCAT) working group in the IETF. For more information about the project, the requirements, Simula, = salary, etc.,=20 please see http://simula.no/jobs/PhDStudent-TimeIn or contact: Postdoc Andreas Petlund, e-mail: apetlund@simula.no or Professor P=E5l Halvorsen, e-mail: paalh@simula.no (where you include the following phrase in the subject field: =93TimeIn = PhD position=94) The application deadline is as soon as possible, but no later than 20 = October 2012. To apply for this position, click here:=20 = https://emea3.recruitmentplatform.com/appproc/index.cfm?event=3DcreateSess= ionAfterSessionClear&ID=3DQL5FK026203F3VBQBV779QWAD&jobboard=3D0&nPTID=3D2= 8&bSessionClear=3Dtrue= From ibc@aliax.net Tue Oct 9 02:25:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8950E21F8843 for ; Tue, 9 Oct 2012 02:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOOMsWH9QR7m for ; Tue, 9 Oct 2012 02:25:06 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D713D21F84B5 for ; Tue, 9 Oct 2012 02:24:59 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so3947080lbo.31 for ; Tue, 09 Oct 2012 02:24:58 -0700 (PDT) X-Google-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:content-transfer-encoding:x-gm-message-state; bh=rOzxGZhWU+6iyoeGTKrYpgVvwlz5buZnVFzyUkR2ZN8=; b=PAceI0No916oqCu4ZVdfIX3Fv5XlRzyqa/iCgGOiNNxnJ5utfuOluC7BOaW1SDnz/u uBeg1XXmDtds51EhuY0ZV460CsfgwUyXA8xRnsJIXAlJR4W75Et8NAl9aPuur3eOZAUo Vq7xDRU4SeYS+t+wKc5XYr5NA9Ndrt5PmJNC5FK1Tj6rVVjtbBJELY/nSpmocb72jHHV w9XZGLvGW96o0TxfKarANaDvUBXCggB6ol5c1Xw5blib6ebcvDjbgx4Y+j2IOUPxaS9j Xjvwdx1GDBFVlWpNMQNtpFOnG/Oo4WzToWSV4mvEQnR2T5A0RxbCkXWVwlxS7hTcx7Ko lP6A== Received: by 10.112.38.39 with SMTP id d7mr7771529lbk.112.1349774698730; Tue, 09 Oct 2012 02:24:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.3.7 with HTTP; Tue, 9 Oct 2012 02:24:38 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 9 Oct 2012 11:24:38 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnC3mZMBccksXDLcjccKdO8vrIcPqqF6x8cUCpMjg0Ttig6AlmtU2c5+9yWZKAVsEi9QQth Cc: rtcweb@ietf.org Subject: Re: [rtcweb] PRANSWER is unusable for serial forking X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Oct 2012 09:25:06 -0000 2012/10/9 Roman Shpount : > SIP does not have serial forking. SIp has serial forking but just at signaling level, not at media level :) > Offer/Answer does not describe something > like this. +1 > We either need to define it and make it something that describes > some set of existing scenarios or add support for something that is defin= ed. IMHO the solution is described in other mail thread (maybe in rtcweb WG): implement cloning. Example: - My JS SIP app sends an INVITE with SDP and receives a 183 response with To-tag "AAAA" and SDP A, so I already have a media stream. - Later the voicemail system answers the call so replies a 200 with To-tag "BBBB" and SDP B. Since To-tag is different I do know (as per RFC 3261/3264) that I should create another media "session" sharing my local SDP (but cloning it). And I also want to close the previous one. Of course, for this we need some API method like "cloneLocalDescription(new_remote_sdp_object)" or whatever. AFAIR this has been recently discussed in rtcweb WG. --=20 I=C3=B1aki Baz Castillo From fluffy@cisco.com Tue Oct 9 07:11:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE921F0C8E for ; Tue, 9 Oct 2012 07:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.528 X-Spam-Level: X-Spam-Status: No, score=-110.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyheYyx5heyQ for ; Tue, 9 Oct 2012 07:11:32 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C51FF1F0C70 for ; Tue, 9 Oct 2012 07:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1724; q=dns/txt; s=iport; t=1349791893; x=1351001493; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dqm0/nZlOEN11ZkNZeNnxupKYUBdi2aLhxV31zdiCq0=; b=JiVlSaPTT1vD1y4mOiu4l2e9q31cu733pfNdK9kjiVS3wiWhuPdrvuH0 ho22FCuOoSt+Yipc1I5TN3qq7NUIDj2154AfzYNDS0MH00fV74dkYXqGB fTrGpo/1ecT4v/oLUNeIOeWI37bX4SGBkicJS6KJGp0ITl+ojWFMvcXYU 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANUvdFCtJXG8/2dsb2JhbABFvy6BCIIgAQEBAwESASc4BwULAgEIIhQQMiUCBA4FCBqHXQabRo9WkD2LOYUzYAOkL4Frgm2CFw X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="129779927" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 09 Oct 2012 14:11:29 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q99EBTbo029091 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 14:11:29 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 09:11:28 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [rtcweb] JSEP: Relaxing SDP O/A rules? Thread-Index: AQHNpad+aenXLuIV20+kkVz1nsB6XpewgfNAgADWtgA= Date: Tue, 9 Oct 2012 14:11:28 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <506D4F7A.5020109@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BD0C5@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FE5@ESESSCMS0356.eemea.ericsson.se>, <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA5E@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAD0861@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAD0861@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.121.138] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19254.003 x-tm-as-result: No--36.264700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <074C0077C442194A9270307C626A207D@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Oct 2012 14:11:33 -0000 On Oct 8, 2012, at 23:26 , Christer Holmberg wrote: > Hi, >=20 >>>>>>> Can I use the same local descriptor for every setLocal() call? >>>>>>=20 >>>>>> My experience suggests that you can. However, that's not=20 >>>>>> stipulated in the API specification, so it's not an ironclad guarant= ee. >>>>>=20 >>>>> If it doesn't, and a new local descripor is created, you would need=20 >>>>> to send that one to the remote endpoint. >>>>=20 >>>> You don't create a new description, you just set one. >>>=20 >>> Correct. >>=20 >>> The only problem arises when you can't set the local description=20 >>> because something broke since you last set it. (Maybe setting the=20 >>> answer caused the browser to release something that you need to set=20 >>> the >>=20 >> If you send an answer that has not relation to the offer, you are equall= y hosed. We are keeping the pairing of the offers and answers in the JS sta= te so there are ways that the JS can mess things up if it is buggy but that= not really a PRANSWER problem -=20 >> it's just as much a issue with offers and answers.=20 >=20 > I am not sure what you mean by "an answer that has not relation to the of= fer". Answers are always related to the Offers. Sorry - that was poorly written. Lets say you had two PeerConnection call t= hem A and B and they both create an offer and far sides sends answers to bo= th offers. Now if you take the answer from offer B and use it as the answer= for A, all bets are off and bad things will happen. That is what I meant b= y if you use an answer that had no relation to offer it needed to be associ= ated with.=20 >=20 > Regards, >=20 > Christer From fluffy@cisco.com Tue Oct 9 07:16:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC1F11E8097 for ; Tue, 9 Oct 2012 07:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.532 X-Spam-Level: X-Spam-Status: No, score=-110.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gv5PpbZQoWBX for ; Tue, 9 Oct 2012 07:16:55 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id BA3D011E810C for ; Tue, 9 Oct 2012 07:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2064; q=dns/txt; s=iport; t=1349792215; x=1351001815; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=c/Y1vw2NnkEUWBwAlCO354fFebett7WZ8yiYY+LdG4I=; b=Lwsds2iY6tNoFZgYo7M+aekCXrKhYUW/YAd3HJyvZzw615KbRZEH2Gl+ O7pidftaAUb1cJTyPsBJP3PyztNqsGX7Ktr7invqnfa4pAet/ayAE64Ar /pCTcNusl8wI0rrtSOWL9txuI5L7NuHu8CeOCd8ZVe8drnUKS7tz467gK g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGYwdFCtJXHA/2dsb2JhbABFvy6BCIIgAQEBAwESASc/BQsCAQgiFBAyJQIEDgUIEweHXQabSo9WkD2LOYUzYAOSOZF2gWuCbYIX X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="129724056" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 09 Oct 2012 14:16:50 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q99EGo9I029478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 14:16:50 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 09:16:50 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [rtcweb] Agenda requests for Atlanta meeting Thread-Index: AQHNpaenkG2ADNG+3EO5+NGGgdEEepewfwQwgADbJIA= Date: Tue, 9 Oct 2012 14:16:49 +0000 Message-ID: References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAD087E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAD087E@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.121.138] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19254.003 x-tm-as-result: No--32.966700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <82BBAC22BF1B734DBE1F8A50F1A6D103@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Oct 2012 14:16:56 -0000 On Oct 8, 2012, at 23:41 , Christer Holmberg wrote: > Hi, >=20 >>> I would like to discuss the different alternatives in order to support = forking, e.g. whether we use cloning, whether we simply set additional loca= l descriptor, and whether we can get rid of PRANSWER. >>=20 >> Seriously? we have discussed this so many times and always come to the s= ame conclusion. I have not seen anything on the list that suggests why we n= eed to remove this or how mapping to SIP 180 with sequential forking is goi= ng to work without it. >=20 > You CAN do serial forking also with cloning (or, as suggested by Martin, = simply setting additional local descriptors). >=20 > I am not blindly suggesting to remove PRANSWER (I have been one of the de= fenders for having it). It's part of the more general "JSEP Offer/Answer Us= age" issue, which we DO need to make sure we get right. agree - sounds like we are on same page=20 >=20 >> It also has other important uses. There are a bunch of changes that are = needed to the JSEP draft to remove some of the inconsistencies in this and = clarify some parts but I'd rather wait till we had that updated before we g= ot into a whole discussion about=20 >> exploding it yet again.=20 >=20 > I have no problem with that. But, again, we do need to get the JSEP O/A s= orted out. My suggesting is still that the base should be RFC 3264, and if = we need to "relax" things we should very carefully look at those cases. I have not seen any reason to relax 3264 yet but if something comes up, agr= ee we should carefully look at the cases. I think we can just do straight u= p 3264. Arguments that SIP early media in a 180 is not compliant with 3264 = are just wrong. >=20 >> Why don't we have a phone call to try and outline what the problems you = are trying to solve that the current solution does not work for then figure= out how much we want to explode this.=20 >=20 > Sure. I'd attend such call. >=20 > Regards, >=20 > Christer >=20 From martin.thomson@gmail.com Tue Oct 9 09:09:53 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4FF11E8109 for ; Tue, 9 Oct 2012 09:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.918 X-Spam-Level: X-Spam-Status: No, score=-3.918 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjaeVMOSy9ZE for ; Tue, 9 Oct 2012 09:09:52 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B421211E810B for ; Tue, 9 Oct 2012 09:09:39 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so3500664lam.31 for ; Tue, 09 Oct 2012 09:09:38 -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=MYuyQaxHO+7PodtVGjzM5xF+ME4wGJVoEou9vYxbDg4=; b=r87ukVx38E9Wj1gcHDv53RraMPDYJ4uJFqVO2P576JBIkLhvgjoVgOS++Hpl25V2z0 tY6E9ebrZe6K0SxCebMbuPERsCjxeEWMIVGpwUtSX9fFMq1cX9xN56La3fkcmcIPliXX lmPJsYdvodaYAAtoTVueh56KL5rHhN0dzKVOcWYeLyMPiXmdQEjfbrfaeWp5QDz793pL iuMzGsiUBnWHHhQ6dZffv7WPQmqlzfwOYrEpOHFvuUoiLtn0Ik7DPa9YmJHHaoIdIjNR 2hBKbTr3FEYI3AXYV+A07PNCNLg27x+k0xlZtpFzotIR6Tb618x+oHUXwqGxJo3yb9m1 65Ew== MIME-Version: 1.0 Received: by 10.112.100.197 with SMTP id fa5mr8067539lbb.59.1349798978635; Tue, 09 Oct 2012 09:09:38 -0700 (PDT) Received: by 10.112.83.2 with HTTP; Tue, 9 Oct 2012 09:09:38 -0700 (PDT) In-Reply-To: References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAD087E@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 9 Oct 2012 09:09:38 -0700 Message-ID: From: Martin Thomson To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Oct 2012 16:09:53 -0000 On 9 October 2012 07:16, Cullen Jennings (fluffy) wrote: > I have not seen any reason to relax 3264 yet but if something comes up, agree we should carefully look at the cases. I think we can just do straight up 3264. RFC 3264 doesn't describe PRANSWER. The concept is entirely absent. The offerer MAY immediately cease listening for media formats that were listed in the initial offer, but not present in the answer. "the" answer. > Arguments that SIP early media in a 180 is not compliant with 3264 are just wrong. I'd be pleased if you could find something concrete that supports this, because I just re-read 3264 and I can't find anything supporting your conclusion. I have no problem with the idea of a well-established status quo that does not conform to the documents. That would be consistent with many other RFCs. However, if that is the case, perhaps someone could write this behavior down so that we can use the same definitions. Clearly, that isn't happening right now. From richard@shockey.us Tue Oct 9 09:19:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9D021F8787 for ; Tue, 9 Oct 2012 09:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.659 X-Spam-Level: X-Spam-Status: No, score=-99.659 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gisNJYacnDxN for ; Tue, 9 Oct 2012 09:19:03 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 64C9921F853A for ; Tue, 9 Oct 2012 09:19:03 -0700 (PDT) Received: (qmail 16715 invoked by uid 0); 9 Oct 2012 16:19:01 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy8.bluehost.com with SMTP; 9 Oct 2012 16:19:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=W+Jk8B7ppna7Ef0rROIPlJt/OnJqZZcr0OJ4RqdrFJY=; b=HocV8EHujvnbjFFq1bjfVUF/8+XrRJ/HxuVSc1g4k9MVqxjEJoQ7rHRXnVhY5t5lca5zOr8KwpB6wtTGI8zl2kzI7TsKaQ2hUKxCZF0SA3V/115N9++B3vO9n65mKNuA; Received: from [71.191.243.130] (port=55566 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TLcWJ-0001nF-Ed; Tue, 09 Oct 2012 10:18:59 -0600 From: "Richard Shockey" To: "'Cullen Jennings'" , "'Roman Shpount'" References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <723C9B03-B45B-4214-9A36-7B4CEBD2FC2E@iii.ca> <17E29D7C-A9D9-4AF9-9514-F44DB54CDEAA@cisco.com> In-Reply-To: Date: Tue, 9 Oct 2012 12:18:55 -0400 Message-ID: <004b01cda639$c96fdab0$5c4f9010$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2lt58SO555OI6NQESDkOHhbI7O7AAgftyg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Oct 2012 16:19:04 -0000 +1 to that idea. Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum skype-linkedin-facebook: rshockey101 http//www.sipforum.org -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Monday, October 08, 2012 8:48 PM To: Roman Shpount Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Agenda requests for Atlanta meeting One other thought on this. I think this just points out that it would be really nice to have a draft that showed how to build a RTCWeb / SIP gateway. On Oct 8, 2012, at 17:42 , Cullen Jennings wrote: > > Check out text from RFC 3311 that says > > o If the UPDATE is being sent before the completion of the INVITE > transaction, and the initial INVITE contained an offer, the > UPDATE cannot be sent with an offer unless the callee has > generated an answer in a reliable provisional response, has > received a PRACK for that reliable provisional response, has > not received any requests (PRACK or UPDATE) with offers that it > has not answered, and has not sent any UPDATE requests > containing offers that have not been answered. > > So the 183 would be need to be sent reliably at which case I would expect the gateways to map it to a final offer in RTCWeb not a provisional one. At that point when the update comes along with an offer, it just mapped to RTCweb offer. > > > On Oct 8, 2012, at 16:21 , Roman Shpount > wrote: > >> The scenario is: >> >> WebRTC is placing a call through some sort of gateway to a SIP end point. It sends an offer that gets translated into INVITE with SDP. SIP end point sends back 183 with SDP that gets delivered to the WebRTC end point as PRANSWER. Then SIP end point sends an UPDATE with SDP in early dialog. And then finally SIP end point sends 200 OK with different SDP. I am not sure how to translate the SDP in UPDATE and the final answer in WebRTC API calls. I would guess this is not something that can be supported without cloning. >> _____________ >> Roman Shpount >> >> >> On Mon, Oct 8, 2012 at 7:09 PM, Cullen Jennings wrote: >> >> Walk me through what the call flow would like it both endpoints were SIP UA's so I understand it better. >> >> >> Note - I'm not against folks trying to figure out clone. I'm saying that we should not get rid of PRANSWER. >> >> >> On Oct 8, 2012, at 15:58 , Roman Shpount wrote: >> >>> Cullen, >>> >>> I have an existing interop problem with SIP serial forking that I cannot solve with the proposed schema. With PRANSWER, how would I handle SIP UPDATE sith SDP received in early dialog? >>> >>> Regards, >>> _____________ >>> Roman Shpount >>> >>> >>> On Mon, Oct 8, 2012 at 6:53 PM, Cullen Jennings (fluffy) wrote: >>> >>> On Oct 8, 2012, at 2:47 , Christer Holmberg wrote: >>> >>>> Hi, >>>> >>>> I would like to discuss the different alternatives in order to support forking, e.g. whether we use cloning, whether we simply set additional local descriptor, and whether we can get rid of PRANSWER. >>> >>> Seriously? we have discussed this so many times and always come to the same conclusion. I have not seen anything on the list that suggests why we need to remove this or how mapping to SIP 180 with sequential forking is going to work without it. It also has other important uses. There are a bunch of changes that are needed to the JSEP draft to remove some of the inconsistencies in this and clarify some parts but I'd rather wait till we had that updated before we got into a whole discussion about exploding it yet again. >>> >>> Why don't we have a phone call to try and outline what the problems you are trying to solve that the current solution does not work for then figure out how much we want to explode this. >>> >>> I'll note that current clone text has lots of "miracles happen here, insert supper fluffy hand wave" in it and plenty of weasel room on failure to allocate required resources on the clone. It's more or less a sketch of an idea at this point. I'm perfectly happy to see people try and sort out the details on clone but using it explode the consensus we have come to around PRANSWER seems like a really bad idea at this point. >>> >>> 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 christer.holmberg@ericsson.com Tue Oct 9 12:04:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1D411E8156 for ; Tue, 9 Oct 2012 12:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.83 X-Spam-Level: X-Spam-Status: No, score=-5.83 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LimsbZeYIa-h for ; Tue, 9 Oct 2012 12:04:14 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B6FC911E8153 for ; Tue, 9 Oct 2012 12:04:13 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-7e-5074752c6294 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 01.7F.25676.C2574705; Tue, 9 Oct 2012 21:04:12 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Tue, 9 Oct 2012 21:04:12 +0200 From: Christer Holmberg To: Martin Thomson , "Cullen Jennings (fluffy)" Date: Tue, 9 Oct 2012 21:04:11 +0200 Thread-Topic: [rtcweb] Agenda requests for Atlanta meeting Thread-Index: Ac2mOIZh+PFfSQJ9S52mI6WiFBgRBAAFw7qT Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6B@ESESSCMS0356.eemea.ericsson.se> References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAD087E@ESESSCMS0356.eemea.ericsson.se> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvra5OaUmAwblnihYdk9ksrp35x2ix 9l87uwOzx5TfG1k9ds66y+6xZMlPpgDmKC6blNSczLLUIn27BK6MJa/mshR0sldsn3CXtYHx BGsXIyeHhICJxM3zHxkhbDGJC/fWs3UxcnEICZxilNh4+gMjhDOHUWLls8lADgcHm4CFRPc/ bRBTRCBO4u43V5BeZgF1iTuLz7GD2CwCKhLnt64Amy8sYCmxaPN+NhBbRMBKYs2t68wQtpHE sZk3wOp5BcIljv5+xgyx6iqzxKG+yWBFnAKBEgdvTwErYgQ67vupNUwQy8Qlbj2ZzwRxtIDE kj3nmSFsUYmXj/+xQtSLStxpX88IUa8jsWD3JzYIW1ti2cLXzBCLBSVOznzCMoFRbBaSsbOQ tMxC0jILScsCRpZVjMK5iZk56eVGeqlFmcnFxfl5esWpmxiB0XRwy2/VHYx3zokcYpTmYFES 57XeusdfSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2ObuNPWo8femC55E6j+y+Xgg9oc/gKt TJ/rkbkTJ0wtehHvPH3JkelfNfctCFDQ/Co+lZvFcNaUzzxFOb4LQ16kfHooFvhC25BLzEj6 uiXz/Vmu/LceFH9dumpTvNZdo8LTkslvbs6UYt/iyrfkaVbVDuUisaUsAlJTihuskpg0TeJa LZdPWKnEUpyRaKjFXFScCADzZOqKdAIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Oct 2012 19:04:14 -0000 Hi, >> I have not seen any reason to relax 3264 yet but if something comes up, = agree we should carefully look at the cases. I think we can just do straigh= t up 3264. > >RFC 3264 doesn't describe PRANSWER. The concept is entirely absent. > > The offerer MAY immediately cease listening for media formats that > were listed in the initial offer, but not present in the answer. > > "the" answer. I agree with Martin. 3264 O/A is always per dialog, and forking is supporte= d by generating multiple dialogs. JSEP, OTOH, in order to support forking w= ith a single "dialog" (peerConnection local descriptor), now defines O/A as= offer+any number of pranswers + answer. So, we would e.g. have to define what happens if a new offer is received fr= om the remote side while the browser is in pranswer-received state (see my = call flow in another reply). Regards, Christer= From fluffy@cisco.com Tue Oct 9 13:05:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7560C1F0422 for ; Tue, 9 Oct 2012 13:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.641 X-Spam-Level: X-Spam-Status: No, score=-108.641 tagged_above=-999 required=5 tests=[AWL=-1.831, BAYES_00=-2.599, FB_NO_MORE_OFFER=3.189, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSQY1obdiMHp for ; Tue, 9 Oct 2012 13:05:45 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8A20B1F040A for ; Tue, 9 Oct 2012 13:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3061; q=dns/txt; s=iport; t=1349813145; x=1351022745; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HcrxLONdBmJhiOqqoHyS64hUFh58oYFlpeWpIpFzCgw=; b=ZqQJSFcfMqnlTNr4hNsF69uPle6pVmiILlau0sTBTciKlBHtkKzKZCF6 yqeL3GhpdXGQHymqcj5PEjAGYiAlbMGLel9M+J5XlxTd8WakWi5eFLE/i sAh1ZtGQCDvm7Zk6NnngU8zsCRPJ/SOISDVD7HT3G9hNq/8UIKIELS1t0 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAE2DdFCtJXHA/2dsb2JhbABFvzCBCIIgAQEBAwESASc/BQsCAQgiFBAyJQIEDgUIGoddBpooj1iQRItDhTNgA5I6kXaBa4Jtghc X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="129932230" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 09 Oct 2012 20:05:29 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q99K5TH7026397 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Oct 2012 20:05:29 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 15:05:29 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [rtcweb] Agenda requests for Atlanta meeting Thread-Index: AQHNpaenkG2ADNG+3EO5+NGGgdEEepewfwQwgADbJICAAB9QAIAAMMWAgAARVYA= Date: Tue, 9 Oct 2012 20:05:29 +0000 Message-ID: References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAD087E@ESESSCMS0356.eemea.ericsson.se> , <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6B@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.72.178] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19254.003 x-tm-as-result: No--34.803200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <0946A37679F97140AE831D229960E210@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Oct 2012 20:05:48 -0000 On Oct 9, 2012, at 12:04 , Christer Holmberg wrote: > Hi, >=20 >>> I have not seen any reason to relax 3264 yet but if something comes up,= agree we should carefully look at the cases. I think we can just do straig= ht up 3264. >>=20 >> RFC 3264 doesn't describe PRANSWER. The concept is entirely absent. >>=20 >> The offerer MAY immediately cease listening for media formats that >> were listed in the initial offer, but not present in the answer. >>=20 >> "the" answer. >=20 > I agree with Martin. 3264 O/A is always per dialog, and forking is suppor= ted by generating multiple dialogs. JSEP, OTOH, in order to support forking= with a single "dialog" (peerConnection local descriptor), now defines O/A = as offer+any number of pranswers + answer. >=20 > So, we would e.g. have to define what happens if a new offer is received = from the remote side while the browser is in pranswer-received state (see m= y call flow in another reply). 3264, SDP, 3261, and related documents are dealing with a bunch of things i= ncluding what happens at media plane and signaling plane.=20 I'll note that though O/A is per dialog, there is only one O shared across = multiple legs and when you create the O you don't know how many dialogs the= re will be. So from the media point of view (covered more in SDP spec than = 3264) there is one O with a bunch of A. From signaling point of view there = are a bunch of O/A pairs).=20 The dialog is SIP signaling concept not a media plane level concept. We mov= ed the signaling part out of the browser and into the JS. But the media par= t is still in the browser. So as 3264 says, after the offer is constructed,= we have to be willing to receive media for all the codec type in the offer= . When we get the answer 3264 makes it clear that one MAY stop receiving th= e codecs that were in the offer but not selected in the answer. However, th= is can not be done until the signaling layer is sure that no more offers wi= ll be honored. Since that signalling part of Offer/Answer is in the JS, the= API need to to have a way to signal what the MAY part should do and that i= s the PRANSWER vs ANSWER.=20 People keep trying to make this some complex weird argument invoking the SI= P deities of the past and quoting incomprehensible phrases from various RFC= caved in stone but the bottom line in the code is very simple to understan= d. When creating the offer you alloced some resources ( like a port to rece= ive video on ). When you get an answer that does not use that resource, you= need to tell the media stack if it should free the resources or not. O/A h= as situation where you need to keep the resources available (like there are= more dialogs coming) and situation where you need to free the resource. S= ince we split the signalling out of the browser and left the media in the b= rowser, we need be able to allow the JS that is dealing with signaling to t= ell the browser when to free the resource.=20 From martin.thomson@gmail.com Tue Oct 9 15:58:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFEE21F84A6 for ; Tue, 9 Oct 2012 15:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=-1.899, BAYES_00=-2.599, FB_NO_MORE_OFFER=3.189, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4K1ODutQQSaq for ; Tue, 9 Oct 2012 15:58:49 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3150621F84A0 for ; Tue, 9 Oct 2012 15:58:49 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so4558873lbo.31 for ; Tue, 09 Oct 2012 15:58: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:content-transfer-encoding; bh=3WWC1xIbzn5btODxKpO2bYtuf8KAa0cZzx11P7Mtql0=; b=QKNIh7TnUooh/ut6+FNSFajkvvYXNJjtzw7ph/PXCffFsxT7VUVG0FsVOJGtgOjWLd 1KcjAJ1+NJWltxTmQ7YPibgi4anB8aaALqXL+GI3wZOMqnEtS9c4djvNAfoRZhb/9Wmr eNw2S4gqoOmYBz/gTIYTtZ9qIwXzvq/zTGlGspM9h9Uawf8VZbyho5J/b8Y043MfEEtS WISiwn9+91zMmbtCIpz4N9mQqa40k8bVZexWwzhHBOEOG1WuoRkLIkjI/wta6wokjg04 aTVWE/5y5khlItRFcqR9E/ewCP+FSRH7BlJme1qQQWcOnrgIj/+E1iuIeWhspiDdeLq4 7ymA== MIME-Version: 1.0 Received: by 10.152.148.8 with SMTP id to8mr9983569lab.2.1349823528200; Tue, 09 Oct 2012 15:58:48 -0700 (PDT) Received: by 10.112.83.2 with HTTP; Tue, 9 Oct 2012 15:58:48 -0700 (PDT) In-Reply-To: References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAD087E@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6B@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 9 Oct 2012 15:58:48 -0700 Message-ID: From: Martin Thomson To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Oct 2012 22:58:50 -0000 On 9 October 2012 13:05, Cullen Jennings (fluffy) wrote: > 3264, SDP, 3261, and related documents are dealing with a bunch of things= including what happens at media plane and signaling plane. > > I'll note that though O/A is per dialog, there is only one O shared acros= s multiple legs and when you create the O you don't know how many dialogs t= here will be. So from the media point of view (covered more in SDP spec tha= n 3264) there is one O with a bunch of A. From signaling point of view ther= e are a bunch of O/A pairs). > > The dialog is SIP signaling concept not a media plane level concept. We m= oved the signaling part out of the browser and into the JS. But the media p= art is still in the browser. So as 3264 says, after the offer is constructe= d, we have to be willing to receive media for all the codec type in the off= er. When we get the answer 3264 makes it clear that one MAY stop receiving = the codecs that were in the offer but not selected in the answer. However, = this can not be done until the signaling layer is sure that no more offers = will be honored. Since that signalling part of Offer/Answer is in the JS, t= he API need to to have a way to signal what the MAY part should do and that= is the PRANSWER vs ANSWER. That's a consistent and logical view. It is not what RFC 3264 says. It may even be the only reasonable solution. > People keep trying to make this some complex weird argument invoking the = SIP deities of the past and quoting incomprehensible phrases from various R= FC caved in stone [...] Quit beating around the bush: it's me you are talking about. It's not a complex weird argument, it's this: PRANSWER is not described in RFC 3264. draft-*-jsep might say something about it, but I'd have to guess about what to do if I were to implement the feature and that doesn't help with interoperation. If there was text that described the above, plus the implications in some detail (including what resources can be released as they relate to the SDP), then we're good. I don't even think that writing this is especially hard. As it stands, the definition for cloning is on par with the definition for PRANSWER. From harald@alvestrand.no Tue Oct 9 23:38:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EBC21F846F for ; Tue, 9 Oct 2012 23:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.435 X-Spam-Level: X-Spam-Status: No, score=-110.435 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wg9Ds5L5jvr0 for ; Tue, 9 Oct 2012 23:38:43 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A541D21F846A for ; Tue, 9 Oct 2012 23:38:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9EAA139E3F4 for ; Wed, 10 Oct 2012 08:38:41 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOT0wPqeSBml for ; Wed, 10 Oct 2012 08:38:40 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:fd63:5f6a:b9ff:a8f] (unknown [IPv6:2001:470:de0a:27:fd63:5f6a:b9ff:a8f]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id ACF8339E27D for ; Wed, 10 Oct 2012 08:38:40 +0200 (CEST) Message-ID: <50751859.6090202@alvestrand.no> Date: Wed, 10 Oct 2012 08:40:25 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <50742574.6080200@ericsson.com> In-Reply-To: <50742574.6080200@ericsson.com> X-Forwarded-Message-Id: <50742574.6080200@ericsson.com> Content-Type: multipart/alternative; boundary="------------020204040001050109050709" Subject: [rtcweb] Fwd: WG poll for consensus MSID draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 06:38:44 -0000 This is a multi-part message in MIME format. --------------020204040001050109050709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit If people feel that this should be progressed, now is a good time to say so in MMUSIC. Harald -------- Original Message -------- Subject: WG poll for consensus MSID draft Date: Tue, 9 Oct 2012 15:24:04 +0200 From: Miguel A. Garcia To: mmusic CC: Flemming Andreasen , Harald Alvestrand At the last IETF meeting we had a presentation of the following draft: http://datatracker.ietf.org/doc/draft-alvestrand-mmusic-msid/ At that time, there was interest in solving the problem of cross session stream identification. We would like to poll the working group for consensus on adopting the above mentioned draft as a working group item, once we get an approved milestone. If you support this work or have problems with the adoption of this document as WG item, please indicate it by replying to this e-mail within the next 5 days. Flemming and Miguel (co-chairs) -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain --------------020204040001050109050709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit If people feel that this should be progressed, now is a good time to say so in MMUSIC.

          Harald


-------- Original Message --------
Subject: WG poll for consensus MSID draft
Date: Tue, 9 Oct 2012 15:24:04 +0200
From: Miguel A. Garcia <Miguel.A.Garcia@ericsson.com>
To: mmusic <mmusic@ietf.org>
CC: Flemming Andreasen <fandreas@cisco.com>, Harald Alvestrand <harald@alvestrand.no> 


At the last IETF meeting we had a presentation of the following draft:

http://datatracker.ietf.org/doc/draft-alvestrand-mmusic-msid/

At that time, there was interest in solving the problem of cross session 
stream identification.

We would like to poll the working group for consensus on adopting the 
above mentioned draft as a working group item, once we get an approved 
milestone.

If you support this work or have problems with the adoption of this 
document as WG item, please indicate it by replying to this e-mail within 
the next 5 days.

Flemming and Miguel (co-chairs)

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain



--------------020204040001050109050709-- From christer.holmberg@ericsson.com Wed Oct 10 01:03:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2745321F843A for ; Wed, 10 Oct 2012 01:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.233 X-Spam-Level: X-Spam-Status: No, score=-4.233 tagged_above=-999 required=5 tests=[AWL=-1.773, BAYES_00=-2.599, FB_NO_MORE_OFFER=3.189, HELO_EQ_SE=0.35, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okm1Omu-Kor9 for ; Wed, 10 Oct 2012 01:03:33 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCCF21F8230 for ; Wed, 10 Oct 2012 01:03:32 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-9c-50752bd3eb72 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 56.B6.17130.3DB25705; Wed, 10 Oct 2012 10:03:32 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 10 Oct 2012 10:03:31 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" Date: Wed, 10 Oct 2012 10:03:30 +0200 Thread-Topic: [rtcweb] Agenda requests for Atlanta meeting Thread-Index: AQHNpaenkG2ADNG+3EO5+NGGgdEEepewfwQwgADbJICAAB9QAIAAMMWAgAARVYCAAHMnwA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAD102B@ESESSCMS0356.eemea.ericsson.se> References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAD087E@ESESSCMS0356.eemea.ericsson.se> , <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvre4V7dIAg43zWC06JrNZXDvzj9Fi 7b92dgdmjym/N7J67Jx1l91jyZKfTAHMUVw2Kak5mWWpRfp2CVwZ9yc9Zi2YKFXxdp16A+NB kS5GTg4JAROJvR3b2CFsMYkL99azdTFycQgJnGKU+LO6kwnCWcgosePER9YuRg4ONgELie5/ 2iANIgKGEk175jGB2MwCIRIPz75jBilhEVCVeHJPAiQsLGApsWjzfjaIciuJNbeuM0PYYRJr l5wFs3kFwiVu7ZvLCrHqGYvE1U1zwBo4BXwlfs1ayAJiMwId9/3UGqhd4hK3nsxngjhaQGLJ nvPMELaoxMvH/1gh6kUl7rSvZ4So15FYsPsTG4StLbFs4WuoxYISJ2c+YZnAKDYLydhZSFpm IWmZhaRlASPLKkbh3MTMnPRyc73Uoszk4uL8PL3i1E2MwFg6uOW3wQ7GTffFDjFKc7AoifPq qe73FxJITyxJzU5NLUgtii8qzUktPsTIxMEp1cB4Wizok/XbG6E7/Je9fp0vk7MpROLUC1XV bXVHuj2q3NhfbL0n+XdSQ5Dk1PXcm19pHb2Vzacnfu2s6sqtE/L+tUxr/Tpf20VuPtfTDPfm X2uzHcoTv6vWBkey97DzWqr/zz7xZlPXdNXjKTvNXkdcEHZyl9tQfLg5ZZ/UnE8BS3Nj1NjW +lxTYinOSDTUYi4qTgQA10tNbXMCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 08:03:34 -0000 Hi, >>>> I have not seen any reason to relax 3264 yet but if something comes up= , agree we should carefully look at the cases. I think we can just do strai= ght up 3264. >>>=20 >>> RFC 3264 doesn't describe PRANSWER. The concept is entirely absent. >>>=20 >>> The offerer MAY immediately cease listening for media formats that =20 >>> were listed in the initial offer, but not present in the answer. >>>=20 >>> "the" answer. >>=20 >> I agree with Martin. 3264 O/A is always per dialog, and forking is suppo= rted by generating multiple dialogs. JSEP, OTOH, in order to support forkin= g with a=20 >> single "dialog" (peerConnection local descriptor), now defines O/A as of= fer+any number of pranswers + answer. >>=20 >> So, we would e.g. have to define what happens if a new offer is received= from the remote side while the browser is in pranswer-received state (see = my call flow in another reply). > > 3264, SDP, 3261, and related documents are dealing with a bunch of things= including what happens at media plane and signaling plane.=20 > > I'll note that though O/A is per dialog, there is only one O shared acros= s multiple legs and when you create the O you don't know how many dialogs t= here will be. The *initial* O is shared across multiple legs. Once a dialog has been crea= ted, O/A transactions on that leg will not affect other legs. > So from the media point of view (covered more in SDP spec than 3264) ther= e is one O with a bunch of A. From signaling point of view there are a bunc= h of O/A pairs).=20 > > The dialog is SIP signaling concept not a media plane level concept. We m= oved the signaling part out of the browser and into the JS. But the media p= art is still in the=20 > browser. So as 3264 says, after the offer is constructed, we have to be w= illing to receive media for all the codec type in the offer. When we get th= e answer 3264 makes=20 > it clear that one MAY stop receiving the codecs that were in the offer bu= t not selected in the answer. However, this can not be done until the signa= ling layer is sure that=20 > no more offers will be honored. Since that signalling part of Offer/Answe= r is in the JS, the API need to to have a way to signal what the MAY part s= hould do and that is=20 > the PRANSWER vs ANSWER.=20 > > People keep trying to make this some complex weird argument invoking the = SIP deities of the past and quoting incomprehensible phrases from various R= FC caved in=20 > stone but the bottom line in the code is very simple to understand. When = creating the offer you alloced some resources ( like a port to receive vide= o on ). When you > get an answer that does not use that resource, you need to tell the media= stack if it should free the resources or not. O/A has situation where you = need to keep the=20 > resources available (like there are more dialogs coming) and situation wh= ere you need to free the resource. Since we split the signalling out of th= e browser and left=20 > the media in the browser, we need be able to allow the JS that is dealing= with signaling to tell the browser when to free the resource.=20 I don't know who "people" is, but at least I have only been talking about t= he O/A *signaling* :) Media is a separate issue. Regards, Christer From pkyzivat@alum.mit.edu Wed Oct 10 11:42:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E07121F86B1 for ; Wed, 10 Oct 2012 11:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.381 X-Spam-Level: X-Spam-Status: No, score=-0.381 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLNT-0jiFi3t for ; Wed, 10 Oct 2012 11:42:44 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 5052B21F8617 for ; Wed, 10 Oct 2012 11:42:44 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta01.westchester.pa.mail.comcast.net with comcast id 9RBa1k0040SCNGk51WiofE; Wed, 10 Oct 2012 18:42:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id 9WeA1k00a3ZTu2S3VWeAgj; Wed, 10 Oct 2012 18:38:10 +0000 Message-ID: <5075C076.5060806@alum.mit.edu> Date: Wed, 10 Oct 2012 14:37:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <506D4F7A.5020109@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> <506F1526.4050306@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 18:42:45 -0000 On 10/5/12 1:46 PM, Roman Shpount wrote: > > On Fri, Oct 5, 2012 at 1:13 PM, Harald Alvestrand > wrote: > > I've asked that question before, but I don't remember seeing an > answer from people who know what they're talking about: > > Does serial forking, as practiced by SIP UAs, violate the SDP O/A > model, or does it not violate the SDP O/A model? > > I don't understand how it, in the form that has been described as > "what we have to support", can be SDP O/A compatible, but then there > are many things about SIP that I don't understand, so I may > understand it when it's explained to me. > > > O/A does not describe multiple answers to a single offer. Nothing > explicitly prohibits it there but I would argue this is not part of this > specification. No standard document that I am aware of describes how > serial O/A is supposed to work. Serial forking as practiced by SIP UA > does violate SIP RFC 3261 which states that each dialog can only have > one answer to each offer. If answer is sent in both provisional and > final response, it should be the same. You can, however, create multiple > dialogs with the same offer. This normally implies parallel forking, but > the most common use case is with early media, where you end up with > multiple early dialogs. For instance you call a phone number, phone > network sends you SDP in early media and plays a dial tone, then the > called number does not answer, and you get connected to a voice mail > which uses a completely different SDP in final answer. According to SIP > these answers should come with different to-tags and technically would > be parts of two different dialogs. Good summary. That is indeed the compliant way to handle this case. > What makes this a bit tricky is when > the phone network and the voice mail are behind SBC (or some other sort > of B2BUA) you only see one dialog which send you multiple answers to the > same offer. This scenario is so common that it is more likely to be > implemented then parallel forking. If you see this then you should complain to the vendor of the SBC/B2BUA that they are broken. There is nothing to prevent the SBC from generating multiple dialogs in order to do this case correctly. > This is why PRANSWER was suggested. > > If cloning can be implemented in WebRTC it would be more standard > compliant then PRANSWER and would allow for a lot more use cases. > Typical difficulty in parallel forking implementation in SIP is due to > RTP from multiple sources coming to the same IP and port with no consent > or notification to the receiving side. This makes it very difficult to > present this media to the user. Yep. > There is no way to tie media to actual > dialogs since RTP can come from different IP and ports then specified in > answer SDPs. Known problem. There was a proposal *long* ago to solve this by the caller generating new O/As (with distinct addr/port) as soon as possible after discovering that forking has occurred. But that didn't go anywhere. And it would still leave a window where the association of address to dialog isn't known. > This is not an issue with WebRTC where consent to receive > media is required. Yes. ICE helps a lot. > I would argue let's implement cloning and not waste > any more time on PRANSWER which in my opinion will always stay a half > working hack. Sounds good to me. Thanks, Paul From pkyzivat@alum.mit.edu Wed Oct 10 11:55:17 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B2821F86DD for ; Wed, 10 Oct 2012 11:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.381 X-Spam-Level: X-Spam-Status: No, score=-0.381 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Z9guYS2touh for ; Wed, 10 Oct 2012 11:55:16 -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 38EC821F86DC for ; Wed, 10 Oct 2012 11:55:16 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta14.westchester.pa.mail.comcast.net with comcast id 9SVy1k00327AodY5EWvLA6; Wed, 10 Oct 2012 18:55:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id 9Wql1k00B3ZTu2S3fWqlK0; Wed, 10 Oct 2012 18:50:45 +0000 Message-ID: <5075C366.9050603@alum.mit.edu> Date: Wed, 10 Oct 2012 14:50:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <506D4F7A.5020109@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> <506F1526.4050306@alvestrand.no> In-Reply-To: <506F1526.4050306@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 18:55:17 -0000 On 10/5/12 1:13 PM, Harald Alvestrand wrote: > On 10/04/2012 08:21 PM, Christer Holmberg wrote: >> Hi, >> >>>> For the Web use case, I think PRANSWER is an unnecessary >>>> distraction; if >>>> we're writing both initiator and responder, multiple O/A rounds, or >>>> use of >>>> multiple PeerConnections, is a much cleaner solution for the use >>>> cases I can >>>> wrap my head around. >>> I'd remove that qualifier. We currently have a draft that describes >>> both cloning AND PRANSWER, both of which are more cleanly addressed by >>> either multiple O/A rounds or multiple independent sessions. >>> >>> PRANSWER: >>> The ability to describe a session that includes receipt capabilities >>> that are a superset of send capabilities. SDP O/A doesn't really >>> provide a way for me to describe this because the default assumption >>> is that items not appearing in the answer are no longer needed. >>> With something like bundle involved, we could split m= lines into >>> sendonly and recvonly portions to allow for this case to be provided. >> I don't think the reason for PRANSWER comes from SDP O/A as such. It's >> more about supporting serial forking. > I've asked that question before, but I don't remember seeing an answer > from people who know what they're talking about: > > Does serial forking, as practiced by SIP UAs, violate the SDP O/A model, > or does it not violate the SDP O/A model? In addition to what Roman already said, I'll add: SIP (3261 & friends) doesn't say much about how to *do* forking. It sets down a bunch of rules, and developing algorithms that adhere to the rules is left as an exercise for the reader. There are also many things that are implicit but that must be inferred via long chains of reasoning. Much of this has become folklore. (RFC 6337 attempts to explain a lot of O/A, but doesn't directly address forking.) The use of a separate dialog per fork falls out for free, by the nature of how to-tags (part of dialog id) are assigned. But this is still a point of confusion among new (and some not so new) sip implementers. Questions about this come up regularly on the sip-implementers list. I think the frequency of them has been maintained for as long as I can remember. So indeed there are ongoing violations, and some implementations are built to tolerate those violations. Thanks, Paul From partha@parthasarathi.co.in Wed Oct 10 12:52:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80E621F85A3 for ; Wed, 10 Oct 2012 12:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.135 X-Spam-Level: X-Spam-Status: No, score=-0.135 tagged_above=-999 required=5 tests=[AWL=-1.659, BAYES_00=-2.599, FB_NO_MORE_OFFER=3.189, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8mlqHjgsc6i for ; Wed, 10 Oct 2012 12:52:26 -0700 (PDT) Received: from outbound-us2.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.233]) by ietfa.amsl.com (Postfix) with ESMTP id AB82221F85A2 for ; Wed, 10 Oct 2012 12:52:26 -0700 (PDT) Received: from userPC (unknown [122.179.93.126]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us2.mailhostbox.com (Postfix) with ESMTPA id C939C3E1143; Wed, 10 Oct 2012 19:52:11 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1349898735; bh=yL1sibAFa8P2MGh4Xu1bNXnnIk8X91ruRW972QR5UCQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=eWkTE1FI0jzFGyHjrP4DMudenllidBGCGpjSUPtJm9Fy2mLnF1YRmbYR1GaTN0epe nAl8/ncNmwWiBeDNK93SfcR9rTbW89t1OsQFXEtqtUwdUSKoUZZq/XB6Aaq4yxGY/E hWOBxR2fCZDRQF2TTOeO31Xl7LRWaDTw58XERdio= From: "Parthasarathi R" To: "'Cullen Jennings \(fluffy\)'" , "'Christer Holmberg'" References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAD087E@ESESSCMS0356.eemea.ericsson.se> , <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Date: Thu, 11 Oct 2012 01:21:58 +0530 Message-ID: <000b01cda720$bd5097a0$37f1c6e0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNpaenkG2ADNG+3EO5+NGGgdEEepewfwQwgADbJICAAB9QAIAAMMWAgAARVYCAAStCEA== Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A020207.5075D1EF.015B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 19:52:27 -0000 Cullen, As signaling is moved to JS (application layer), Offer-answer in JSEP has to be generic enough. The underlying assumption in PRANSWER state is that webserver knows whether the received SDP from remote is PRANSWER or final ANSWER. Unfortunately, Webserver may not able to tell whether the receive in lot of real time deployment which is an open issue now. UPDATE offer after 18x answer from remote is the typical example where PRANSWER state breaks. The real-time usage of SIP UPDATE offer is to update the existing answer in 18x in the same dialog. Early dialog UPDATE callflow is well deployment because of PSTN remote ringback (18x) from media server and then UPDATE with SDP to update the media information of remote endpoing and then, call connect (200 ok) from actual endpoint. The same PSTN callflow shall be achieved by serial forking as well. Please note that the final answer or not is not based on browser or originating SIP UA but it is based on the intermediate SIP entities. >From RTCWeb perspective, The new OFFER is possible to be received in browser as per RFC 3264 after the first answer is received. PRANSWER is the new state in JSEP wherein JSEP is the extension of RFC 3264. It will be good in case you explain how browser in PRANSWER has to handle new OFFER from the remote side. Please include me in case any phone discussion if you are planning. Thanks Partha -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings (fluffy) Sent: Wednesday, October 10, 2012 1:35 AM To: Christer Holmberg Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Agenda requests for Atlanta meeting On Oct 9, 2012, at 12:04 , Christer Holmberg wrote: > Hi, > >>> I have not seen any reason to relax 3264 yet but if something comes up, agree we should carefully look at the cases. I think we can just do straight up 3264. >> >> RFC 3264 doesn't describe PRANSWER. The concept is entirely absent. >> >> The offerer MAY immediately cease listening for media formats that >> were listed in the initial offer, but not present in the answer. >> >> "the" answer. > > I agree with Martin. 3264 O/A is always per dialog, and forking is supported by generating multiple dialogs. JSEP, OTOH, in order to support forking with a single "dialog" (peerConnection local descriptor), now defines O/A as offer+any number of pranswers + answer. > > So, we would e.g. have to define what happens if a new offer is received from the remote side while the browser is in pranswer-received state (see my call flow in another reply). 3264, SDP, 3261, and related documents are dealing with a bunch of things including what happens at media plane and signaling plane. I'll note that though O/A is per dialog, there is only one O shared across multiple legs and when you create the O you don't know how many dialogs there will be. So from the media point of view (covered more in SDP spec than 3264) there is one O with a bunch of A. From signaling point of view there are a bunch of O/A pairs). The dialog is SIP signaling concept not a media plane level concept. We moved the signaling part out of the browser and into the JS. But the media part is still in the browser. So as 3264 says, after the offer is constructed, we have to be willing to receive media for all the codec type in the offer. When we get the answer 3264 makes it clear that one MAY stop receiving the codecs that were in the offer but not selected in the answer. However, this can not be done until the signaling layer is sure that no more offers will be honored. Since that signalling part of Offer/Answer is in the JS, the API need to to have a way to signal what the MAY part should do and that is the PRANSWER vs ANSWER. People keep trying to make this some complex weird argument invoking the SIP deities of the past and quoting incomprehensible phrases from various RFC caved in stone but the bottom line in the code is very simple to understand. When creating the offer you alloced some resources ( like a port to receive video on ). When you get an answer that does not use that resource, you need to tell the media stack if it should free the resources or not. O/A has situation where you need to keep the resources available (like there are more dialogs coming) and situation where you need to free the resource. Since we split the signalling out of the browser and left the media in the browser, we need be able to allow the JS that is dealing with signaling to tell the browser when to free the resource. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From worley@shell01.TheWorld.com Wed Oct 10 13:27:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F6111E809B for ; Wed, 10 Oct 2012 13:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXwbjJrdnXou for ; Wed, 10 Oct 2012 13:27:09 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 53DB411E808D for ; Wed, 10 Oct 2012 13:27:09 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id q9AKQHRt004278 for ; Wed, 10 Oct 2012 16:26:20 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9AKQHV74318061 for ; Wed, 10 Oct 2012 16:26:17 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9AKQH8o4341543; Wed, 10 Oct 2012 16:26:17 -0400 (EDT) Date: Wed, 10 Oct 2012 16:26:17 -0400 (EDT) Message-Id: <201210102026.q9AKQH8o4341543@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: rtcweb@ietf.org Subject: [rtcweb] The SIP gateway use case X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 20:27:10 -0000 I'm new to this discussion. Being from the SIP community, my "default use case" for WebRTC is when the web server routes the WebRTC media to a SIP gateway, which I expect will be a significant fraction of early usage of WebRTC. Within this context, the WebRTC architecture needs to be able to support the media stream operations that a SIP endpoint ("user agent", UA) must implement. Those operations are not immediately clear from a reading of the standards (as many a SIP implementer has discovered), partly due to the complexity of the situation and partly because a number of critical problems are not manifested in the protocol operations, and hence the RFCs do not address them. The proper, indeed necessary, operations only become clear from an extended discussion of various cases and what strategies will and won't work in practice. My apologies if any of this duplicates what others have already described. I've tried to leave out irrelevant parts of the SIP signaling. I may have made some mistakes. In particular, I'm not familiar with the details of ICE. Please correct any mistakes. I've divided the discussion into three sections - Background - The situation the SIP caller is faced with - Architectural questions * Background Let me describe the actions by a SIP endpoint that initiates a call (a "user agent client", UAC). The operation of a SIP endpoint that receives a call (a "user agent server", UAS) is similar but much simpler, and I will leave it to the reader to construct that discussion. Similarly, I will assume that the UAC sends an initial offer; when the UAC does not send an initial offer, the operations are similar but simpler. The UAC sends the INVITE containing the initial offer. Over time, this INVITE reaches various UASs via request forwarding, serial forking, and parallel forking. Between the UAC and each UAS, SIP constructs a "dialog", which is the stream of SIP requests and responses between them through intermediary SIP entities, and the associated dialog state. Because of network delays, because some SIP responses are not reliably transmitted, and because some SIP responses are absorbed by intermediate SIP entities, the UAC does not have complete knowledge of the dialogs it is participating in. Connected with each dialog is a "session", which is a collection of media streams. Each session is described by the two SDPs which have been sent from each UA to the other, and that description can change over time due to SIP messages carrying SDP offers and answers. The sending and receiving of SDP between the UAC and each UAS is separately governed by the offer/answer rules and has its own offer/answer state. (Excepting that all offer/answer states necessarily start with the same initial offer.) ICE negotiation is performed within any session for which SDP has been sent and received. In practice, the UAC uses a separate port for each media stream (m-line) in its offer, but for any media stream, uses the same port to communicate the clone of that media stream to/from each UAS. In practice, each UAS uses a different ports from every other UAS, and a different port for each media stream. The RTP of a media stream is not labeled to match it with the governing SDP for its session; the matching is done heuristically between the port used by the UAS and the port listed in the SDP. Because SIP responses may not reach the UAC promptly, the UAC can be participating in sessions that it has received no SDP for. A dialog and its session can be terminated in various ways: - Final termination of the call by sending/receiving a BYE - Termination of an early dialog by the UAC sending a BYE (uncommon, but allowed) - Termination of all but one of several 200 responses received in a race situation by the UAC sending BYEs - The UAS sending a failure final response. (But some such responses are received by intermediate proxies and not passed on, and trigger serial forking.) - The UAS sending a 199 response (or a proxy sending a 199 response on behalf of the UAS), which may reach the UAC * The situation the SIP caller is faced with Thus, the SIP caller (UAC) is participating in a dynamically changing collection of sessions. Some of the sessions the UAC has complete knowledge of, and maintains an offer/answer state for. The current SDP for a session can be updated by either UA. The corresponding RTP streams are identified by their UAS-end addresses. Some of the sessions the UAC has no knowledge of, other than that it is receiving RTP for the session. The UAC may later receive SDP for such a session. The situation will be simplified to one dialog and session when: - the dialog is ended by the UAC receiving a failure final response to the initial INVITE - the call is established by the UAC receiving a 200 final response (but the UAC must be prepared to receive additional 200 final responses and terminate those dialogs with BYE) Regarding the media received in each particular session, there are several alternatives: - The media are being received, and are not silence. This stream should be mixed into what the user hears, as it contains information from a UAS. - The media are absent or silent, but the SIP signaling has indicated that the far end is ringing (a 180 has been received on this dialog). For this stream, a ringback signal should be mixed into what the user hears. - The media are absent or silent, and the SIP signaling has not indicated that the far end is ringing. For this stream, nothing should be mixed into what the user hears. Regarding the media sent to each particular session: - If a session is for an established dialog, the user's voice should be sent to the (necessarily unique) UAS. - If a session is the only early dialog, the user's voice should be sent to the unique UAS. (This is because some legitimate callees delay proving a 200 response and have extended information interchange during the early dialog.) - If there are multiple early dialogs, practice seems not to be standardized. * Architectural questions In this context, the major architectural questions seem to be the degree to which this messy reality is revealed to the WebRTC browser-side code. The choices on these questions are reflected in both the wire protocol and the Javascript API. Does WebRTC reveal the multiple sessions to the multiple UASs? (It seems that any sessions for which outgoing RTP can be generated (at the browser), must be individually revealed to the browser, as each UAS can provide answer SDP that has no codec in common with other answer SDPs.) Does WebRTC reveal/permit later offer/answer cycles for a session? (Note that the SIP UA can prevent later offer/answer cycles by not sending re-INVITEs/UPDATEs and giving failure responses to any received re-INVITEs/UPDATEs. But this is unlikely to be tolerated in practice, as later offer/answer cycles are used in many SIP systems.) Does WebRTC transport signaling-level ring and call failure information (e.g., the SIP call progress and termination response codes), or just the initiation and termination events of sessions? Does WebRTC transport or reveal in the API the complete SDP or just selected information from it? Does WebRTC provide facilities for the Javascript to affect the handling of multiple sessions (e.g., forcibly terminating an early dialog with undesirable properties)? (Note that in SIP phones, the user is usually not provided with any such facility.) Dale From worley@shell01.TheWorld.com Wed Oct 10 13:29:09 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535E921F859F for ; Wed, 10 Oct 2012 13:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.748 X-Spam-Level: X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONENSKjD+4Yb for ; Wed, 10 Oct 2012 13:29:08 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id B31B121F8534 for ; Wed, 10 Oct 2012 13:29:08 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id q9AKSb5X012070 for ; Wed, 10 Oct 2012 16:28:39 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9AKSaiq4339090 for ; Wed, 10 Oct 2012 16:28:37 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9AKSaxu4352980; Wed, 10 Oct 2012 16:28:36 -0400 (EDT) Date: Wed, 10 Oct 2012 16:28:36 -0400 (EDT) Message-Id: <201210102028.q9AKSaxu4352980@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: rtcweb@ietf.org Subject: [rtcweb] Relaxing SDP O/A rules? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 20:29:09 -0000 > From: Roman Shpount [roman@telurix.com] > > You can, however, create multiple dialogs with the same offer. This > normally implies parallel forking, but the most common use case is > with early media, where you end up with multiple early dialogs. For > instance you call a phone number, phone network sends you SDP in > early media and plays a dial tone, then the called number does not > answer, and you get connected to a voice mail which uses a > completely different SDP in final answer. According to SIP these > answers should come with different to-tags and technically would be > parts of two different dialogs. > > What makes this a bit tricky is when the > phone network and the voice mail are behind SBC (or some other sort > of B2BUA) you only see one dialog which send you multiple answers to > the same offer. This scenario is so common that it is more likely to > be implemented then parallel forking. This is why PRANSWER was > suggested. Strictly speaking, if the first answer is sent reliably (presumably in a reliable provisional response), then the first O/A cycle is finished and a second can be initiated. What makes this situation interesting is that the second O/A cycle can be done before any dialog is established, that is, while further early dialogs may be created. If the first answer is not sent reliably, then the B2BUA may not send another offer without violating the O/A rules -- until a duplicate answer is sent reliably (presumably in the 200 response). > If cloning can be implemented in WebRTC it would be more standard > compliant then PRANSWER and would allow for a lot more use > cases. Typical difficulty in parallel forking implementation in SIP > is due to RTP from multiple sources coming to the same IP and port > with no consent or notification to the receiving side. This makes it > very difficult to present this media to the user. There is no way to > tie media to actual dialogs since RTP can come from different IP and > ports then specified in answer SDPs. This is not an issue with > WebRTC where consent to receive media is required. I would argue > let's implement cloning and not waste any more time on PRANSWER > which in my opinion will always stay a half working hack. In practice, almost all SIP systems send media from the address/port they specify in their SDP as the address/port from which they receive media. But if you implement RTP filtering or "consent to receive", that does not help, as before call establishment, a SIP caller can receive media from addresses/ports that it has not yet received SDP for. Dale From harald@alvestrand.no Thu Oct 11 08:23:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C5821F8742 for ; Thu, 11 Oct 2012 08:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.699 X-Spam-Level: X-Spam-Status: No, score=-109.699 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVh2sGzw9kfy for ; Thu, 11 Oct 2012 08:23:13 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 92ED621F8740 for ; Thu, 11 Oct 2012 08:23:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9F30039E057 for ; Thu, 11 Oct 2012 17:23:10 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZGcMUW2atvu for ; Thu, 11 Oct 2012 17:23:09 +0200 (CEST) Received: from [192.168.1.16] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id F0EEE39E04C for ; Thu, 11 Oct 2012 17:23:08 +0200 (CEST) Message-ID: <5076E4CD.2020602@alvestrand.no> Date: Thu, 11 Oct 2012 17:25:01 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAD087E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 15:23:14 -0000 On 10/09/2012 04:16 PM, Cullen Jennings (fluffy) wrote: > On Oct 8, 2012, at 23:41 , Christer Holmberg > wrote: >> >> I have no problem with that. But, again, we do need to get the JSEP O/A sorted out. My suggesting is still that the base should be RFC 3264, and if we need to "relax" things we should very carefully look at those cases. > I have not seen any reason to relax 3264 yet but if something comes up, agree we should carefully look at the cases. I think we can just do straight up 3264. Arguments that SIP early media in a 180 is not compliant with 3264 are just wrong. > This seems to be true as long as I consider the offer/180 exchange a separate SDP exchange from the offer/answer exchange, and abandon the concept that the final answer "updates" the 180 answer. Is that what you are saying, or did I squint the wrong way? From christer.holmberg@ericsson.com Thu Oct 11 08:42:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA0721F8734 for ; Thu, 11 Oct 2012 08:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.126 X-Spam-Level: X-Spam-Status: No, score=-6.126 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2d38N4QrCWVH for ; Thu, 11 Oct 2012 08:42:13 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCDD21F871D for ; Thu, 11 Oct 2012 08:42:13 -0700 (PDT) X-AuditID: c1b4fb25-b7f956d0000011c3-c6-5076e8d4d725 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 9C.CC.04547.4D8E6705; Thu, 11 Oct 2012 17:42:12 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 11 Oct 2012 17:42:11 +0200 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Date: Thu, 11 Oct 2012 17:38:18 +0200 Thread-Topic: [rtcweb] Agenda requests for Atlanta meeting Thread-Index: Ac2nxFkYlxHAcOGpQSSR4wekASssMwAAhcYH Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA7E@ESESSCMS0356.eemea.ericsson.se> References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAD087E@ESESSCMS0356.eemea.ericsson.se> , <5076E4CD.2020602@alvestrand.no> In-Reply-To: <5076E4CD.2020602@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvre6VF2UBBvM/ilkc6+tis1j7r53d gcnjyoQrrB5LlvxkCmCK4rJJSc3JLEst0rdL4MroOPeWreAHR8XPe6tYGhgb2LsYOTgkBEwk lh+36WLkBDLFJC7cW8/WxcjFISRwilGi98hEZghnIaPEq88rwBrYBCwkuv9pgzSICARL9D5/ zwhiswioSuzfeosJxBYWsJRYtHk/G0SNlcSaW9eZIWwjiWe77oPZvALhEgt7u9lBbCGBjcwS bQsVQGxOAV2J1yfes4LYjEAHfT+1Bmwms4C4xK0n85kgDhWQWLLnPDOELSrx8vE/qHpRiTvt 6xkh6nUkFuz+xAZha0ssW/gaaq+gxMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsopRODcxMye9 3EgvtSgzubg4P0+vOHUTIzBCDm75rbqD8c45kUOM0hwsSuK81lv3+AsJpCeWpGanphakFsUX leakFh9iZOLglGpgbBHRXXFGbGVLVUiiLveHR4cXOme9f3W0/2vUhM4Lk14cPNLQtCKjd+nR OD/Dd0sdxOe7bWnfOyfmn0jK0vkth6ZmMs8uj88wuLBm273PfZLLpGLVHPSlCytmGrybwb/6 5tpZWq6c2htsrq4wjPRg2vhVLVP1qBPLlOaVGulc247ZbUh935DzQ4mlOCPRUIu5qDgRACQk 5LpeAgAA Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 15:42:14 -0000 Hi, >>> I have no problem with that. But, again, we do need to get the JSEP O/A= sorted out. My suggesting is still that the base should be RFC 3264, and i= f we need to "relax" things we should very carefully look at those cases. >> I have not seen any reason to relax 3264 yet but if something comes up, = agree we should carefully look at the cases. I think we can just do straigh= t up 3264. Arguments that SIP early media in a 180 is not compliant with 32= 64 are just wrong. > > This seems to be true as long as I consider the offer/180 exchange a > separate SDP exchange from the offer/answer exchange, and abandon the > concept that the final answer "updates" the 180 answer. > > Is that what you are saying, or did I squint the wrong way? If you receive the SDP answer in a reliable 180 response, that IS an offer/= answer exchange :) That answer CANNOT be "updated" in another reliable 18x response, or in the= 200 response.=20 (You can receive a "copy" of the previously received SDP answer in the 18x/= 200 responses, but it will not update the previously received SDP answer) Regards, Christer= From christer.holmberg@ericsson.com Thu Oct 11 08:45:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B0C21F874C for ; Thu, 11 Oct 2012 08:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.127 X-Spam-Level: X-Spam-Status: No, score=-6.127 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyF73OX0uG2v for ; Thu, 11 Oct 2012 08:45:13 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D064121F86C9 for ; Thu, 11 Oct 2012 08:45:12 -0700 (PDT) X-AuditID: c1b4fb25-b7f956d0000011c3-ab-5076e9878f04 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 5B.1D.04547.789E6705; Thu, 11 Oct 2012 17:45:11 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Thu, 11 Oct 2012 17:45:11 +0200 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Date: Thu, 11 Oct 2012 17:44:18 +0200 Thread-Topic: [rtcweb] Agenda requests for Atlanta meeting Thread-Index: Ac2nxFkYlxHAcOGpQSSR4wekASssMwAAhcYHAAA1pVI= Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA7F@ESESSCMS0356.eemea.ericsson.se> References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAD087E@ESESSCMS0356.eemea.ericsson.se> , <5076E4CD.2020602@alvestrand.no>, <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA7E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA7E@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+JvrW77y7IAg1/3jSyO9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGW0NU5nK9jJW7H74XKWBsZPXF2MnBwSAiYS 39e1s0HYYhIX7q0Hsrk4hAROMUrc7NzOAuHMZZR4NvMraxcjBwebgIVE9z9tkAYRgWCJ3ufv GUFsFgFViX+PFrGC2MIClhKLNu9ng6ixklhz6zozjN30/TyYzSsQLvF/+2pWiPkNLBJbXt4B a+AUiJA49vEB2FBGoIu+n1rDBGIzC4hL3HoynwniUgGJJXsgBkkIiEq8fPyPFaJeVOJO+3pG iHodiQW7P7FB2NoSyxa+hlosKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiFM5NzMxJLzfS Sy3KTC4uzs/TK07dxAiMkoNbfqvuYLxzTuQQozQHi5I4r/XWPf5CAumJJanZqakFqUXxRaU5 qcWHGJk4OKUaGGvbFk5UXHnAmN9pd/mab+2Bs26HThTc7DbJ/4mSU61Z3kZh8Rc1398+/ZT6 9dCGjw7Tlr51WxShZHn+F/dX6aOzA5QtFBwLfXm+SB5/6/k6/phv4tqL+oeiWScyxJbw1uoF TS5mLZ1ptYYhXvlSq2hW4vyk5Qeq87xC/1V7zPeZmNi05+nRf0osxRmJhlrMRcWJAPFYdqBg AgAA Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 15:45:14 -0000 That answer CANNOT be "updated" in another reliable 18x response, or in the= 200 response - on the same SIP early dialog, that is. ________________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Christ= er Holmberg [christer.holmberg@ericsson.com] Sent: Thursday, October 11, 2012 6:38 PM To: Harald Alvestrand; rtcweb@ietf.org Subject: Re: [rtcweb] Agenda requests for Atlanta meeting Hi, >>> I have no problem with that. But, again, we do need to get the JSEP O/A= sorted out. My suggesting is still that the base should be RFC 3264, and i= f we need to "relax" things we should very carefully look at those cases. >> I have not seen any reason to relax 3264 yet but if something comes up, = agree we should carefully look at the cases. I think we can just do straigh= t up 3264. Arguments that SIP early media in a 180 is not compliant with 32= 64 are just wrong. > > This seems to be true as long as I consider the offer/180 exchange a > separate SDP exchange from the offer/answer exchange, and abandon the > concept that the final answer "updates" the 180 answer. > > Is that what you are saying, or did I squint the wrong way? If you receive the SDP answer in a reliable 180 response, that IS an offer/= answer exchange :) That answer CANNOT be "updated" in another reliable 18x response, or in the= 200 response. (You can receive a "copy" of the previously received SDP answer in the 18x/= 200 responses, but it will not update the previously received SDP answer) Regards, Christer _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb= From bernard_aboba@hotmail.com Thu Oct 11 11:58:08 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20E121F859F for ; Thu, 11 Oct 2012 11:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.216 X-Spam-Level: X-Spam-Status: No, score=-102.216 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbSmBk4sSEJD for ; Thu, 11 Oct 2012 11:58:08 -0700 (PDT) Received: from blu0-omc3-s35.blu0.hotmail.com (blu0-omc3-s35.blu0.hotmail.com [65.55.116.110]) by ietfa.amsl.com (Postfix) with ESMTP id ECC1621F850B for ; Thu, 11 Oct 2012 11:58:07 -0700 (PDT) Received: from BLU169-DS31 ([65.55.116.73]) by blu0-omc3-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Oct 2012 11:58:07 -0700 X-Originating-IP: [24.16.96.166] X-EIP: [ICieIffDoxJ+nEn/fZTVbQqLOe5yHaGH] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: Date: Thu, 11 Oct 2012 11:58:29 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E6_01CDA7A7.BAF185A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2n390YKMPBJlHJR6qO6A5g1JgwWw== Content-Language: en-us X-OriginalArrivalTime: 11 Oct 2012 18:58:07.0319 (UTC) FILETIME=[59B67670:01CDA7E2] Subject: [rtcweb] Agenda request: Overall Approach to defining SDP usage in WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 18:58:08 -0000 ------=_NextPart_000_01E6_01CDA7A7.BAF185A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In addition to covering "fascinating" topics such as MTI codecs and JSEP support of O/A at IETF 85, I'd like to suggest that we also set some time aside at IETF 85 to discuss the overall approach to defining SDP usage in WebRTC. In this "big picture" discussion, I'd like to try to figure out how we will answer some of the following questions: 1. What SDP functionality MUST/SHOULD/MAY be implemented/used in WebRTC API implementations? 2. What is the overall model for SDP usage in JSEP? 3. How much of this discussion belongs in W3C, how much in IETF? The goal of this discussion is *not* to get into the details of the answer to the questions, but rather to focus on what work needs to be done, what form it takes (adding material in existing docs, new docs, etc.), and what is handled in what org (W3C, IETF, etc.). To some extent, answers to question #1 are derivable from the RTP usage draft, but I'm not clear that it makes sense to cover all aspects of SDP usage there. Also, it would be useful to discuss the plan for documenting SDP in current usage that has no corresponding RFC or I-D (e.g. are all the bases covered?). In question #2, I would include questions such as the role of the constraints API (versus hacking SDP), what SDP lines/fields can or cannot be edited by applications and how SDP errors are handled. While it would certainly be possible to write a -00 draft, without understanding the overall plan, getting into detail probably doesn't make much sense. IMHO, slides should be sufficient, and I have some available to stimulate discussion. ------=_NextPart_000_01E6_01CDA7A7.BAF185A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In = addition to covering "fascinating" topics such as MTI codecs = and JSEP support of O/A at IETF 85, I'd like to suggest that we also set = some time aside at IETF 85 to discuss the overall approach to defining = SDP usage in WebRTC.  

 

In this = "big picture" discussion, I'd like to try to figure out how we = will answer some of the following questions:

 

  1. What SDP functionality MUST/SHOULD/MAY be implemented/used in = WebRTC API implementations?
  2. What is the overall model for SDP = usage in JSEP?
  3. How much of this discussion belongs in W3C, how much in = IETF?

 

The goal of this discussion is *not* to get = into the details of the answer to the questions, but rather to focus on = what work needs to be done,  what form it takes (adding material in = existing docs, new docs, etc.), and what is handled in what org (W3C, = IETF, etc.).

 

To = some extent, answers to question #1 are derivable from the RTP usage = draft, but I'm not clear that it makes sense to cover all aspects of SDP = usage there.  Also, it would be useful to discuss the plan for = documenting SDP in current usage that has no corresponding RFC or I-D = (e.g. are all the bases covered?).

 

In question = #2, I would include questions such as the role of the constraints API = (versus hacking SDP), what SDP lines/fields can or cannot be edited by = applications and how SDP errors are handled.

 

While it = would certainly be possible to write a -00 draft, without understanding = the overall plan, getting into detail probably doesn't make much sense. =  IMHO, slides should be sufficient, and I have some available to = stimulate discussion.

 

 

 

 

 

 

------=_NextPart_000_01E6_01CDA7A7.BAF185A0-- From juberti@google.com Thu Oct 11 22:42:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5805221F84C9 for ; Thu, 11 Oct 2012 22:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OM7TRbNFOTId for ; Thu, 11 Oct 2012 22:42:32 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7A27A21F8484 for ; Thu, 11 Oct 2012 22:42:32 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so2298885qcg.31 for ; Thu, 11 Oct 2012 22:42:31 -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:x-system-of-record; bh=nEp2yYMD6/pEF4Vni8pfSTF+ctQyQGK/0byS9eB39J8=; b=RAl+Srnh8nu2uM5tdbBVJvDTz0PcIt5cX6GxGZpKjfn51siKDhpYTBOazZWwuR8bKe ycFndBxZpHqq17InpbTz6hHI6Qfhb1c2ks9mNRW/GE9r6qL2U+mtEXyHGh5e2ccn8PqN VSnNWYgTvgGXgi9JdFojLhWoR1HKHh17GekieBS/y9YEqiRqj45UHs1uojKbTwTBKgLf HrjquGS9XHnViwZkvvLI4gG+xEZ2Pi1KwJHIn7PsOkm0CvXAkUmGxDO4B1kcc8WVaOCK MbIWRFBrVbdhehSgE2CWqgeo2QruLTdL0C9w/ggUgyMfKX5UBtwawEUsgkfKUEiQO1YF ZfhA== X-Google-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:x-system-of-record:x-gm-message-state; bh=nEp2yYMD6/pEF4Vni8pfSTF+ctQyQGK/0byS9eB39J8=; b=kqOPmKNhgyZ9SPzv+8McMvpo5whiYwyhjv45R0RI895G2GuaIOCnvTAGr9aOF5Z15g axeoNdV9FD0mCzGCazQkxiexDZSwGVbSyUJ10FWvnam1G9HvXN0g2KnejyR4xRa7uXDC QshAsGBzsMLv8h9BqIsPWyFmHrV9xLHysCMjjOrRWU4GdKwqFY/GDw+3EAOYd1l22gTC RJ+oScVl/YUi/2nFcL/yYsZ5QXtsS9ydkmTpHQvSLUYAosUuklCeur4M9RcCDSw2dTA4 oJei/8Y9LlvfvyuNEMD70dBqD2da9z5Dh+2i/Z+Gzbd9k/aC6Ho0CGdUMOfWKYmzT/Wg D1Mg== Received: by 10.229.209.167 with SMTP id gg39mr1433524qcb.154.1350020551619; Thu, 11 Oct 2012 22:42:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.216.194 with HTTP; Thu, 11 Oct 2012 22:42:11 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Thu, 11 Oct 2012 22:42:11 -0700 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=0016e6d260886b35d104cbd627a3 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnpEfevDc2Sd1VgtQ/ZbiSoqzy6nCp7rHqt0Rb8HSF1qydaAlyUwwFZo6uSqcoqS6jUpJUwc9556B+2vEui6JDI9v/d82/cGYf+0+aj0okOfrGBg0grRod+CoPzee3vgTRFM+LWRpwyMHCW12N/k4D9U/odAt2cvFyT1RHrXL1eUqw9oMbXVaD8KTID4TOW5UoenOmc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda request: Overall Approach to defining SDP usage in WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 05:42:33 -0000 --0016e6d260886b35d104cbd627a3 Content-Type: text/plain; charset=UTF-8 I am planning to address some of what you mention in the JSEP -02, and also have some slides on this for the JSEP discussion. On Thu, Oct 11, 2012 at 11:58 AM, Bernard Aboba wrote: > In addition to covering "fascinating" topics such as MTI codecs and JSEP > support of O/A at IETF 85, I'd like to suggest that we also set some time > aside at IETF 85 to discuss the overall approach to defining SDP usage in > WebRTC. **** > > ** ** > > In this "big picture" discussion, I'd like to try to figure out how we > will answer some of the following questions:**** > > ** ** > > 1. What SDP functionality MUST/SHOULD/MAY be implemented/used in > WebRTC API implementations?**** > 2. What is the overall model for SDP usage in JSEP?**** > 3. How much of this discussion belongs in W3C, how much in IETF? **** > > ** ** > > The goal of this discussion is **not** to get into the details of the > answer to the questions, but rather to focus on what work needs to be > done, what form it takes (adding material in existing docs, new docs, > etc.), and what is handled in what org (W3C, IETF, etc.).**** > > ** ** > > To some extent, answers to question #1 are derivable from the RTP usage > draft, but I'm not clear that it makes sense to cover all aspects of SDP > usage there. Also, it would be useful to discuss the plan for documenting > SDP in current usage that has no corresponding RFC or I-D (e.g. are all the > bases covered?). **** > > ** ** > > In question #2, I would include questions such as the role of the > constraints API (versus hacking SDP), what SDP lines/fields can or cannot > be edited by applications and how SDP errors are handled. **** > > ** ** > > While it would certainly be possible to write a -00 draft, without > understanding the overall plan, getting into detail probably doesn't make > much sense. IMHO, slides should be sufficient, and I have some available > to stimulate discussion. **** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --0016e6d260886b35d104cbd627a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am planning to address some of what you mention in the JSEP -02, and also= have some slides on this for the JSEP discussion.


On Thu, Oct 11, 2012 at 11:58 AM, Bern= ard Aboba <bernard_aboba@hotmail.com> wrote:

In addition to covering "fascinatin= g" topics such as MTI codecs and JSEP support of O/A at IETF 85, I'= ;d like to suggest that we also set some time aside at IETF 85 to discuss t= he overall approach to defining SDP usage in WebRTC. =C2=A0

=C2=A0

In th= is "big picture" discussion, I'd like to try to figure out ho= w we will answer some of the following questions:

=C2=A0

  1. What SDP functionality MUST/SHOULD/MAY be implemen= ted/used in WebRTC API implementations?
  2. What is the overall model for SDP usage in JSEP?
  3. How much of this discussion belongs in W3C, how muc= h in IETF?

=C2=A0<= /u>

The goal of this discussion is *not* t= o get into the details of the answer to the questions, but rather to focus = on what work needs to be done,=C2=A0 what form it takes (adding material in= existing docs, new docs, etc.), and what is handled in what org (W3C, IETF= , etc.).

=C2=A0

<= p class=3D"MsoNormal">To some extent, answers to question #1 are derivable = from the RTP usage draft, but I'm not clear that it makes sense to cove= r all aspects of SDP usage there.=C2=A0 Also, it would be useful to discuss= the plan for documenting SDP in current usage that has no corresponding RF= C or I-D (e.g. are all the bases covered?).

=C2=A0

In qu= estion #2, I would include questions such as the role of the constraints AP= I (versus hacking SDP), what SDP lines/fields can or cannot be edited by ap= plications and how SDP errors are handled.

=C2=A0

While= it would certainly be possible to write a -00 draft, without understanding= the overall plan, getting into detail probably doesn't make much sense= . =C2=A0IMHO, slides should be sufficient, and I have some available to sti= mulate discussion.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0=

=C2=A0


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


--0016e6d260886b35d104cbd627a3-- From juberti@google.com Thu Oct 11 22:46:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB8021F84C9 for ; Thu, 11 Oct 2012 22:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0Ixe4hlFurm for ; Thu, 11 Oct 2012 22:46:46 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 85DE921F84C5 for ; Thu, 11 Oct 2012 22:46:46 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j40so207987qab.10 for ; Thu, 11 Oct 2012 22:46:46 -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:x-system-of-record; bh=504oIzMdpGlkUNX/HZvgR5YbsZyo2VAc/b96+U1Bego=; b=oZvYijpGHnqU8IBpvyIa6Qute8AP2R+r+HPLqNzN4UNMqkX3iaplXmMm+GvapCYEIG V/hSNox/hkIZ6D5ByyjT1bEXVMjJ+OZ9CzePuBwDWV1Z20KAV/8WZKrN59aCwlXJp9iV YgphXfYUt5KGGMFPztqZ4Igbssx0sjq8GoJ8qVjPPRFWjVJWF/pHCVITSF847JLfJ/83 dRiRk6JlMgMBKneans03/V8E6qmJ/coVyIGMhysQqs9q8JIiZ/WozIkrdTOiBNHWbS3C btTgaQoR1X8rqxJLTV3BVncQjnYS44F8jb5tzc+pyG6nL/QZOWwhbDvzARB5JljzhJrF 6sKA== X-Google-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:x-system-of-record:x-gm-message-state; bh=504oIzMdpGlkUNX/HZvgR5YbsZyo2VAc/b96+U1Bego=; b=d9Mgny7NaD6nYrP2iCfA/eHNTCFBFJTgziadakv2hUC1tUm3QBbwjbQ1P+2GyHwxM7 +vRWta2bjsbvnwgCVno0LSakO+x29FRRlf7NYyCER1qn4LjREls7FfXGTgnjeGYvCoV1 f6M7yulDhBjSfKK6MLaAtHK75zZPAuzZFMmdOTINeTntNpCavD/KOMn+O+18trkCxhFv HN/ttvqPo6YKQOqkcAQEbH0hXL5IizBotbNxmvGtNcXqfCB3iMFn4jR5eJwPK3ORGCh+ 4xN8J3p7YOoWkHUzM7CPTPM3qUucTFvcTAXE2qzZpfYXrWqNThYZs1+p0ZsVLM8Qa0kp bmuQ== Received: by 10.49.48.43 with SMTP id i11mr2202532qen.10.1350020805900; Thu, 11 Oct 2012 22:46:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.216.194 with HTTP; Thu, 11 Oct 2012 22:46:25 -0700 (PDT) In-Reply-To: References: <7F2072F1E0DE894DA4B517B93C6A0585340A7BCEF1@ESESSCMS0356.eemea.ericsson.se> From: Justin Uberti Date: Thu, 11 Oct 2012 22:46:25 -0700 Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=047d7b6d89c2933a9b04cbd636bb X-System-Of-Record: true X-Gm-Message-State: ALoCoQl1BCCroc0EbZhPO65pM2aeM+AdxBt46QS2/trU1F0yMiVQxdUtx5nZw2gxD6IVTvz4Pu8MbchhFLG1JvNZenzSsRvOOlVnoXgZIRmLlv4XEpwSbEaROVpDzRPMv7qHGxfNESz2wZfQROgtn8ca1yGhUENpwMzczizvV49EIHchTwgAdQXOwalIUE1IqtVvy6eFeRMc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-02: SDP line X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 05:46:47 -0000 --047d7b6d89c2933a9b04cbd636bb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable "SDP line" meant, literally, each text line in the SDP. A SDP blob is composed of SDP lines. If there is better terminology to use here, please advise and we will change it. On Mon, Oct 8, 2012 at 3:51 PM, Cullen Jennings (fluffy) wrote: > > On Oct 4, 2012, at 7:33 , Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > Hi, > > > > What is a =E2=80=9DSDP line=E2=80=9D? The same thing as a =E2=80=9CSDP = blob=E2=80=9D? > > > > Regards, > > > > Christer > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > this is poorly defined and we need to fix that - it's probably the wrong > term > > I think it was trying to get at the m-line matching issues in SDP so the > term > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b6d89c2933a9b04cbd636bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable "SDP line" meant, literally, each text line in the SDP. A SDP blo= b is composed of SDP lines.

If there is better terminolo= gy to use here, please advise and we will change it.


On Mon, Oct 8, 2012 at 3:51 PM, Cullen J= ennings (fluffy) <fluffy@cisco.com> wrote:

On Oct 4, 2012, at 7:33 , Christer Holmberg <christer.holmberg@ericsson.com> wrote:

> Hi,
>
> What is a =E2=80=9DSDP line=E2=80=9D? The same thing as a =E2=80=9CSDP= blob=E2=80=9D?
>
> Regards,
>
> Christer
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

this is poorly defined and we need to fix that - it's probably the wron= g term

I think it was trying to get at the m-line matching issues in SDP so the te= rm

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

--047d7b6d89c2933a9b04cbd636bb-- From juberti@google.com Thu Oct 11 23:00:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D6421F842C for ; Thu, 11 Oct 2012 23:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwpdpK3hkah3 for ; Thu, 11 Oct 2012 23:00:05 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB1F21F844F for ; Thu, 11 Oct 2012 23:00:05 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so2307493qcg.31 for ; Thu, 11 Oct 2012 23:00:04 -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:x-system-of-record; bh=K/ldI5uX/qacjirZQFAF9336h29/kY3RKA2waYmMZtk=; b=BoDEDH93gQUUBXM7ZRjysw66lKkG7mQ0iZcD4fg/AlFEAStWjg7RDhdo5y2TPVXmuz NadLF0mVHvIbHXui1k5QdgOw4QdHJrcxj9rWugoby96QbhtKQBgYZyp7gleCwztY3L5e GDx40dFacTwR1vY/rlFoScImGGVIfEpQbje6nHbabL8BtT1N07mICi23RvXFW/Z+Idq4 wp420XAUBohfv/AeyY/JWlBtr7gvVfa7aRPe5eIYYwsd+DcCQtax9jMEWPVM+0wjPwtt 7WjRdJ53319RGqs6IhfT/MwgkyY5PBpTGVmVHKpASldM5gE+LMdhq2C67/sNNAxqXGjF mTFg== X-Google-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:x-system-of-record:x-gm-message-state; bh=K/ldI5uX/qacjirZQFAF9336h29/kY3RKA2waYmMZtk=; b=HGmCVfICcyTKzETxmuLHyuJQbRzhWLAarlI0uiv4Gxv1R5+phhK58hL1aoZ7WGYfXI RucuswKbhGI7IWTgoCEZ/G4AF4WlBLvoV2DNI3Ax08lWpP6Wck1RSXnT6WJ4H5YslNT4 0VxUgOk++RLgIhKbJUFOx4dH5lvBLnf2sPLJ/TYzJphX2DKVRL/0COCeauIW9HrmagAm nsJ+k1boCn1+XPaVR0QqrCXt43IvED4D462wPIetTlktxmU8u8PwBHfVvp0yAzdQmjtB qxbr6Ykr243a0rUPY/m9a60G7duwPjs4RtU06TCLjMzYIbYSsXtvz51CNyuoWJ2gprzI i1pQ== Received: by 10.229.198.76 with SMTP id en12mr1486838qcb.107.1350021604554; Thu, 11 Oct 2012 23:00:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.216.194 with HTTP; Thu, 11 Oct 2012 22:59:44 -0700 (PDT) In-Reply-To: References: <7F2072F1E0DE894DA4B517B93C6A0585340A7BCD49@ESESSCMS0356.eemea.ericsson.se> <506D73CF.80701@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A0585340A7BCD92@ESESSCMS0356.eemea.ericsson.se> From: Justin Uberti Date: Thu, 11 Oct 2012 22:59:44 -0700 Message-ID: To: Jim Barnett Content-Type: multipart/alternative; boundary=0016369c8d402db72e04cbd66684 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkDw6bskrR+IUKe/ehbmaWAh9OX04IIPtdXVyr3bhwNYaMiRni2K2k0DhW5S8O7dIXBKWeoKhu1qrMQpojTvdu8E4AaSUOuBQUeoTOFpHCtnB8dolmQXireRB5tKwVMyKVYxqvohUsfMV2yVlSVqFZ5MYSiQyV6LQegvO+TibtwvRKOOF/swjmZTa6B247qNAQTHfw2 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-02: Clone comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 06:00:06 -0000 --0016369c8d402db72e04cbd66684 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The preceding paragraph of 4.7.2 mentions that each clone may end up with its own peer-reflexive candidates (as would be the case if the local NAT was endpoint-dependent). So while the local addresses and server-reflexive/relay addresses should be the same, the overall set of local candidates for each clone may be different. I will try to clarify this for the next draft. On Thu, Oct 4, 2012 at 5:47 AM, Jim Barnett wro= te: > If the local address isn=E2=80=99t the same, we shouldn=E2=80=99t call it= a =E2=80=98clone=E2=80=99. I > think that people will expect everything to be the same on a =E2=80=98clo= ne=E2=80=99. *** > * > > ** ** > > **- **Jim****** > > ** ** > > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Christer Holmberg > *Sent:* Thursday, October 04, 2012 7:57 AM > *To:* Harald Alvestrand; rtcweb@ietf.org > *Subject:* Re: [rtcweb] JSEP-02: Clone comments**** > > ** ** > > Hi,**** > > **** > > >> A couple of comments on the cloning stuff in JSEP:**** > > >>** ** > > >> Q1. The document doesn=E2=80=99t say how the cloning is performed. If = that is > outside the scope of JSEP, and belongs to the W3C API spec, I think it > should be mentioned.**** > > >> **** > > >> Q2. The text in section 4.7.2 says:**** > > **>> **** > > >> =E2=80=9CAs a result of this cloning, the application w= ill end > up with N**** > > >> parallel sessions, each with a local and remote > description and their**** > > >> own local and remote addresses.=E2=80=9D**** > > =E2=89=AB**** > > >> I think the =E2=80=9Cown local addresses=E2=80=9D wording is a little = misleading, as > each clone will share the same local address.**** > > >** ** > > > Not sure what to say here.**** > > >** ** > > > I can see multiple ways to implement this - some will end up with > different local ports, some won't.**** > > **** > > Earlier in the same section, the text says:**** > > **** > > =E2=80=9CSince the *clone uses the same local description as its*= **** > > * &nb! sp; parent*, creating a clone will fail if it is not > possible to reserve**** > > the same resources for the clone as have already been reserved b= y > the**** > > parent.=E2=80=9D**** > > **** > > > If the non-local (reflexive?) candidates are allocated using STUN on a > per-port basis, addresses could be different too.**** > > **** > > My assumption, and understanding of the text, is that a clone is a=E2=80= =A6 eeeeh=E2=80=A6 > clone =E2=80=93 meaning that the local address is the same :)**** > > **** > > Regards,**** > > **** > > Christer**** > > **** > > **** > > **** > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --0016369c8d402db72e04cbd66684 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The preceding paragraph of 4.7.2 mentions that each clone may end up with i= ts own peer-reflexive candidates (as would be the case if the local NAT was= endpoint-dependent). So while the local addresses and server-reflexive/rel= ay addresses should be the same, the overall set of local candidates for ea= ch clone may be different.

I will try to clarify this for the next draft.


On Thu, Oct 4, 2012 a= t 5:47 AM, Jim Barnett <Jim.Barnett@genesyslab.com>= wrote:

If the local = address isn=E2=80=99t the same, we shouldn=E2=80=99t call it a =E2=80=98clo= ne=E2=80=99.=C2=A0 I think that people will expect everything to be the sam= e on a =E2=80=98clone=E2=80=99.=C2=A0

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Jim=

=C2=A0

From: rtcweb-bounces@ietf.o= rg [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Thursday, October 04, 2012 7:57 AM
To: Harald Alvest= rand; rtcweb@ietf.org<= /a>
Subject: Re: [rtcweb] JSEP-02: Clone comments

=C2=A0

>>=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 the same resources for the clone as have already b= een reserved by the

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 parent.=E2=80=9D<= u>

=C2=A0<= /p>

> If the non-local (reflexive= ?) candidates are allocated using STUN on a per-port basis, addresses could= be different too.

=C2=A0<= /p>

My assumption, = and understanding of the text, is that a clone is a=E2=80=A6 eeeeh=E2=80=A6= clone =E2=80=93 meaning that the local address is the same :)

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0<= /p>

=C2=A0

=C2=A0<= /p>


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


--0016369c8d402db72e04cbd66684-- From harald@alvestrand.no Fri Oct 12 02:36:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A34721F853A for ; Fri, 12 Oct 2012 02:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.239 X-Spam-Level: X-Spam-Status: No, score=-110.239 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hhCxsJkGpcw for ; Fri, 12 Oct 2012 02:36:54 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 638D221F8462 for ; Fri, 12 Oct 2012 02:36:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 71E7639E091 for ; Fri, 12 Oct 2012 11:36:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PGNR44nbVcs for ; Fri, 12 Oct 2012 11:36:52 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9563E39E062 for ; Fri, 12 Oct 2012 11:36:52 +0200 (CEST) Message-ID: <5077E4B4.3050702@alvestrand.no> Date: Fri, 12 Oct 2012 11:36:52 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <50742574.6080200@ericsson.com> In-Reply-To: <50742574.6080200@ericsson.com> X-Forwarded-Message-Id: <50742574.6080200@ericsson.com> Content-Type: multipart/alternative; boundary="------------010909010500080404050805" Subject: [rtcweb] Fwd: WG poll for consensus MSID draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 09:36:55 -0000 This is a multi-part message in MIME format. --------------010909010500080404050805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reminder: This poll in MMUSIC closes on Sunday the 14th, if I read the announcement correctly; if you want to make sure your voice is heard, speak up today. -------- Original Message -------- Subject: WG poll for consensus MSID draft Date: Tue, 9 Oct 2012 15:24:04 +0200 From: Miguel A. Garcia To: mmusic CC: Flemming Andreasen , Harald Alvestrand At the last IETF meeting we had a presentation of the following draft: http://datatracker.ietf.org/doc/draft-alvestrand-mmusic-msid/ At that time, there was interest in solving the problem of cross session stream identification. We would like to poll the working group for consensus on adopting the above mentioned draft as a working group item, once we get an approved milestone. If you support this work or have problems with the adoption of this document as WG item, please indicate it by replying to this e-mail within the next 5 days. Flemming and Miguel (co-chairs) -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain --------------010909010500080404050805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reminder: This poll in MMUSIC closes on Sunday the 14th, if I read the announcement correctly; if you want to make sure your voice is heard, speak up today.


-------- Original Message --------
Subject: WG poll for consensus MSID draft
Date: Tue, 9 Oct 2012 15:24:04 +0200
From: Miguel A. Garcia <Miguel.A.Garcia@ericsson.com>
To: mmusic <mmusic@ietf.org>
CC: Flemming Andreasen <fandreas@cisco.com>, Harald Alvestrand <harald@alvestrand.no> 


At the last IETF meeting we had a presentation of the following draft:

http://datatracker.ietf.org/doc/draft-alvestrand-mmusic-msid/

At that time, there was interest in solving the problem of cross session 
stream identification.

We would like to poll the working group for consensus on adopting the 
above mentioned draft as a working group item, once we get an approved 
milestone.

If you support this work or have problems with the adoption of this 
document as WG item, please indicate it by replying to this e-mail within 
the next 5 days.

Flemming and Miguel (co-chairs)

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain



--------------010909010500080404050805-- From fluffy@cisco.com Fri Oct 12 08:52:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2391021F86C2 for ; Fri, 12 Oct 2012 08:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.49 X-Spam-Level: X-Spam-Status: No, score=-110.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkQZ5rd3XmHR for ; Fri, 12 Oct 2012 08:52:30 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 83BDE21F86B3 for ; Fri, 12 Oct 2012 08:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=537; q=dns/txt; s=iport; t=1350057150; x=1351266750; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OtmIptDYdepVAVCojsN7ry58L6m74YalbSFbc926a6s=; b=ljH051ThIjmK3x9x0yValu6mBxWcJAxfxm/fNO9XDBLmDd5tMiDto5aD hM/3mA2S7Er8VyN3UuLZgpWU5u3Kdy+rpMpkRwwN5KG2RL80XnhXLVSoA Z/NGyVZg2TZfGbLRT8h2MOQfbQ4/sIydpprWu49A38B6OjQcCqL5Aptnn A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FAEg8eFCtJXG//2dsb2JhbABEhUu6FIEIgiABAQEDARIBJz8FCwIBCCIUECERJQIEDgUIGodQAwkGmkuWMw2JVIpsZoVdYAOUGIx4gyKBa4Jtghc X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="131009095" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 12 Oct 2012 15:52:29 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9CFqTsZ028388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Oct 2012 15:52:29 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Fri, 12 Oct 2012 10:52:28 -0500 From: "Cullen Jennings (fluffy)" To: Martin Thomson Thread-Topic: [rtcweb] Agenda requests for Atlanta meeting Thread-Index: AQHNqJGUMD0tgzZzikuiy9arqelDHQ== Date: Fri, 12 Oct 2012 15:52:28 +0000 Message-ID: References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAD087E@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19266.000 x-tm-as-result: No--30.130000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <0BFFFBE4CBD7434A94050D63058EA9E4@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 15:52:34 -0000 On Oct 9, 2012, at 4:58 PM, Martin Thomson wrote= : > Quit beating around the bush: it's me you are talking about. Sorry Martin - I did not mean exactly you. I meant, you, me, Christer, othe= rs. I think we just need to get all very pragmatic and specific about what = the code needs to do. And I don't mean to imply that you or Christer are no= t - you both are very pragmatic. But we all need to get this thread to spec= ific examples about real world use cases that people can understand. =20 From fluffy@cisco.com Fri Oct 12 08:59:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FC521F86F7 for ; Fri, 12 Oct 2012 08:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.85 X-Spam-Level: X-Spam-Status: No, score=-108.85 tagged_above=-999 required=5 tests=[AWL=-1.440, BAYES_00=-2.599, FB_NO_MORE_OFFER=3.189, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdFrSCeOVsGK for ; Fri, 12 Oct 2012 08:59:06 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3453B21F86E8 for ; Fri, 12 Oct 2012 08:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2675; q=dns/txt; s=iport; t=1350057546; x=1351267146; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qQfdQ7mwgM0JQWiu1KeOzlZllfj8KYGd8ld3Ami6CgA=; b=Jwo6rGx6ehlKgAGbGyKzSO1JZKygCb/S3XYmgpnNf8jPaOLn+5RsB/JT tEEGyuQFFSg1Hqi3XegXqDaAiHAoLv4GdcLGszaBKYdIxxU0RPRvsRNPQ 6uQ/GsYmFddEAnbbyS2l2hsOyrR94IPAWTzZ5xCQYzoQ2kJ9oKgQrK/Ao c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOI9eFCtJV2Y/2dsb2JhbABEv1+BCIIgAQEBAwESASc/BQsCAQgYChQQIRElAgQOBQgTB4dQAwkGmk2WNA2JVIpsZoVdYAOUGIx4gyKBa4Jtghc X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="131045954" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 12 Oct 2012 15:59:06 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9CFx5gf014666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Oct 2012 15:59:05 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Fri, 12 Oct 2012 10:59:05 -0500 From: "Cullen Jennings (fluffy)" To: Martin Thomson Thread-Topic: [rtcweb] Agenda requests for Atlanta meeting Thread-Index: AQHNqJKAP8TeNCVzQEOOplGvYGeDXw== Date: Fri, 12 Oct 2012 15:59:04 +0000 Message-ID: References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAD087E@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19266.000 x-tm-as-result: No--42.495500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 15:59:06 -0000 On Oct 9, 2012, at 4:58 PM, Martin Thomson wrote= : > On 9 October 2012 13:05, Cullen Jennings (fluffy) wrot= e: >> 3264, SDP, 3261, and related documents are dealing with a bunch of thing= s including what happens at media plane and signaling plane. >>=20 >> I'll note that though O/A is per dialog, there is only one O shared acro= ss multiple legs and when you create the O you don't know how many dialogs = there will be. So from the media point of view (covered more in SDP spec th= an 3264) there is one O with a bunch of A. From signaling point of view the= re are a bunch of O/A pairs). >>=20 >> The dialog is SIP signaling concept not a media plane level concept. We = moved the signaling part out of the browser and into the JS. But the media = part is still in the browser. So as 3264 says, after the offer is construct= ed, we have to be willing to receive media for all the codec type in the of= fer. When we get the answer 3264 makes it clear that one MAY stop receiving= the codecs that were in the offer but not selected in the answer. However,= this can not be done until the signaling layer is sure that no more offers= will be honored. Since that signalling part of Offer/Answer is in the JS, = the API need to to have a way to signal what the MAY part should do and tha= t is the PRANSWER vs ANSWER. >=20 > That's a consistent and logical view. It is not what RFC 3264 says. > It may even be the only reasonable solution. >=20 >> People keep trying to make this some complex weird argument invoking the= SIP deities of the past and quoting incomprehensible phrases from various = RFC caved in stone [...] >=20 > Quit beating around the bush: it's me you are talking about. >=20 > It's not a complex weird argument, it's this: > PRANSWER is not described in RFC 3264. >=20 > draft-*-jsep might say something about it, but I'd have to guess about > what to do if I were to implement the feature and that doesn't help > with interoperation. >=20 > If there was text that described the above, plus the implications in > some detail (including what resources can be released as they relate > to the SDP), then we're good. I don't even think that writing this is > especially hard.=20 Agree that text has to be a clear. But provision is a term from 3261 which = is referenced from 3264 and bunch of this also relies on SDP RFC too. Some = of the key information about it is 3262. This is all intertwined but my key= point is that I don't think we are trying to do anything that was not part= of 3264 offer / answer. This is more or less a SIP 180.=20 From fluffy@cisco.com Fri Oct 12 09:04:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C736C21F8647 for ; Fri, 12 Oct 2012 09:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.076 X-Spam-Level: X-Spam-Status: No, score=-110.076 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2dh73qhTkWo for ; Fri, 12 Oct 2012 09:04:33 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id AFD5321F8680 for ; Fri, 12 Oct 2012 09:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5731; q=dns/txt; s=iport; t=1350057873; x=1351267473; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pvDsZXIi1PutsCrGo+3clp4zWRjfLgebBEJ3f9aT3So=; b=eFqzO7msntmNwaCp8KbrCGbYFwBlGP0PsPtBtLDSerg/Y0eyiR0ShhAr DKgZavbamK/fH3bQg59dOupijGkBX0u+hC0XdE5njEjXfA3khzYdaQvpp HFenH03R2/PazX7SMWQ8RxO1yKcvXbLAoc7tzvcD9zzSMhSP7GNn18bm8 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFg/eFCtJV2Y/2dsb2JhbABEv1+BCIIgAQEBAwEBAQEPASc0CwUHBAIBCBEEAQEBChQJBycLFAkIAgQOBQgah1wGC5pFoA8Ei1KFXWADkjyRdoFrgm2BWgUENA X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="130794367" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 12 Oct 2012 16:04:33 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9CG4XuK023708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Oct 2012 16:04:33 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Fri, 12 Oct 2012 11:04:32 -0500 From: "Cullen Jennings (fluffy)" To: Parthasarathi R Thread-Topic: [rtcweb] Agenda requests for Atlanta meeting Thread-Index: AQHNqJNERbmAruLOa06QaNt9Wva3zw== Date: Fri, 12 Oct 2012 16:04:31 +0000 Message-ID: References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAD087E@ESESSCMS0356.eemea.ericsson.se> , <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6B@ESESSCMS0356.eemea.ericsson.se> <000b01cda720$bd5097a0$37f1c6e0$@co.in> In-Reply-To: <000b01cda720$bd5097a0$37f1c6e0$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19266.000 x-tm-as-result: No--65.814700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <8918DEDBB6E50D459E23A7C4883AEC6F@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 16:04:34 -0000 I fully agree this needs to work early media to PSTN via SIP. I don't see a= ny problem with doing that. I'm happy to work through detail call flows to = make sure that early media to PSTN works.=20 Update after a 180 is not allowed by the Update RFC as I pointed out in oth= er email exactly because just in SIP with no RTCP web, the UA that caret th= e invite would not have enough information to be able to process this as yo= u point in the thread below.=20 On Oct 10, 2012, at 1:51 PM, Parthasarathi R w= rote: > Cullen, >=20 > As signaling is moved to JS (application layer), Offer-answer in JSEP has= to > be generic enough. The underlying assumption in PRANSWER state is that > webserver knows whether the received SDP from remote is PRANSWER or final > ANSWER. Unfortunately, Webserver may not able to tell whether the receive= in > lot of real time deployment which is an open issue now. UPDATE offer afte= r > 18x answer from remote is the typical example where PRANSWER state breaks= . > The real-time usage of SIP UPDATE offer is to update the existing answer = in > 18x in the same dialog. Early dialog UPDATE callflow is well deployment > because of PSTN remote ringback (18x) from media server and then UPDATE w= ith > SDP to update the media information of remote endpoing and then, call > connect (200 ok) from actual endpoint. The same PSTN callflow shall be > achieved by serial forking as well. Please note that the final answer or = not > is not based on browser or originating SIP UA but it is based on the > intermediate SIP entities.=20 >=20 > From RTCWeb perspective, The new OFFER is possible to be received in brow= ser > as per RFC 3264 after the first answer is received. PRANSWER is the new > state in JSEP wherein JSEP is the extension of RFC 3264. It will be good = in > case you explain how browser in PRANSWER has to handle new OFFER from the > remote side.=20 >=20 > Please include me in case any phone discussion if you are planning. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of > Cullen Jennings (fluffy) > Sent: Wednesday, October 10, 2012 1:35 AM > To: Christer Holmberg > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Agenda requests for Atlanta meeting >=20 >=20 > On Oct 9, 2012, at 12:04 , Christer Holmberg > > wrote: >=20 >> Hi, >>=20 >>>> I have not seen any reason to relax 3264 yet but if something comes up= , > agree we should carefully look at the cases. I think we can just do strai= ght > up 3264. >>>=20 >>> RFC 3264 doesn't describe PRANSWER. The concept is entirely absent. >>>=20 >>> The offerer MAY immediately cease listening for media formats that >>> were listed in the initial offer, but not present in the answer. >>>=20 >>> "the" answer. >>=20 >> I agree with Martin. 3264 O/A is always per dialog, and forking is > supported by generating multiple dialogs. JSEP, OTOH, in order to support > forking with a single "dialog" (peerConnection local descriptor), now > defines O/A as offer+any number of pranswers + answer. >>=20 >> So, we would e.g. have to define what happens if a new offer is received > from the remote side while the browser is in pranswer-received state (see= my > call flow in another reply). >=20 >=20 > 3264, SDP, 3261, and related documents are dealing with a bunch of things > including what happens at media plane and signaling plane.=20 >=20 > I'll note that though O/A is per dialog, there is only one O shared acros= s > multiple legs and when you create the O you don't know how many dialogs > there will be. So from the media point of view (covered more in SDP spec > than 3264) there is one O with a bunch of A. From signaling point of view > there are a bunch of O/A pairs).=20 >=20 > The dialog is SIP signaling concept not a media plane level concept. We > moved the signaling part out of the browser and into the JS. But the medi= a > part is still in the browser. So as 3264 says, after the offer is > constructed, we have to be willing to receive media for all the codec typ= e > in the offer. When we get the answer 3264 makes it clear that one MAY sto= p > receiving the codecs that were in the offer but not selected in the answe= r. > However, this can not be done until the signaling layer is sure that no m= ore > offers will be honored. Since that signalling part of Offer/Answer is in = the > JS, the API need to to have a way to signal what the MAY part should do a= nd > that is the PRANSWER vs ANSWER.=20 >=20 > People keep trying to make this some complex weird argument invoking the = SIP > deities of the past and quoting incomprehensible phrases from various RFC > caved in stone but the bottom line in the code is very simple to understa= nd. > When creating the offer you alloced some resources ( like a port to recei= ve > video on ). When you get an answer that does not use that resource, you n= eed > to tell the media stack if it should free the resources or not. O/A has > situation where you need to keep the resources available (like there are > more dialogs coming) and situation where you need to free the resource. > Since we split the signalling out of the browser and left the media in th= e > browser, we need be able to allow the JS that is dealing with signaling t= o > tell the browser when to free the resource.=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From christer.holmberg@ericsson.com Fri Oct 12 10:42:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4C221F8711 for ; Fri, 12 Oct 2012 10:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.119 X-Spam-Level: X-Spam-Status: No, score=-6.119 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwT-OUfPFZse for ; Fri, 12 Oct 2012 10:42:55 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4771721F86C1 for ; Fri, 12 Oct 2012 10:42:55 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-48-5078569d16c5 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 31.AB.11467.D9658705; Fri, 12 Oct 2012 19:42:54 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Fri, 12 Oct 2012 19:42:54 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" , Martin Thomson Date: Fri, 12 Oct 2012 19:41:29 +0200 Thread-Topic: [rtcweb] Agenda requests for Atlanta meeting Thread-Index: AQHNqJGUMD0tgzZzikuiy9arqelDHZe18Hvh Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA85@ESESSCMS0356.eemea.ericsson.se> References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAD087E@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6B@ESESSCMS0356.eemea.ericsson.se> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvre68sIoAg5UfeC06JrNZXDvzj9Fi 7b92dgdmjym/N7J67Jx1l91jyZKfTAHMUVw2Kak5mWWpRfp2CVwZDV9esBS0sldcX5fSwHiF tYuRk0NCwETi0PG7jBC2mMSFe+vZuhi5OIQETjFK7JnbxgrhzGWUuPF5FksXIwcHm4CFRPc/ bZAGEYE4if4Nb5hAbGYBdYk7i8+xg9gsAqoSuy6sYQGxhQUsJRZt3s8GUW8lsebWdWYI20ji +r/nYL28AuESK780Qi3+wCpxYNEPsASngK/ExBm7wZoZga77fmoN1DJxiVtP5jNBXC0gsWTP eWYIW1Ti5eN/rBD1ohJ32tczQtTrSCzY/YkNwtaWWLbwNTPEYkGJkzOfsExgFJuFZOwsJC2z kLTMQtKygJFlFaNwbmJmTnq5oV5qUWZycXF+nl5x6iZGYDQd3PJbdwfjqXMihxilOViUxHm5 kvb7CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBsdp225P0qzxulHJIbl3/VeD3zzNvD6Y9W W8run7bjcY7CdRv2JD/pAx9Z0pjdFXzk1Saf4pk0YWptoeWXWIatczQXFjOEu0rFHGt0MWsV U45ozi1M2brB59sq/TW6sftXzWdfELYgdteNJMMdYvqmCSnmhTmFtbGfWcX5kh5fmvrPc4PW vRIlluKMREMt5qLiRACvQA6DdAIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 17:42:56 -0000 Cullen,=20 I did send a real world call flow example, which you haven't commented :) Regards, Christer ________________________________________ From: Cullen Jennings (fluffy) [fluffy@cisco.com] Sent: Friday, October 12, 2012 6:52 PM To: Martin Thomson Cc: Christer Holmberg; rtcweb@ietf.org Subject: Re: [rtcweb] Agenda requests for Atlanta meeting On Oct 9, 2012, at 4:58 PM, Martin Thomson wrote= : > Quit beating around the bush: it's me you are talking about. Sorry Martin - I did not mean exactly you. I meant, you, me, Christer, othe= rs. I think we just need to get all very pragmatic and specific about what = the code needs to do. And I don't mean to imply that you or Christer are no= t - you both are very pragmatic. But we all need to get this thread to spec= ific examples about real world use cases that people can understand.= From christer.holmberg@ericsson.com Fri Oct 12 10:45:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB31E21F86C5 for ; Fri, 12 Oct 2012 10:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.82 X-Spam-Level: X-Spam-Status: No, score=-5.82 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1f6AbpPflhXe for ; Fri, 12 Oct 2012 10:45:19 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3948121F86C1 for ; Fri, 12 Oct 2012 10:45:19 -0700 (PDT) X-AuditID: c1b4fb25-b7f956d0000011c3-81-5078572d117e Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 87.01.04547.D2758705; Fri, 12 Oct 2012 19:45:18 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Fri, 12 Oct 2012 19:45:18 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" , Parthasarathi R Date: Fri, 12 Oct 2012 19:43:24 +0200 Thread-Topic: [rtcweb] Agenda requests for Atlanta meeting Thread-Index: AQHNqJNERbmAruLOa06QaNt9Wva3z5e18QE3 Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA86@ESESSCMS0356.eemea.ericsson.se> References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAD087E@ESESSCMS0356.eemea.ericsson.se> , <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6B@ESESSCMS0356.eemea.ericsson.se> <000b01cda720$bd5097a0$37f1c6e0$@co.in>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvra5eeEWAweNOHouOyWwWkz/1sVqs /dfO7sDsMeX3RlaPJUt+Mnl8mP+FPYA5issmJTUnsyy1SN8ugSvj2stJLAWLdCvWztvK0sB4 QrmLkZNDQsBEou/EQ1YIW0ziwr31bF2MXBxCAqcYJVYe2s8O4cxllJi77TNQFQcHm4CFRPc/ bZAGEYFEiY6PX5hBbGYBTYkJy3axgdgsAqoSrzY9AosLC1hKLNq8nw2i3kpiza3rzBC2kcTD /sdMIDavQLjE89d3mCF2XWGV6J65DqyBU8BXYs7RO2A2I9B130+tYYJYJi5x68l8JoirBSSW 7DnPDGGLSrx8/I8Vol5U4k77ekaIeh2JBbs/sUHY2hLLFr5mhlgsKHFy5hOWCYxis5CMnYWk ZRaSlllIWhYwsqxiFM5NzMxJLzfSSy3KTC4uzs/TK07dxAiMp4NbfqvuYLxzTuQQozQHi5I4 r/XWPf5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGNcvm/fKoHTrxb2yEsuPqXW9n5Vgdmdu 7z3N6Ue1jF+VpZ76lrz4L+9RkcM7FlaZ9G39fcRdxWP7rwrL3CNC0zbo8ZjM2Zfx5kf+gZ/T O4Nmf15y2mfW33KFp03/Fepvb7UznXJ+4YL8LaZzF731Zvd15HpUNzUrZ6rG67Dtu/gmTlHl PyHPovdHiaU4I9FQi7moOBEAB3v/gHUCAAA= Cc: "" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 17:45:20 -0000 Hi, > I fully agree this needs to work early media to PSTN via SIP. I don't see= any problem with doing that. I'm happy to work through detail call flows t= o make sure that early media to PSTN works. > > Update after a 180 is not allowed by the Update RFC as I pointed out in o= ther email exactly because just in SIP with no RTCP web, the UA that caret = the invite would not have enough information to be able to process this as = you point in the thread below. As far as I know, UPDATE is allowed after a reliable 180. If you don't agre= e, please show me the text which forbids it :) Regards, Christer On Oct 10, 2012, at 1:51 PM, Parthasarathi R w= rote: > Cullen, > > As signaling is moved to JS (application layer), Offer-answer in JSEP has= to > be generic enough. The underlying assumption in PRANSWER state is that > webserver knows whether the received SDP from remote is PRANSWER or final > ANSWER. Unfortunately, Webserver may not able to tell whether the receive= in > lot of real time deployment which is an open issue now. UPDATE offer afte= r > 18x answer from remote is the typical example where PRANSWER state breaks= . > The real-time usage of SIP UPDATE offer is to update the existing answer = in > 18x in the same dialog. Early dialog UPDATE callflow is well deployment > because of PSTN remote ringback (18x) from media server and then UPDATE w= ith > SDP to update the media information of remote endpoing and then, call > connect (200 ok) from actual endpoint. The same PSTN callflow shall be > achieved by serial forking as well. Please note that the final answer or = not > is not based on browser or originating SIP UA but it is based on the > intermediate SIP entities. > > From RTCWeb perspective, The new OFFER is possible to be received in brow= ser > as per RFC 3264 after the first answer is received. PRANSWER is the new > state in JSEP wherein JSEP is the extension of RFC 3264. It will be good = in > case you explain how browser in PRANSWER has to handle new OFFER from the > remote side. > > Please include me in case any phone discussion if you are planning. > > Thanks > Partha > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of > Cullen Jennings (fluffy) > Sent: Wednesday, October 10, 2012 1:35 AM > To: Christer Holmberg > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Agenda requests for Atlanta meeting > > > On Oct 9, 2012, at 12:04 , Christer Holmberg > > wrote: > >> Hi, >> >>>> I have not seen any reason to relax 3264 yet but if something comes up= , > agree we should carefully look at the cases. I think we can just do strai= ght > up 3264. >>> >>> RFC 3264 doesn't describe PRANSWER. The concept is entirely absent. >>> >>> The offerer MAY immediately cease listening for media formats that >>> were listed in the initial offer, but not present in the answer. >>> >>> "the" answer. >> >> I agree with Martin. 3264 O/A is always per dialog, and forking is > supported by generating multiple dialogs. JSEP, OTOH, in order to support > forking with a single "dialog" (peerConnection local descriptor), now > defines O/A as offer+any number of pranswers + answer. >> >> So, we would e.g. have to define what happens if a new offer is received > from the remote side while the browser is in pranswer-received state (see= my > call flow in another reply). > > > 3264, SDP, 3261, and related documents are dealing with a bunch of things > including what happens at media plane and signaling plane. > > I'll note that though O/A is per dialog, there is only one O shared acros= s > multiple legs and when you create the O you don't know how many dialogs > there will be. So from the media point of view (covered more in SDP spec > than 3264) there is one O with a bunch of A. From signaling point of view > there are a bunch of O/A pairs). > > The dialog is SIP signaling concept not a media plane level concept. We > moved the signaling part out of the browser and into the JS. But the medi= a > part is still in the browser. So as 3264 says, after the offer is > constructed, we have to be willing to receive media for all the codec typ= e > in the offer. When we get the answer 3264 makes it clear that one MAY sto= p > receiving the codecs that were in the offer but not selected in the answe= r. > However, this can not be done until the signaling layer is sure that no m= ore > offers will be honored. Since that signalling part of Offer/Answer is in = the > JS, the API need to to have a way to signal what the MAY part should do a= nd > that is the PRANSWER vs ANSWER. > > People keep trying to make this some complex weird argument invoking the = SIP > deities of the past and quoting incomprehensible phrases from various RFC > caved in stone but the bottom line in the code is very simple to understa= nd. > When creating the offer you alloced some resources ( like a port to recei= ve > video on ). When you get an answer that does not use that resource, you n= eed > to tell the media stack if it should free the resources or not. O/A has > situation where you need to keep the resources available (like there are > more dialogs coming) and situation where you need to free the resource. > Since we split the signalling out of the browser and left the media in th= e > browser, we need be able to allow the JS that is dealing with signaling t= o > tell the browser when to free the resource. > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >= From jmpolk@cisco.com Fri Oct 12 12:21:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316AB21F86DD for ; Fri, 12 Oct 2012 12:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRF2S07U8Qo2 for ; Fri, 12 Oct 2012 12:21:17 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 14CD421F86E2 for ; Fri, 12 Oct 2012 12:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6407; q=dns/txt; s=iport; t=1350069677; x=1351279277; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=fOYIx6AX3ssGk39yXsqV+I89rLGcXDUEOt9kvc34e80=; b=YG+W2G7PD7eHvlBQ8lt8/GUlMjKI2Pkf6gWUEJdDpeQP2ri4v2g5JkFX 5qSq5h2P3afo+oRohc1DimXxOLo6/Supdu/CRC1u3dqsTPJDEoOB9KVls mHpW3694yFDkx6s+pNnlJOcMdluE8yHihzMtx6kiM98TsxeM/SGiSq4Sx I=; X-IronPort-AV: E=Sophos;i="4.80,577,1344211200"; d="scan'208";a="130864140" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 12 Oct 2012 19:21:16 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) (authenticated bits=0) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9CJLGse016666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Oct 2012 19:21:16 GMT Message-Id: <201210121921.q9CJLGse016666@rcdn-core2-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Oct 2012 14:21:14 -0500 To: Christer Holmberg , "Cullen Jennings (fluffy)" , Parthasarathi R From: James Polk In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA86@ESESSCMS0356.ee mea.ericsson.se> References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAD087E@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6B@ESESSCMS0356.eemea.ericsson.se> <000b01cda720$bd5097a0$37f1c6e0$@co.in> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA86@ESESSCMS0356.eemea.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Cc: "" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 19:21:19 -0000 At 12:43 PM 10/12/2012, Christer Holmberg wrote: >Hi, > > > I fully agree this needs to work early media to PSTN via SIP. I > don't see any problem with doing that. I'm happy to work through > detail call flows to make sure that early media to PSTN works. > > > > Update after a 180 is not allowed by the Update RFC as I pointed > out in other email exactly because just in SIP with no RTCP web, > the UA that caret the invite would not have enough information to > be able to process this as you point in the thread below. > >As far as I know, UPDATE is allowed after a reliable 180. If you >don't agree, please show me the text which forbids it :) UPDATE is allowed after a before and after a 180, and allowed after a 200 OK to the INVITE. RFC 6442 (Geolocation Header) took advantage of this function through/with/by/whatever the blessing of Jonathan R. James >Regards, > >Christer > > > >On Oct 10, 2012, at 1:51 PM, Parthasarathi R > wrote: > > > Cullen, > > > > As signaling is moved to JS (application layer), Offer-answer in > JSEP has to > > be generic enough. The underlying assumption in PRANSWER state is that > > webserver knows whether the received SDP from remote is PRANSWER or final > > ANSWER. Unfortunately, Webserver may not able to tell whether the > receive in > > lot of real time deployment which is an open issue now. UPDATE offer after > > 18x answer from remote is the typical example where PRANSWER state breaks. > > The real-time usage of SIP UPDATE offer is to update the existing answer in > > 18x in the same dialog. Early dialog UPDATE callflow is well deployment > > because of PSTN remote ringback (18x) from media server and then > UPDATE with > > SDP to update the media information of remote endpoing and then, call > > connect (200 ok) from actual endpoint. The same PSTN callflow shall be > > achieved by serial forking as well. Please note that the final > answer or not > > is not based on browser or originating SIP UA but it is based on the > > intermediate SIP entities. > > > > From RTCWeb perspective, The new OFFER is possible to be received > in browser > > as per RFC 3264 after the first answer is received. PRANSWER is the new > > state in JSEP wherein JSEP is the extension of RFC 3264. It will be good in > > case you explain how browser in PRANSWER has to handle new OFFER from the > > remote side. > > > > Please include me in case any phone discussion if you are planning. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of > > Cullen Jennings (fluffy) > > Sent: Wednesday, October 10, 2012 1:35 AM > > To: Christer Holmberg > > Cc: rtcweb@ietf.org > > Subject: Re: [rtcweb] Agenda requests for Atlanta meeting > > > > > > On Oct 9, 2012, at 12:04 , Christer Holmberg > > > > wrote: > > > >> Hi, > >> > >>>> I have not seen any reason to relax 3264 yet but if something comes up, > > agree we should carefully look at the cases. I think we can just > do straight > > up 3264. > >>> > >>> RFC 3264 doesn't describe PRANSWER. The concept is entirely absent. > >>> > >>> The offerer MAY immediately cease listening for media formats that > >>> were listed in the initial offer, but not present in the answer. > >>> > >>> "the" answer. > >> > >> I agree with Martin. 3264 O/A is always per dialog, and forking is > > supported by generating multiple dialogs. JSEP, OTOH, in order to support > > forking with a single "dialog" (peerConnection local descriptor), now > > defines O/A as offer+any number of pranswers + answer. > >> > >> So, we would e.g. have to define what happens if a new offer is received > > from the remote side while the browser is in pranswer-received > state (see my > > call flow in another reply). > > > > > > 3264, SDP, 3261, and related documents are dealing with a bunch of things > > including what happens at media plane and signaling plane. > > > > I'll note that though O/A is per dialog, there is only one O shared across > > multiple legs and when you create the O you don't know how many dialogs > > there will be. So from the media point of view (covered more in SDP spec > > than 3264) there is one O with a bunch of A. From signaling point of view > > there are a bunch of O/A pairs). > > > > The dialog is SIP signaling concept not a media plane level concept. We > > moved the signaling part out of the browser and into the JS. But the media > > part is still in the browser. So as 3264 says, after the offer is > > constructed, we have to be willing to receive media for all the codec type > > in the offer. When we get the answer 3264 makes it clear that one MAY stop > > receiving the codecs that were in the offer but not selected in the answer. > > However, this can not be done until the signaling layer is sure > that no more > > offers will be honored. Since that signalling part of > Offer/Answer is in the > > JS, the API need to to have a way to signal what the MAY part should do and > > that is the PRANSWER vs ANSWER. > > > > People keep trying to make this some complex weird argument > invoking the SIP > > deities of the past and quoting incomprehensible phrases from various RFC > > caved in stone but the bottom line in the code is very simple to > understand. > > When creating the offer you alloced some resources ( like a port to receive > > video on ). When you get an answer that does not use that > resource, you need > > to tell the media stack if it should free the resources or not. O/A has > > situation where you need to keep the resources available (like there are > > more dialogs coming) and situation where you need to free the resource. > > Since we split the signalling out of the browser and left the media in the > > browser, we need be able to allow the JS that is dealing with signaling to > > tell the browser when to free the resource. > > > > > > > > > > > > > > _______________________________________________ > > 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 fluffy@cisco.com Fri Oct 12 19:21:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A69D21F867A for ; Fri, 12 Oct 2012 19:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.495 X-Spam-Level: X-Spam-Status: No, score=-110.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02gXB4Rg3Br3 for ; Fri, 12 Oct 2012 19:21:47 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD4621F8532 for ; Fri, 12 Oct 2012 19:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=785; q=dns/txt; s=iport; t=1350094907; x=1351304507; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2RsIxsuuQdRxH2dKmkzXgd6k9l0hTrmWUj8G/MqvO0M=; b=RvIxvjXya6xrsE/jxNo49Xzq+vKfxVPKgT9AwhM3F9g4KOz+QqrjYHgr 6SzgPgbF5jtvX+7TTMfHAksOub7iABFM2MNRxoeTAA0KO2CZnse/SpNgw 9+/uDytDzbs9wx77qDYkPalQGCmq3+fybcfIIBKvooRNvJPRzoELJsnrf g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUFADHPeFCtJXG//2dsb2JhbABFhUu6JIEIgiABAQEDARIBJz8FCwIBCCIUEDIlAgQOBQgah1wGm1mfaYtShV1gA6QygWuCbYFjNA X-IronPort-AV: E=Sophos;i="4.80,580,1344211200"; d="scan'208";a="131167171" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 13 Oct 2012 02:21:47 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9D2LkGp032372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 13 Oct 2012 02:21:46 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Fri, 12 Oct 2012 21:21:46 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [rtcweb] Agenda requests for Atlanta meeting Thread-Index: AQHNqOl+kDeDfA5eqEW9OAbsBiOagg== Date: Sat, 13 Oct 2012 02:21:46 +0000 Message-ID: References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAD087E@ESESSCMS0356.eemea.ericsson.se> , <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6B@ESESSCMS0356.eemea.ericsson.se> <000b01cda720$bd5097a0$37f1c6e0$@co.in>, <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA86@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA86@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19266.000 x-tm-as-result: No--39.574200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <5604F12821B751498B13020BF5768590@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 02:21:48 -0000 On Oct 12, 2012, at 11:43 AM, Christer Holmberg wrote: > Hi, >=20 >> I fully agree this needs to work early media to PSTN via SIP. I don't se= e any problem with doing that. I'm happy to work through detail call flows = to make sure that early media to PSTN works. >>=20 >> Update after a 180 is not allowed by the Update RFC as I pointed out in = other email exactly because just in SIP with no RTCP web, the UA that caret= the invite would not have enough information to be able to process this as= you point in the thread below. >=20 > As far as I know, UPDATE is allowed after a reliable 180. If you don't ag= ree, please show me the text which forbids it :) >=20 > Regards, I agree - but it's not ok after a normal 180 From fluffy@cisco.com Fri Oct 12 19:24:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D933021F86C1 for ; Fri, 12 Oct 2012 19:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+WPBTiRpBch for ; Fri, 12 Oct 2012 19:24:27 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id EF97B21F86AD for ; Fri, 12 Oct 2012 19:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3857; q=dns/txt; s=iport; t=1350095067; x=1351304667; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NmnzR2zKlyeLxYccDZPyzDmy5OHBmngAknFAmghB9dc=; b=jEhljn/0o19lAIQ+W5GZtjoCQxr8AMQVZFjowUhmlrMwT9OeL9QKgqQr hW9xva/vcRfpVobXY6/t/Ey0mcKRv3QK3VkWTEc4OVug1UsfctQ1sSqgo 0X2BeNjqyUhTCGPWaDxbu73I06+ugo7KuoTBiB8HGQ/vDfvqjmHoK/O2D U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHHQeFCtJV2Z/2dsb2JhbABFv2+BCIIgAQEBAwESARRSBQsCAQgiJDIlAgQOBQgah1wGm1ifaYtShV1gA4gjnA+Ba4Jtghc X-IronPort-AV: E=Sophos;i="4.80,580,1344211200"; d="scan'208";a="128166968" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 13 Oct 2012 02:24:26 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9D2OQmD020713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 13 Oct 2012 02:24:26 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Fri, 12 Oct 2012 21:24:25 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [rtcweb] PRANSWER is unusable for serial forking Thread-Index: AQHNqOnc3QfmtiokskqSBC02DG7ABw== Date: Sat, 13 Oct 2012 02:24:25 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A0585340BAD087C@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAD087C@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19266.000 x-tm-as-result: No--41.265700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <40517851574AF74F905E5655E709918A@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] PRANSWER is unusable for serial forking X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 02:24:28 -0000 On Oct 9, 2012, at 12:40 AM, Christer Holmberg wrote: > Hi, >=20 > I THINK Roman is talking about the following flow: >=20 >=20 > BROWSER JS APP FORKING PROXY SIP UA 1 SIP UA 2 >=20 > ------- OFFER ---------------> > ----- INVITE (OFFER 1) -= --------> > ----- INVITE (OFFER 1) ---------> > ----- INVITE (OFFER 1) -------------------------------------------= ---------> > <----180 (ANSWER 1a) ---------- > <----180 (ANSWER 1a) ---------- > <----PRANSWER ----------- > <----UPDATE (OFFER 2) -------- > <----UPDATE (OFFER 2) --------- > <----???? -------------------- > <----200 (ANSWER 1b) ---------------------------------------------= --------- > <----200 (ANSWER 1b) ---------- > <----ANSWER --------------- >=20 >=20 That's not a call flow that is legal for use of update. From section 5.1 of= of RFC 3311 has=20 o If the UPDATE is being sent before completion of the initial INVITE transaction, and the initial INVITE contained an offer, the UPDATE can contain an offer if the callee generated an answer in a reliable provisional response, and the caller has received answers to any other offers it sent in either PRACK or UPDATE, and has generated answers for any offers it received in an UPDATE from the callee. If the answer from UA1 is going to do updates before the invite transaction= complete, it needs to do that with 100rel / PRACK. Note the diagram should= also show an the 200 response to the update is going to cary an answer. So if you made all these changes, lets talk about how you would solve this = problem in the JS App.=20 Fundamentally what is happening here is the call signaling is setting up tw= o session - this is parallel media forking and parallel signaling forking. = One fork to UA1, and one to UA2. The JS App needs to pick which one it is g= oing to choose to have a media session with. Let's say it choose UA1, then = it would map the Answer 1a to an Answer, the Offer2 to an offer. If it was = going to choose UA2, it would not pass the answer down to the browser at al= l and would instead wait till it Answer 1b and pass that down. If you think= it should simultaneously have a media session with both UA1 and UA2, then = things are more complicated. I realize that at the time it gets ANSWER 1a, = it does not know it will later get ANSWR 1b so that make it hard to choose = UA2.=20 Parallel forking with early media and secure media is a hard problem in SIP= as we know from the HERFP discussion. I'm unaware of real world problem th= at are solved well with SIP and require parallel forking and thus my focus = has been on making sure we solve serial forking. I'm perfectly happy if we = *also* solve parallel forking but I don't care too much as long a early med= ia serial forking scenarios work because theses do happen all the time. I'm= pretty skeptical that are a lot of existing SIP phones that deal well with= simultaneously receiving and sending media to two other UAs in a scenario = like this (I'm trying to separate this from conferencing - I know lots of S= IP UA do 3 way calling and conferencing just fine).=20 If you want to do both, one way might be to create a new peer connection fo= r the 2nd call, and map it to and IVNTE with replaces, or send a SIP refer = to get the second session mapped to the new PeerConnection object. One coul= d also try and work on some thing that allows one PeerConenction to clone t= o two places but that's going to be a bunch of work to figure out - and aga= in, perfectly happy if someone goes and does that but it's a hard problem w= hen you have resource allocations.=20 From christer.holmberg@ericsson.com Sat Oct 13 00:22:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814CA21F8681 for ; Sat, 13 Oct 2012 00:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.122 X-Spam-Level: X-Spam-Status: No, score=-6.122 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQKvAUD1U+9o for ; Sat, 13 Oct 2012 00:22:45 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 376ED21F8683 for ; Sat, 13 Oct 2012 00:22:45 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-96-507916c3de64 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 2C.A0.11467.3C619705; Sat, 13 Oct 2012 09:22:43 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Sat, 13 Oct 2012 09:22:43 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" Date: Sat, 13 Oct 2012 09:21:30 +0200 Thread-Topic: [rtcweb] PRANSWER is unusable for serial forking Thread-Index: AQHNqOnc3QfmtiokskqSBC02DG7AB5e21Ob3 Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA8C@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340BAD087C@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvre5hscoAg6mT5Sw6JrNZfFj/g9Fi xoWpzBZr/7WzO7B4TPm9kdVjyZKfTB6Xz39k9Lg1pSCAJYrLJiU1J7MstUjfLoEro+X2AcaC hSoVM2ZPYGpgvCLZxcjJISFgIvFm7wt2CFtM4sK99WxdjFwcQgKnGCW235nHDOEsZJT4tuQW UxcjBwebgIVE9z9tkAYRAUOJpj3zmEBsZoFciQe714INYhFQlTg47wcriC0sYCvR+HYGE0S9 ncSED/vYIWwjiRPfvjKD2LwC4RLvfu9kgth1n1Hi6r0OsGZOAV+J1+ungxUxAl33/dQaqGXi EreezGeCuFpAYsme88wQtqjEy8f/WCHqRSXutK9nhKjXkViw+xMbhK0tsWzha6jFghInZz5h mcAoNgvJ2FlIWmYhaZmFpGUBI8sqRuHcxMyc9HJDvdSizOTi4vw8veLUTYzACDu45bfuDsZT 50QOMUpzsCiJ83Il7fcXEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwCgsvHSvk/CJBEWNSVyx k3VVzl6OCLLm15n7d8K1f5c3rmKM57h0wtXnR+P3gjlqKRetUv38mItjxF+stvvusTF+i9Sn NlW5edoyPkJ8J2MDX2twOp0pinG5OLm/1/PxU+/FxxQ/HN+wv//2CdbbIgtXBTce61X7uTGo +5L3R9/O4xekZrmwuimxFGckGmoxFxUnAgAmyUTmfgIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] PRANSWER is unusable for serial forking X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 07:22:46 -0000 Hi Cullen, I'll read your reply more in detail later, but please note that I assume th= at the 180 is sent *reliably* (I left the PRACK out). Regards, Christer ________________________________________ From: Cullen Jennings (fluffy) [fluffy@cisco.com] Sent: Saturday, October 13, 2012 5:24 AM To: Christer Holmberg Cc: Roman Shpount; Cullen Jennings; rtcweb@ietf.org Subject: Re: [rtcweb] PRANSWER is unusable for serial forking On Oct 9, 2012, at 12:40 AM, Christer Holmberg wrote: > Hi, > > I THINK Roman is talking about the following flow: > > > BROWSER JS APP FORKING PROXY = SIP UA 1 SIP UA 2 > > ------- OFFER ---------------> > ----- INVITE (OFFER 1) -= --------> > ----- INVITE (OFFER= 1) ---------> > ----- INVITE (OFFER= 1) ----------------------------------------------------> > <----180 (ANSWER 1a= ) ---------- > <----180 (ANSWER 1a) ---------- > <----PRANSWER ----------- > <----UPDATE (OFFER = 2) -------- > <----UPDATE (OFFER 2) --------- > <----???? -------------------- > <----200 (ANSWER 1b= ) ------------------------------------------------------ > <----200 (ANSWER 1b) ---------- > <----ANSWER --------------- > > That's not a call flow that is legal for use of update. From section 5.1 of= of RFC 3311 has o If the UPDATE is being sent before completion of the initial INVITE transaction, and the initial INVITE contained an offer, the UPDATE can contain an offer if the callee generated an answer in a reliable provisional response, and the caller has received answers to any other offers it sent in either PRACK or UPDATE, and has generated answers for any offers it received in an UPDATE from the callee. If the answer from UA1 is going to do updates before the invite transaction= complete, it needs to do that with 100rel / PRACK. Note the diagram should= also show an the 200 response to the update is going to cary an answer. So if you made all these changes, lets talk about how you would solve this = problem in the JS App. Fundamentally what is happening here is the call signaling is setting up tw= o session - this is parallel media forking and parallel signaling forking. = One fork to UA1, and one to UA2. The JS App needs to pick which one it is g= oing to choose to have a media session with. Let's say it choose UA1, then = it would map the Answer 1a to an Answer, the Offer2 to an offer. If it was = going to choose UA2, it would not pass the answer down to the browser at al= l and would instead wait till it Answer 1b and pass that down. If you think= it should simultaneously have a media session with both UA1 and UA2, then = things are more complicated. I realize that at the time it gets ANSWER 1a, = it does not know it will later get ANSWR 1b so that make it hard to choose = UA2. Parallel forking with early media and secure media is a hard problem in SIP= as we know from the HERFP discussion. I'm unaware of real world problem th= at are solved well with SIP and require parallel forking and thus my focus = has been on making sure we solve serial forking. I'm perfectly happy if we = *also* solve parallel forking but I don't care too much as long a early med= ia serial forking scenarios work because theses do happen all the time. I'm= pretty skeptical that are a lot of existing SIP phones that deal well with= simultaneously receiving and sending media to two other UAs in a scenario = like this (I'm trying to separate this from conferencing - I know lots of S= IP UA do 3 way calling and conferencing just fine). If you want to do both, one way might be to create a new peer connection fo= r the 2nd call, and map it to and IVNTE with replaces, or send a SIP refer = to get the second session mapped to the new PeerConnection object. One coul= d also try and work on some thing that allows one PeerConenction to clone t= o two places but that's going to be a bunch of work to figure out - and aga= in, perfectly happy if someone goes and does that but it's a hard problem w= hen you have resource allocations.= From christer.holmberg@ericsson.com Sat Oct 13 02:51:07 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0DF21F8513 for ; Sat, 13 Oct 2012 02:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.123 X-Spam-Level: X-Spam-Status: No, score=-6.123 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJUbf-v5N1cK for ; Sat, 13 Oct 2012 02:51:06 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3D44921F843E for ; Sat, 13 Oct 2012 02:51:05 -0700 (PDT) X-AuditID: c1b4fb25-b7f956d0000011c3-7b-50793985c71a Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E5.7D.04547.58939705; Sat, 13 Oct 2012 11:51:01 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Sat, 13 Oct 2012 11:51:01 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" Date: Sat, 13 Oct 2012 11:51:00 +0200 Thread-Topic: [rtcweb] PRANSWER is unusable for serial forking Thread-Index: AQHNqOnc3QfmtiokskqSBC02DG7AB5e27xpu Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA90@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340BAD087C@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+JvrW6rZWWAwfp3shYdk9ksPqz/wWgx 48JUZou1/9rZHVg8pvzeyOqxZMlPJo/L5z8yetyaUhDAEsVlk5Kak1mWWqRvl8CV8WL2E7aC HpWKOZuusDYwTpPsYuTkkBAwkfjRf4cNwhaTuHBvPZDNxSEkcIpR4su9ScwQzkJGiW03HgA5 HBxsAhYS3f+0QRpEBAwlmvbMYwKxmQVyJR7sXssOYrMIqEp83nqUFcQWFrCVaHw7gwmi3k5i wod97CBjRASMJC5vygUJ8wqESzStnwK16j6jxNV7HWC9nAK+Eq/XT2cGsRmBjvt+ag3ULnGJ W0/mM0EcLSCxZM95ZghbVOLl43+sEPWiEnfa1zNC1OtILNj9iQ3C1pZYtvA1M8RiQYmTM5+w TGAUm4Vk7CwkLbOQtMxC0rKAkWUVo3BuYmZOermRXmpRZnJxcX6eXnHqJkZgfB3c8lt1B+Od cyKHGKU5WJTEea237vEXEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwMgcxHlLPvZ59rv196bs +MwynTeY06ln1parnGZntzGV/A23PP25m3Mfe2jY+voA3n+PPu8S2qG8h79Nc92N/TcZ1Hq3 2u1es69v0kEGxuO7nOxY+5rbTssdXFLQmd78c1vwr8J31578yNnmwHAq4MSKsAIvHkabFVz/ 3xi1tugcmrz6+YvPVycqsRRnJBpqMRcVJwIAhfAD2n0CAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] PRANSWER is unusable for serial forking X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 09:51:07 -0000 Hi Cullen, >> I THINK Roman is talking about the following flow: >> >> >> BROWSER JS APP FORKING PROXY = SIP UA 1 SIP UA 2 >> >> ------- OFFER ---------------> >> ----- INVITE (OFFER 1) = ---------> >> ----- INVITE (OFFE= R 1) ---------> >> ----- INVITE (OFFE= R 1) ----------------------------------------------------> >> <----180 (ANSWER 1= a) ---------- >> <----180 (ANSWER 1a) ---------- >> <----PRANSWER ----------- >> <----UPDATE (OFFER= 2) -------- >> <----UPDATE (OFFER 2) --------- >> <----???? -------------------- >> <----200 (ANSWER 1= b) ------------------------------------------------------ >> <----200 (ANSWER 1b) ---------- >> <----ANSWER --------------- >> >> > > That's not a call flow that is legal for use of update. From section 5.1 = of of RFC 3311 has > > o If the UPDATE is being sent before completion of the initial > INVITE transaction, and the initial INVITE contained an offer, > the UPDATE can contain an offer if the callee generated an > answer in a reliable provisional response, and the caller has > received answers to any other offers it sent in either PRACK or > UPDATE, and has generated answers for any offers it received in > an UPDATE from the callee. > > If the answer from UA1 is going to do updates before the invite transacti= on complete, it needs to do that with 100rel / PRACK. Note the diagram shou= ld also show an the 200 response to the update is going to cary an answer. I agree. I appologize for making too many assumptions. The 180 IS sent reli= ably, there IS a PRACK, and there IS a response to the UPDATE. > So if you made all these changes, lets talk about how you would solve thi= s problem in the JS App. > > Fundamentally what is happening here is the call signaling is setting up = two session - this is parallel media forking and parallel signaling forking= .=20 We could even make it more simply by removing the forking part, ie there is= a reliable 180, follwed by an UPDATE. But, for now, let's continue with th= e flow above... (I have added some numbering to your text below) >1. One fork to UA1, and one to UA2. Yes. >2. The JS App needs to pick which one it is going to choose to have a medi= a session with. Yes. >3. Let's say it choose UA1, then it would map the Answer 1a to an Answer, = the Offer2 to an offer. Here comes the issue: According to jsep-02, when Offer2 comes the JSEP O/A state machine is in th= e "pranswer" state, where a new offer is not accepted. And, yes, we could fix that by accepting a new offer at that point. But, to= which state would be then go? >4. If it was going to choose UA2, it would not pass the answer down to the= browser at all and would instead wait till it Answer 1b and pass that down= . Sure. >5. If you think it should simultaneously have a media session with both UA= 1 and UA2, then things are more complicated. I realize that at the time it = gets ANSWER 1a, it does not know it will later get ANSWR 1b so that make it= hard to choose UA2. I am assuming serial forking. Once the answer from UA2 has been provided to= the browser, I don't care if the media session with UA1 goes away. But, again, my main issue at this point is not about media - it's about how= the offers and answers between the JS app and the UAs are mapped to JSEP o= ffer/pranswer/answer. > Parallel forking with early media and secure media is a hard problem in S= IP as we know from the HERFP discussion. I'm unaware of real world problem = that are solved well with > SIP and require parallel forking and thus my focus has been on making sur= e we solve serial forking. No disagreement from my side there :)=20 > I'm perfectly happy if we *also* solve parallel forking but I don't care = too much as long a early media serial forking scenarios work because theses= do happen all the time. At the moment, JSEP-02 does talk about cloning. I don't know whether you su= ggest that to be removed, but if it stays it would work also for serial for= king. Regards, Christer= From fluffy@cisco.com Sat Oct 13 05:44:39 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60BA21F854C for ; Sat, 13 Oct 2012 05:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.372 X-Spam-Level: X-Spam-Status: No, score=-110.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGdyg2h0n9ov for ; Sat, 13 Oct 2012 05:44:39 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 34A8E21F8427 for ; Sat, 13 Oct 2012 05:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=340; q=dns/txt; s=iport; t=1350132279; x=1351341879; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RHBhO1/mNV4GAEzEJsH/bRTKj6akHYazz4dAV/Jg4UQ=; b=EiY15bVBZgfLWL9/ccSi5yZNAEr/MTOe8FY4OpE77KcbBctbtbrVXhZx XDcTYC2Hj+ywuJd+bQ0KQ9NJ7w8G75i3XCpREpc2qUGqxsjGGduEvHrAN 6BbRIg5AzUbVzHMxLEuMkrl+pcJA9ZmJLhQRpsM9pw/jQqF4si654FQtQ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAMdheVCtJXHB/2dsb2JhbABFhUu6IYEIgiABAQEDARIBJz8FCwIBCCIUEDIlAgQOBQgah1wGnBafW4tZhV1gA6QxgWuCbYIX X-IronPort-AV: E=Sophos;i="4.80,580,1344211200"; d="scan'208";a="131237829" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 13 Oct 2012 12:44:32 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9DCiWIA022658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 13 Oct 2012 12:44:32 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Sat, 13 Oct 2012 07:44:32 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [rtcweb] PRANSWER is unusable for serial forking Thread-Index: AQHNqOnc3QfmtiokskqSBC02DG7AB5e21Ob3gACuEoA= Date: Sat, 13 Oct 2012 12:44:31 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A0585340BAD087C@ESESSCMS0356.eemea.ericsson.se>, <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA8C@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA8C@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19268.004 x-tm-as-result: No--32.200000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] PRANSWER is unusable for serial forking X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 12:44:39 -0000 On Oct 13, 2012, at 1:21 AM, Christer Holmberg wrote: > Hi Cullen, >=20 > I'll read your reply more in detail later, but please note that I assume = that the 180 is sent *reliably* (I left the PRACK out). ok - that was probably part of the confusing was we were reading that diffe= rntly= From pkyzivat@alum.mit.edu Sun Oct 14 12:26:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877B621F84D2 for ; Sun, 14 Oct 2012 12:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.224 X-Spam-Level: * X-Spam-Status: No, score=1.224 tagged_above=-999 required=5 tests=[AWL=-1.528, BAYES_00=-2.599, FB_NO_MORE_OFFER=3.189, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVtCk+HQ+9oY for ; Sun, 14 Oct 2012 12:26:09 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id A9BA521F849C for ; Sun, 14 Oct 2012 12:26:09 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta03.westchester.pa.mail.comcast.net with comcast id B0ts1k00L1ap0As537SEbR; Sun, 14 Oct 2012 19:26:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id B7Mk1k00G3ZTu2S3i7MkyF; Sun, 14 Oct 2012 19:21:44 +0000 Message-ID: <507B10A4.1010302@alum.mit.edu> Date: Sun, 14 Oct 2012 15:21:08 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAD087E@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Oct 2012 19:26:10 -0000 On 10/12/12 11:59 AM, Cullen Jennings (fluffy) wrote: > > On Oct 9, 2012, at 4:58 PM, Martin Thomson wrote: > >> On 9 October 2012 13:05, Cullen Jennings (fluffy) wrote: >>> 3264, SDP, 3261, and related documents are dealing with a bunch of things including what happens at media plane and signaling plane. >>> >>> I'll note that though O/A is per dialog, there is only one O shared across multiple legs and when you create the O you don't know how many dialogs there will be. So from the media point of view (covered more in SDP spec than 3264) there is one O with a bunch of A. From signaling point of view there are a bunch of O/A pairs). >>> >>> The dialog is SIP signaling concept not a media plane level concept. We moved the signaling part out of the browser and into the JS. But the media part is still in the browser. So as 3264 says, after the offer is constructed, we have to be willing to receive media for all the codec type in the offer. When we get the answer 3264 makes it clear that one MAY stop receiving the codecs that were in the offer but not selected in the answer. However, this can not be done until the signaling layer is sure that no more offers will be honored. Since that signalling part of Offer/Answer is in the JS, the API need to to have a way to signal what the MAY part should do and that is the PRANSWER vs ANSWER. >> >> That's a consistent and logical view. It is not what RFC 3264 says. >> It may even be the only reasonable solution. >> >>> People keep trying to make this some complex weird argument invoking the SIP deities of the past and quoting incomprehensible phrases from various RFC caved in stone [...] >> >> Quit beating around the bush: it's me you are talking about. >> >> It's not a complex weird argument, it's this: >> PRANSWER is not described in RFC 3264. >> >> draft-*-jsep might say something about it, but I'd have to guess about >> what to do if I were to implement the feature and that doesn't help >> with interoperation. >> >> If there was text that described the above, plus the implications in >> some detail (including what resources can be released as they relate >> to the SDP), then we're good. I don't even think that writing this is >> especially hard. > > Agree that text has to be a clear. But provision is a term from 3261 which is referenced from 3264 and bunch of this also relies on SDP RFC too. Some of the key information about it is 3262. This is all intertwined but my key point is that I don't think we are trying to do anything that was not part of 3264 offer / answer. This is more or less a SIP 180. I am trying to follow this argument, but am having difficulty, even though I agree with much of what has been said by those who seem to be on different sides of the "argument". There is much about what needs to be done in presence of forking that is not written, but which is a corollary to what is specified. Most of what Christer described falls into this category. Implementations that don't do this will fail on some cases. The problem I have with PRANSWER is that I don't if it ever applies when sip is at one end, and if so, how it applies. IMO the simple answer is that it is an extension that should not be used when gatewaying to sip. But now I think I see people saying it is only there for gatewaying to sip. If so, then I want to see a specification for how this maps. Thanks, Paul From pkyzivat@alum.mit.edu Sun Oct 14 12:43:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6DA21F845D for ; Sun, 14 Oct 2012 12:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.057 X-Spam-Level: X-Spam-Status: No, score=-0.057 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_53=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZgIAi25YiUW for ; Sun, 14 Oct 2012 12:43:33 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 20CAD21F8421 for ; Sun, 14 Oct 2012 12:43:32 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta04.westchester.pa.mail.comcast.net with comcast id B7Me1k0030Fqzac547jdD6; Sun, 14 Oct 2012 19:43:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id B7eN1k00J3ZTu2S3U7eNAr; Sun, 14 Oct 2012 19:38:22 +0000 Message-ID: <507B14B7.5010807@alum.mit.edu> Date: Sun, 14 Oct 2012 15:38:31 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAD087E@ESESSCMS0356.eemea.ericsson.se> , <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAD102B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAD102B@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Oct 2012 19:43:34 -0000 On 10/10/12 4:03 AM, Christer Holmberg wrote: > Hi, > >>>>> I have not seen any reason to relax 3264 yet but if something comes up, agree we should carefully look at the cases. I think we can just do straight up 3264. >>>> >>>> RFC 3264 doesn't describe PRANSWER. The concept is entirely absent. >>>> >>>> The offerer MAY immediately cease listening for media formats that >>>> were listed in the initial offer, but not present in the answer. >>>> >>>> "the" answer. >>> >>> I agree with Martin. 3264 O/A is always per dialog, and forking is supported by generating multiple dialogs. JSEP, OTOH, in order to support forking with a >>> single "dialog" (peerConnection local descriptor), now defines O/A as offer+any number of pranswers + answer. >>> >>> So, we would e.g. have to define what happens if a new offer is received from the remote side while the browser is in pranswer-received state (see my call flow in another reply). >> >> 3264, SDP, 3261, and related documents are dealing with a bunch of things including what happens at media plane and signaling plane. >> >> I'll note that though O/A is per dialog, there is only one O shared across multiple legs and when you create the O you don't know how many dialogs there will be. > > The *initial* O is shared across multiple legs. Once a dialog has been created, O/A transactions on that leg will not affect other legs. +1 I'll also observe that you can have early dialogs without reliable provisionals. E.g.: - A sends INIVTE offering codecs C1 and C2 - proxy P forks first to B. - B sends unreliable 180, tag BBB, with answer selecting codec C1, and starts sending media. - P cancels the invite to B and forwards the invite to C - C sends unreliable 180, tag CCC, with answer selecting codec C2, and starts sending media - C sends 200 with same answer as before. Note that A must not invalidate the use of C2 when it receives the 180 from B, unless it first clones the invite. It must leave it eligible for use on other dialogs. And of course while it can manage separate O/A state machines per dialog, down at the RTP stack it may not be able to correlate the incoming media with a particular one of those O/A state machines. (Consider the example above, but the 180 from B is lost - never received by A. Since it isn't reliable, nobody knows this. But the media still comes.) Of course things are a bit different when you layer ICE on top of this. I won't try to discuss that. Thanks, Paul From harald@alvestrand.no Mon Oct 15 09:38:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A33321F8620 for ; Mon, 15 Oct 2012 09:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.365 X-Spam-Level: X-Spam-Status: No, score=-110.365 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDQz4gzVooyX for ; Mon, 15 Oct 2012 09:38:42 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B6D2A21F861B for ; Mon, 15 Oct 2012 09:38:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 90C4A39E1A6 for ; Mon, 15 Oct 2012 18:38:40 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZPZqkv3Um5I for ; Mon, 15 Oct 2012 18:38:39 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7BC2D39E16A for ; Mon, 15 Oct 2012 18:38:39 +0200 (CEST) Message-ID: <507C3C0E.7060006@alvestrand.no> Date: Mon, 15 Oct 2012 18:38:38 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <20121015163131.3756.11599.idtracker@ietfa.amsl.com> In-Reply-To: <20121015163131.3756.11599.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121015163131.3756.11599.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------090502000200000308030305" Subject: [rtcweb] Fwd: New Version Notification for draft-alvestrand-rtcweb-vp8-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 16:38:43 -0000 This is a multi-part message in MIME format. --------------090502000200000308030305 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit As the chairs asked for - here is some written input for the video codec MTI discussion. Harald -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-rtcweb-vp8-00.txt Date: Mon, 15 Oct 2012 09:31:31 -0700 From: internet-drafts@ietf.org To: harald@alvestrand.no CC: agrange@google.com A new version of I-D, draft-alvestrand-rtcweb-vp8-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-alvestrand-rtcweb-vp8 Revision: 00 Title: VP8 as RTCWEB Mandatory to Implement Creation date: 2012-10-15 WG ID: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-alvestrand-rtcweb-vp8-00.txt Status: http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8 Htmlized: http://tools.ietf.org/html/draft-alvestrand-rtcweb-vp8-00 Abstract: This document recommends that the RTCWEB working group choose the VP8 specification as a mandatory to implement video codec for RTCWEB implementations. This document is not intended for publication as an RFC. The IETF Secretariat --------------090502000200000308030305 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit As the chairs asked for - here is some written input for the video codec MTI discussion.

   Harald


-------- Original Message --------
Subject: New Version Notification for draft-alvestrand-rtcweb-vp8-00.txt
Date: Mon, 15 Oct 2012 09:31:31 -0700
From: internet-drafts@ietf.org
To: harald@alvestrand.no
CC: agrange@google.com 


A new version of I-D, draft-alvestrand-rtcweb-vp8-00.txt
has been successfully submitted by Harald Alvestrand and posted to the
IETF repository.

Filename:	 draft-alvestrand-rtcweb-vp8
Revision:	 00
Title:		 VP8 as RTCWEB Mandatory to Implement
Creation date:	 2012-10-15
WG ID:		 Individual Submission
Number of pages: 7
URL:             http://www.ietf.org/internet-drafts/draft-alvestrand-rtcweb-vp8-00.txt
Status:          http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8
Htmlized:        http://tools.ietf.org/html/draft-alvestrand-rtcweb-vp8-00


Abstract:
   This document recommends that the RTCWEB working group choose the VP8
   specification as a mandatory to implement video codec for RTCWEB
   implementations.

   This document is not intended for publication as an RFC.


                                                                                  


The IETF Secretariat



--------------090502000200000308030305-- From partha@parthasarathi.co.in Mon Oct 15 10:55:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5636221F883C for ; Mon, 15 Oct 2012 10:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POwI66I5ZYFe for ; Mon, 15 Oct 2012 10:55:24 -0700 (PDT) Received: from outbound-us2.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.237]) by ietfa.amsl.com (Postfix) with ESMTP id 75F2921F8823 for ; Mon, 15 Oct 2012 10:55:24 -0700 (PDT) Received: from userPC (unknown [122.172.188.3]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us2.mailhostbox.com (Postfix) with ESMTPA id AEF6D3E23BC; Mon, 15 Oct 2012 17:55:17 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1350323721; bh=RZaMUdgDXDDaUXDDd3vtCgpFyzl7JBy/PaA/93ibq6Q=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=DTOm/GQGLuWjK8h1a6606YCNLNQAeBOah9cjw4GPNj4lJk3dvwwIXxuk4z/G9cOWA xb8vj6CU8HbwXpjukBunfUUnYhlH/tDRw9eThOB7eqhfEVyQqemMdU4BmSYtsEdSFi fG/J/nb8C3vx8hAMjHR07tTnAcIDUUQAQUYGwRxQ= From: "Parthasarathi R" To: "'Cullen Jennings \(fluffy\)'" , "'Christer Holmberg'" References: <506B0367.4000103@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340BAD087E@ESESSCMS0356.eemea.ericsson.se> , <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6B@ESESSCMS0356.eemea.ericsson.se> <000b01cda720$bd5097a0$37f1c6e0$@co.in>, <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA86@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Date: Mon, 15 Oct 2012 23:25:12 +0530 Message-ID: <001701cdaafe$3dc94c70$b95be550$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNqOl+kDeDfA5eqEW9OAbsBiOagpe6qM1g Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0B0202.507C4E09.0039, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 17:55:28 -0000 Cullen, As you mentioned in another mail thread, the discussion is about mapping UPDATE with SDP just after reliable 18x with SDP in JSEP PRANSWER state. Hope you agree that PRANSWER does not address UPDATE with SDP (OFFER from remote) in the early dialog scenario. Thanks Partha -----Original Message----- From: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com] Sent: Saturday, October 13, 2012 7:52 AM To: Christer Holmberg Cc: Parthasarathi R; Subject: Re: [rtcweb] Agenda requests for Atlanta meeting On Oct 12, 2012, at 11:43 AM, Christer Holmberg wrote: > Hi, > >> I fully agree this needs to work early media to PSTN via SIP. I don't see any problem with doing that. I'm happy to work through detail call flows to make sure that early media to PSTN works. >> >> Update after a 180 is not allowed by the Update RFC as I pointed out in other email exactly because just in SIP with no RTCP web, the UA that caret the invite would not have enough information to be able to process this as you point in the thread below. > > As far as I know, UPDATE is allowed after a reliable 180. If you don't agree, please show me the text which forbids it :) > > Regards, I agree - but it's not ok after a normal 180 From internet-drafts@ietf.org Mon Oct 15 16:48:27 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3783621F88FE; Mon, 15 Oct 2012 16:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAPEuAddX4aj; Mon, 15 Oct 2012 16:48:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C864321F88F1; Mon, 15 Oct 2012 16:48:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121015234826.6745.30772.idtracker@ietfa.amsl.com> Date: Mon, 15 Oct 2012 16:48:26 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-qos-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 23:48:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : DSCP and other packet markings for RTCWeb QoS Author(s) : Subha Dhesikan Dan Druta Paul Jones James Polk Filename : draft-ietf-rtcweb-qos-00.txt Pages : 10 Date : 2012-10-15 Abstract: Many networks, such as Service Provider and Enterprise networks, can provide per packet treatments based on Differentiated Services Code Points (DSCP) on a per hop basis. This document defines the recommended DSCP values for browsers to use for various classes of traffic. This draft is a very early and far from done. It is meant to provide the structure for the idea of how to do this but much discussion is needed about the details. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-qos There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-qos-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From dbenham@cisco.com Mon Oct 15 17:17:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830C311E80F2 for ; Mon, 15 Oct 2012 17:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpScTok+HycT for ; Mon, 15 Oct 2012 17:17:46 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id BBD3711E8097 for ; Mon, 15 Oct 2012 17:17:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1410; q=dns/txt; s=iport; t=1350346666; x=1351556266; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=bPfm3S5tRxjQ321UzCuYsCsaxKWMmDAP4Tvej1VYmlg=; b=lP4KnHzqqqlMFekv8GjWEuyr4GDipu9MeysQfftpRduUUXWbzbL23kxa b/K6PIBXUtwwT9jq/I8mf/zmdKqw6XloA7u9Hu7eC0SkXtZm7XyXFui0p VT1KShSKuQhjz2hpnjaJtBDBtqGPZXpoUCRFCXuHO4QXIV8PBgFozqKNr g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHKmfFCtJXG8/2dsb2JhbABFhhK5CXmBCIIhAQEEEgEQBgtDEgIBAiACBiACAgIwFRACBBsBGYdiC5tJjR+CO5BSgSGKU4UQMmADlwGNMIFrgm2CFw X-IronPort-AV: E=Sophos;i="4.80,592,1344211200"; d="scan'208";a="131675513" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 16 Oct 2012 00:17:46 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9G0Hktu002372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 16 Oct 2012 00:17:46 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.252]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 19:17:45 -0500 From: "David Benham (dbenham)" To: "rtcweb@ietf.org" Thread-Topic: New Version Notification for draft-dbenham-webrtc-videomti-00.txt Thread-Index: AQHNqzDUnL4kiHG6Z0e6uRroK0Wp25e7DRmw Importance: high X-Priority: 1 Date: Tue, 16 Oct 2012 00:17:44 +0000 Message-ID: <0683D6CB32AC424D8AF52C0F660E5DC51508EE16@xmb-aln-x10.cisco.com> References: <20121015235726.9247.32687.idtracker@ietfa.amsl.com> In-Reply-To: <20121015235726.9247.32687.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.140.119] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19274.004 x-tm-as-result: No--20.699200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [rtcweb] New Version Notification for draft-dbenham-webrtc-videomti-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Oct 2012 00:17:47 -0000 VGhlcmUgYXJlIHNldmVyYWwgVVJMcyBpbiB0aGUgdGV4dCB2ZXJzaW9uIHRoYXQgd3JhcCBhcm91 bmQgbXVsdGlwbGUgbGluZXMsIHNvIHRoZXkgbmVlZCB0byBoYXZlIHRoZWlyIGV4dHJhIHNwYWNl cyBhdCBsaW5lcyBicmVha3MgcmVtb3ZlZCBpZiB5b3UgY29weSBhbmQgcGFzdGUgdGhlbSAoZGlk bid0IGdldCBhcm91bmQgdG8gbWFraW5nIHRpbnkgdXJscykuICBPdGhlcndpc2UsIGJldHRlciB0 byBqdXN0IGdvIHRvIHRoZSBodG1saXplZCB2ZXJzaW9uIGZvciB0aGUgbGlua3MuDQoNCg0KRmls ZW5hbWU6CSBkcmFmdC1kYmVuaGFtLXdlYnJ0Yy12aWRlb210aQ0KUmV2aXNpb246CSAwMA0KVGl0 bGU6CQkgSC4yNjQvQVZDIGFzIE1hbmRhdG9yeS10by1JbXBsZW1lbnQgVmlkZW8gQ29kZWMgZm9y IFJUQ3dlYg0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMTAtMTUNCldHIElEOgkJIEluZGl2aWR1YWwg U3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxMA0KVVJMOiAgICAgICAgICAgICBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1kYmVuaGFtLXdlYnJ0Yy12aWRlb210 aS0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1kYmVuaGFtLXdlYnJ0Yy12aWRlb210aQ0KSHRtbGl6ZWQ6ICAgICAgaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGJlbmhhbS13ZWJydGMtdmlkZW9tdGktMDANCg0KQWJz dHJhY3Q6DQogICBUaGlzIG1lbW8gcHJvcG9zZXMgdGhhdCBILjI2NC9BVkMgYmUgc2VsZWN0ZWQg YXMgdGhlIG1hbmRhdG9yeS10by0NCiAgIGltcGxlbWVudCAoTVRJKSB2aWRlbyBjb2RlYyBmb3Ig UlRDd2ViIGR1ZSB0byBpcyBBZG9wdGlvbiBBZHZhbnRhZ2UsDQogICBRdWFsaXR5LVBvd2VyLUJh bmR3aWR0aCBhZHZhbnRhZ2UsIEhhcmR3YXJlIEFjY2VsZXJhdGlvbiBBZHZhbnRhZ2UNCiAgIGFu ZCBXZWxsLWVzdGFibGlzaGVkIElQUiBTdGF0dXMuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoN Cg== From magnus.westerlund@ericsson.com Tue Oct 16 04:20:38 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B772A21F887B for ; Tue, 16 Oct 2012 04:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.225 X-Spam-Level: X-Spam-Status: No, score=-106.225 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lptYzHdrTcJQ for ; Tue, 16 Oct 2012 04:20:38 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7375421F857A for ; Tue, 16 Oct 2012 04:20:36 -0700 (PDT) X-AuditID: c1b4fb25-b7f956d0000011c3-6f-507d4303f190 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 80.ED.04547.3034D705; Tue, 16 Oct 2012 13:20:35 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Tue, 16 Oct 2012 13:20:34 +0200 Message-ID: <507D4302.9050108@ericsson.com> Date: Tue, 16 Oct 2012 13:20:34 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+JvrS6zc22AwdlZohZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr490c+4Lb7BXTr7xmb2A8y9bFyMkhIWAisWLmY3YIW0ziwr31 QHEuDiGBU4wSN/4sZodwljNKXNx9C6yKV0Bb4uG1PiYQm0VAVWJTfycriM0mYCFx80cj2FRR gWCJSfu3sEDUC0qcnPkEzBYRUJe4/PAC2BxhAV2JmXsPQF0hKfFm8k2wGmYBPYkpV1sYIWx5 ieats5lBbCGgvQ1NHawTGPlnIRk7C0nLLCQtCxiZVzEK5yZm5qSXG+mlFmUmFxfn5+kVp25i BIbZwS2/VXcw3jkncohRmoNFSZzXeusefyGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MU02T Pgccrou17Dr765HHgb64acEz5nzZtK/W32CCuGvJ/BVBVfL3z6xi33n20ZPrDXZeGvePHdbb 0z93gbUG40XuF/tuz53Gz9U2WcW+u6fxRtaym8sW6SkGsahtO/0/MCrilXs9B//Fkts/l//0 Kjjj9/eok3AIm2565WLbRQsPzDC/x/hJWYmlOCPRUIu5qDgRAIs62ocBAgAA Subject: [rtcweb] Summary of Video Codec contributions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Oct 2012 11:20:38 -0000 WG, The Video Codec selection internet draft to RTCWEB WG I have seen are the following four: http://www.ietf.org/internet-drafts/draft-dbenham-webrtc-videomti-00.txt https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/ https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/ https://datatracker.ietf.org/doc/draft-marjou-rtcweb-video-codec/ Please review information and proposals and lets start discussing them on the mailing list prior to the WG meeting in Atlanta. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From neils@vipadia.com Tue Oct 16 06:35:40 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355B021F8848 for ; Tue, 16 Oct 2012 06:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1A8Hi-RUJZPq for ; Tue, 16 Oct 2012 06:35:39 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5342921F8843 for ; Tue, 16 Oct 2012 06:35:38 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so4752962lam.31 for ; Tue, 16 Oct 2012 06:35:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=YD1Hn4VU8yd1PLL0SByfBlIBrz73q5UpcOsNkFpSNRg=; b=VIwkJy2RMwEsltDfxs4uCQ4BKJfDNL1kpzQfVPBifmcxFkfPEqPjLE7uM5kxU3rlFi B6htNDJHn+mx9KwpBD6Xe1akfd3ZtRoq/wE4VmuDQSkidUE/ixhbifLAFHaRTOF/EA2q Zbt9NW5YvVyq2ZlP+y76Yo4yBnyRsdRFxkV5Lfa4bOcy872VJcmsTActfMEYwB1zAC3y GBdENbX/Eh2VwOQiYEMEqsR0l8T/stUtyfNhwYQ4hQaqAonrcX2lTYnp7dMrREkXLAWC ogJyplOsUddoI2HFxmUAl3iQlrAAqzYTMHm81nvBaA7FuGeouWsTOyKELP47MTAjQ1Dk rhMw== MIME-Version: 1.0 Received: by 10.112.25.161 with SMTP id d1mr5550080lbg.118.1350394537931; Tue, 16 Oct 2012 06:35:37 -0700 (PDT) Sender: neils@vipadia.com Received: by 10.114.70.76 with HTTP; Tue, 16 Oct 2012 06:35:37 -0700 (PDT) In-Reply-To: <507D4302.9050108@ericsson.com> References: <507D4302.9050108@ericsson.com> Date: Tue, 16 Oct 2012 14:35:37 +0100 X-Google-Sender-Auth: MF62c6SCzWR7xNe9dL-ULxo9coA Message-ID: From: Neil Stratford To: Magnus Westerlund Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQny034jvj0qxc3HRkGhWUO2sbG8Wa4BYbIpcprUUpUMtBCSOM65985gjCHtToC3y8hQGCb5 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Summary of Video Codec contributions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Oct 2012 13:35:40 -0000 On Tue, Oct 16, 2012 at 12:20 PM, Magnus Westerlund wrote: > WG, > > The Video Codec selection internet draft to RTCWEB WG I have seen are > the following four: > > http://www.ietf.org/internet-drafts/draft-dbenham-webrtc-videomti-00.txt > > https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/ > > https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/ > > https://datatracker.ietf.org/doc/draft-marjou-rtcweb-video-codec/ > > Please review information and proposals and lets start discussing them > on the mailing list prior to the WG meeting in Atlanta. Something that concerns me about video codecs is the availability of a scalable coding profile. Many plugins that we are trying to replace with WebRTC appear to be starting to make use of scalable coding techniques to enable efficient multi-party calls. To encourage the replacement of such plugins the codec specified in WebRTC should offer the ability to match what is best practice today. I understand that H.264 has Annex G, and that VP8 has something similar. Are there any issues around making this MTI for either codec that would help drive a decision? Neil From harald@alvestrand.no Tue Oct 16 07:49:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1AE21F880C for ; Tue, 16 Oct 2012 07:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.389 X-Spam-Level: X-Spam-Status: No, score=-110.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUX7K0Be-9+S for ; Tue, 16 Oct 2012 07:49:13 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A54F821F8805 for ; Tue, 16 Oct 2012 07:49:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8C25A39E197 for ; Tue, 16 Oct 2012 16:49:12 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5FPpaAI7LOi for ; Tue, 16 Oct 2012 16:49:11 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 724DF39E029 for ; Tue, 16 Oct 2012 16:49:11 +0200 (CEST) Message-ID: <507D73E6.3030808@alvestrand.no> Date: Tue, 16 Oct 2012 16:49:10 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <507D4302.9050108@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Summary of Video Codec contributions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Oct 2012 14:49:14 -0000 On 10/16/2012 03:35 PM, Neil Stratford wrote: > On Tue, Oct 16, 2012 at 12:20 PM, Magnus Westerlund > wrote: >> WG, >> >> The Video Codec selection internet draft to RTCWEB WG I have seen are >> the following four: >> >> http://www.ietf.org/internet-drafts/draft-dbenham-webrtc-videomti-00.txt >> >> https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/ >> >> https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/ >> >> https://datatracker.ietf.org/doc/draft-marjou-rtcweb-video-codec/ >> >> Please review information and proposals and lets start discussing them >> on the mailing list prior to the WG meeting in Atlanta. > Something that concerns me about video codecs is the availability of a > scalable coding profile. Many plugins that we are trying to replace > with WebRTC appear to be starting to make use of scalable coding > techniques to enable efficient multi-party calls. To encourage the > replacement of such plugins the codec specified in WebRTC should offer > the ability to match what is best practice today. > > I understand that H.264 has Annex G, and that VP8 has something > similar. Are there any issues around making this MTI for either codec > that would help drive a decision? For one thing, I believe the hardware support for SVC is minimal to nonexistent. People have also been raising doubts about the cost/benefit tradeoff of H.264 SVC. At the moment, we have no proposals to adopt SVC as MTI, so I believe the point is moot. Of course, any implementation that supports codecs beyond the MTI will be free to offer them as part of the negotiation phase. But that doesn't make them MTI. Harald From bernard_aboba@hotmail.com Tue Oct 16 10:35:39 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A0221F8A6C for ; Tue, 16 Oct 2012 10:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.185 X-Spam-Level: X-Spam-Status: No, score=-100.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtZrEMdMWDeJ for ; Tue, 16 Oct 2012 10:35:33 -0700 (PDT) Received: from blu0-omc3-s36.blu0.hotmail.com (blu0-omc3-s36.blu0.hotmail.com [65.55.116.111]) by ietfa.amsl.com (Postfix) with ESMTP id CFAA721F8A77 for ; Tue, 16 Oct 2012 10:35:32 -0700 (PDT) Received: from BLU402-EAS132 ([65.55.116.74]) by blu0-omc3-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Oct 2012 10:35:23 -0700 X-Originating-IP: [61.8.205.230] X-EIP: [WipnkVcGmAX4iIA05ryZXonHytGGEYIH] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Date: Tue, 16 Oct 2012 10:35:19 -0700 From: Bernard Aboba To: rtcweb@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-OriginalArrivalTime: 16 Oct 2012 17:35:23.0594 (UTC) FILETIME=[9F2AE2A0:01CDABC4] Subject: Re: [rtcweb] SVC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Oct 2012 17:35:39 -0000 U29tZSBjaGlwc2V0cyBkbyBzdXBwb3J0IHRlbXBvcmFsIHNjYWxpbmcgKHNlYXJjaCAnc29jIHN1 cHBvcnQgZm9yIEguMjY0L1NWQycpLCBhbmQgdGhlcmUgYXJlIHN3IGltcGxlbWVudGF0aW9ucyB0 aGF0IHN1cHBvcnQgdGVtcG9yYWwsIHF1YWxpdHkgYW5kIHNwYXRpYWwgc2NhbGluZyAoIGh0dHA6 Ly93d3cucG9seWNvbS5jb20vY29tcGFueS9uZXdzL3ByZXNzLXJlbGVhc2VzLzIwMTIvMjAxMjEw MDQuaHRtbCkuICA= From elagerway@gmail.com Wed Oct 17 01:56:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1383121F87EF for ; Wed, 17 Oct 2012 01:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKKYqki3beJF for ; Wed, 17 Oct 2012 01:56:57 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8998521F87E4 for ; Wed, 17 Oct 2012 01:56:56 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so5471090lam.31 for ; Wed, 17 Oct 2012 01:56:55 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=uGbY5R4eWV29YmWfzAltUrF21rwXIe4Yo8zar1Cm2ww=; b=a+U/b7ZuZ6UMpwKDSbK1mMk3zdSDqMVEDcl7PniFHhqkpRftxbgtJkd3syEZKQFQ5b 0cc5gOlsvRDoB8l7krnyj0ofbhuD7q1FOpPQrQZG2K6a2zIQWTgGf857R1hIDlP/u6pn fpuuQ95P2nyB4S1cMpSSFwwOK6I9dM1ZU+FDkymga+WvUmVEPYA70Dj4D5Z1gfzaedI7 Lwq9uBorLiMqSgfxPxaE83yzC7akK7DDe9WxgwgOWc5C2R1Drdk1N4WszdP1T742FVGr Cfda7xF4ThxoFs2Ywi5yjo4YY99TSjUH4fA8kgkA4HXIlE/Z50SLnAlklsTlsL9K+qp1 cWEQ== MIME-Version: 1.0 Received: by 10.112.23.197 with SMTP id o5mr6614871lbf.114.1350464215420; Wed, 17 Oct 2012 01:56:55 -0700 (PDT) Sender: elagerway@gmail.com Received: by 10.114.68.82 with HTTP; Wed, 17 Oct 2012 01:56:55 -0700 (PDT) In-Reply-To: <507D4302.9050108@ericsson.com> References: <507D4302.9050108@ericsson.com> Date: Wed, 17 Oct 2012 01:56:55 -0700 X-Google-Sender-Auth: JMBNPOkpIwTcu7qP4UO1z7f4qww Message-ID: From: Erik Lagerway To: Magnus Westerlund Content-Type: multipart/alternative; boundary=485b390f7df4d78e2604cc3d7388 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Summary of Video Codec contributions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Oct 2012 08:56:58 -0000 --485b390f7df4d78e2604cc3d7388 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thought it important to point out the fact that FREE-P8 (VP8) would likely be the preferred codec implemented by independent developers. Royalties and admin headaches create a barrier to entry. Independent dev shops equate to a great deal of innovation and some of these have been responsible for dictating the standard in market with hundreds of millions of users. Yes, there is plenty of interoperability with 264 today but that doesn't mean it will be that way tomorrow. Can't we do both, as we have done for Audio MTI? Cost for implementation of both is not really that high and if VP8 is included it will likely be the choice for rtc indie devs globally, spurring innovation. If unknown IPR is the only real reason not to include VP8 then I maybe we are not trying hard enough. RTCweb / WebRTC is supposed to be the next big thing, why hamper innovation like this? I understand this will likely not count as a vote, just wanted to voice some concerns. My apologies in advance if this has been answered in another thread or offline. I searched the threads and found no reference and my double isn't always available. /Erik *Erik Lagerway | *Hookflash * | m 1.604.562.8647* **** On Tue, Oct 16, 2012 at 4:20 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > WG, > > The Video Codec selection internet draft to RTCWEB WG I have seen are > the following four: > > http://www.ietf.org/internet-drafts/draft-dbenham-webrtc-videomti-00.txt > > https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/ > > https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/ > > https://datatracker.ietf.org/doc/draft-marjou-rtcweb-video-codec/ > > Please review information and proposals and lets start discussing them > on the mailing list prior to the WG meeting in Atlanta. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > 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 > --485b390f7df4d78e2604cc3d7388 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thought it important to point out the fact that FREE-P8 (VP8) would likely = be the preferred codec implemented by independent developers. Royalties and= admin headaches create a barrier to entry. Independent dev shops equate to= a great deal of innovation and some of these have been responsible for dic= tating the standard in market with hundreds of millions of users. Yes, ther= e is plenty of interoperability with 264 today but that doesn't mean it= will be that way tomorrow.

Can't we do both, as we have done for Audio MTI? Cost for implement= ation of both is not really that high and if VP8 is included it will likely= be the choice for rtc indie devs globally, spurring innovation.

If unknown IPR is the only real reason not to include VP8 then I maybe we a= re not trying hard enough. RTCweb / WebRTC is supposed to be the next big t= hing, why hamper innovation like this?

I understand this will likely= not count as a vote, just wanted to voice some concerns. My apologies in a= dvance if this has been answered in another thread or offline. I searched t= he threads and found no reference and my double isn't always available.=

/Erik

<= a href=3D"http://ca.linkedin.com/in/lagerway" target=3D"_blank">Erik Lagerway | Hookflash | m 1.604.562.8647=
<= /span>


On Tue, Oct 16, 2012 at 4:20 AM, Magnus = Westerlund <magnus.westerlund@ericsson.com> wro= te:
WG,

The Video Codec selection internet draft to RTCWEB WG I have seen are
the following four:

http://www.ietf.org/internet-drafts/draft-dbenh= am-webrtc-videomti-00.txt

https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-v= p8/

https://datatracker.ietf.org/doc/draft-burman-rtcweb= -h264-proposal/

https://datatracker.ietf.org/doc/draft-marjou-rtcweb-v= ideo-codec/

Please review information and proposals and lets start discussing them
on the mailing list prior to the WG meeting in Atlanta.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =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

--485b390f7df4d78e2604cc3d7388-- From ron@debian.org Wed Oct 17 12:20:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6282E21F861A for ; Wed, 17 Oct 2012 12:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.034 X-Spam-Level: X-Spam-Status: No, score=0.034 tagged_above=-999 required=5 tests=[AWL=-1.458, BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MBMh2AfE2Zc for ; Wed, 17 Oct 2012 12:20:50 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFF121F8634 for ; Wed, 17 Oct 2012 12:20:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANEDf1B20idQ/2dsb2JhbABFwCeBCYIgAQEEATocKAsLGC4UGA1Sh2MFvAiLWIZCA44Bh2kBkDSDAg Received: from ppp118-210-39-80.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([118.210.39.80]) by ipmail06.adl2.internode.on.net with ESMTP; 18 Oct 2012 05:50:48 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id C98DA4F8F3 for ; Thu, 18 Oct 2012 05:50:46 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bttJe36CLlus for ; Thu, 18 Oct 2012 05:50:46 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 42D474F902; Thu, 18 Oct 2012 05:50:46 +1030 (CST) Date: Thu, 18 Oct 2012 05:50:46 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20121017192046.GO6812@audi.shelbyville.oz> References: <507D4302.9050108@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] Summary of Video Codec contributions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Oct 2012 19:20:51 -0000 Hi Erik, On Wed, Oct 17, 2012 at 01:56:55AM -0700, Erik Lagerway wrote: > Thought it important to point out the fact that FREE-P8 (VP8) would likely > be the preferred codec implemented by independent developers. Royalties and > admin headaches create a barrier to entry. Independent dev shops equate to > a great deal of innovation and some of these have been responsible for > dictating the standard in market with hundreds of millions of users. Yes, > there is plenty of interoperability with 264 today but that doesn't mean it > will be that way tomorrow. Very true. Though for developers who don't click-track and count users of their software it is more than just preferred. An RF solution is actually the only viable way for this standard to be accessible to them. Any standard that immediately excludes a large portion of potential developers and adopters can only ever be of niche value and is certain to be replaced before long by an alternative that doesn't have that constraint as a fundamental flaw preventing its broadest use. If the whole point of this group was to avoid further fracturing of the developer efforts in this space, then solving this problem now would be much preferable to forcing another group to develop another competing standard that does address that issue. It would be a sad waste of the invested time of the people here if we didn't recognise this necessity. I think the points you make above are very relevant here. > Can't we do both, as we have done for Audio MTI? Well, the M in MTI stands for Mandatory. So mandating both would be mandating the barriers to entry that you so clearly identified above? Mandating an RF video codec, and permitting any other to be negotiated as an extension would be more like what we decided was best for audio. > If unknown IPR is the only real reason not to include VP8 then I maybe we > are not trying hard enough. If that's the only reason people have for opposing VP8 then maybe they're trying too hard. Resorting to imaginary reasons to make the issue seem more complex than it really is doesn't seem very enlightening. Every day that goes by leaves this argument dangling from a thinner, more strained thread of tenuousness. It's been well over a year since the very public call to form an offensive pool was made or even since the last very vague mumbling of "yeah, some people responded. honest." - meanwhile VP8 continues to serve millions of users every day through things like youtube et al. with no concrete claim being made against them of infringement. It's not like this is a secret, so any submarine patent holder must know that laches is now daily eroding their 'investment'. The extensive patent search made in the attempt to form a pool surely only weakens their case further in the absence of any real disclosure or claim being made - if not outright coming close in itself to 'proving' that no such IPR exists. If VP8 was mandated here, I presume that would additionally place an obligation of disclosure on any of the participants of this group, which would strengthen that protection even more. If we get to the end of this process and there are still no actual claims being presented for substantiation, then it seems reasonable to conclude that we may be as safe as it is ever possible to be from "unknown IPR" (until the laws are changed to end that kind of madness once and for all). By contrast the present day known burdens of H.264 are very real, and if we're going to project our future concerns, then I think we've got more to worry about from the royalties for H.264 being dialled up greatly as the patents on it begin to expire and their holders want to 'encourage' people to switch to H.265 while its patents are still nice and fresh. Locking people into that seems like a far greater danger. Especially since unlike VP8, H.264 really has had submarine patents surface on it and really is an exposed pawn in the present theatre of patent warfare that everyone else seems to be ducking stray bullets from these days. So spruiking there's somehow a spookier risk to VP8 in the face of all available evidence to the contrary seems like some sport where you have to squint pretty hard and tip your head 90 degrees to the left in a dark room, before that line of plot extrapolation might perhaps appear to be spinning in an even vaguely-real kind of direction, sort of ... And even then, only if the people wanting you to buy that proposition don't properly label their axes ... > RTCweb / WebRTC is supposed to be the next big thing, why hamper > innovation like this? Indeed we should not, and I for one certainly hope consensus is that we will not. Stay sharp! Ron From worley@shell01.TheWorld.com Wed Oct 17 13:05:11 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8FB21F86C5 for ; Wed, 17 Oct 2012 13:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMvOSgS5JZok for ; Wed, 17 Oct 2012 13:05:08 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 1213921F86B6 for ; Wed, 17 Oct 2012 13:05:07 -0700 (PDT) Received: from shell.TheWorld.com (nevins@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id q9HK457l012976 for ; Wed, 17 Oct 2012 16:04:07 -0400 Received: from shell01.TheWorld.com (localhost [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9HK45Hf4780584 for ; Wed, 17 Oct 2012 16:04:05 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9HK45QU4781362; Wed, 17 Oct 2012 16:04:05 -0400 (EDT) Date: Wed, 17 Oct 2012 16:04:05 -0400 (EDT) Message-Id: <201210172004.q9HK45QU4781362@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: rtcweb@ietf.org In-reply-to: (fluffy@cisco.com) Subject: [rtcweb] WebRTC offer/answer design and corresponding SIP gateway design X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Oct 2012 20:05:11 -0000 > From: "Cullen Jennings (fluffy)" > > But we all need to get this thread to specific examples about real > world use cases that people can understand. This is an analysis of how SIP/WebRTC gateway design depends upon and reflects the offer/answer architecture that is chosen for WebRTC. The unexpected result is that a SIP/WebRTC gateway can work well with a *simpler* WebRTC offer/answer architecture than is being discussed, indeed, an O/A architecture resembling a single caller/callee pair. * Background The overall task that must be performed by a SIP/WebRTC-server gateway combined with the WebRTC-client is the same as what a SIP telephone does. A detailed discussion is in my previous message http://www.ietf.org/mail-archive/web/rtcweb/current/msg05435.html. The important point for this discussion is: Quality handing of outgoing SIP calls requires integrating (mixing) information from both the signaling and media for all early dialogs to generate the media stream to be presented to the user. Let me now outline three architectures and their characteristics. I still haven't checked the consequences of requiring ICE, but I believe that it does not fundamentally change the analysis. * cloning In the cloning architecture, the WebRTC protocol reveals the multiple dialogs of the SIP call. When the client Javascript initiates the call, a "call object" is created. When the SIP signaling reveals to the gateway the existence of a new early dialog, the gateway uses WebRTC to tell the client of the new dialog, and a child "dialog object" is created. The dialog objects are continually updated by information from the WebRTC server to tell the Javascript the status of the early dialogs. The WebRTC client is the source/target of the media streams. (If it is possible for an early dialog's media stream to arrive at the client before corresponding SIP signaling, the client stack creates additional dialog objects for those early dialogs.) The client stack or Javascript must integrate the information in the signaling and media to produce the audio stream to be presented to the user. This architecture is the most complicated form of WebRTC. It also requires that the client stack and/or Javascript implement the full processing required by a SIP phone in all cases, because in general, the client-side code never knows whether a communication session is directed to a SIP gateway or not. * PRANSWER In the PRANSWER architecture, the WebRTC protocol carries SDP in a manner that is similar to SDP offer/answer between two endpoints. The exception is that the offer provided with call initiation may receive a sequence of answers, which inform the client of the origins of successive early dialogs that it should listen to. The WebRTC client is the source/target of the media streams. This architecture presupposes that there will be only one early dialog at a time that is producing media that the user needs to hear, and that the gateway can determine from the SIP signaling what this sequence of dialogs is. The difficulty is that neither of these presuppositions is correct: Given parallel forking, the call may have reached destinations that are both producing important feedback at the same time. Also, the SIP signaling does not completely inform the SIP caller which destinations are producing media streams that contain information -- that decision requires determining if RTP is arriving from each destination and whether the RTP is non-silent. In addition, if the signaling shows that a destination is ringing but is not providing media, synthetic ringback media should be provided. This architecture requires that the gateway make these decisions despite not being the endpoint of the media streams. * simple In the "simple" architecture, the WebRTC protocol models a *single* offer/answer dialog, and all of the media processing required for a SIP early dialog is placed in the gateway: Initially, the gateway provides an answer giving *itself* as the server end of the media streams. During the early phase of the call, the gateway decodes, synthesizes, and mixes all of the early media according to the principles for SIP telephones, and sends a single RTP stream to the WebRTC client that is the audio the user should hear. This is relatively easy because the gateway has direct access to both the signaling and the media from the SIP destinations. At some point (probably when one dialog becomes established), the gateway decides to remove itself from the media processing, and does a "Z operation" to pass a new offer/answer pair between the now-unique UAS and the WebRTC client. (A "Z operation" is named for its appearance on protocol diagrams: An intermediate device sends a request to the endpoint in one direction demanding that it produce an offer; the intermediate device passes the offer through to the other endpoint, which produces an answer; the intermediate device passes the answer through back to the first endpoint.) This architecture has several advantages: (1) The WebRTC protocol implements only a single offer/answer sequence. (2) The gateway is responsible for combining the media and signaling information of the early dialogs; the multiple early dialogs are not revealed in WebRTC. This processing is relatively easy to implement, as it can be implemented in about the same way that SIP phones now implement it. (3) Improving the handling of multiple early dialogs can be done entirely by updating the gateway; the WebRTC protocol does not commit the processing to any particular model. (4) WebRTC client stacks and application Javascript provide no special support for SIP forking; all connections appear to them to be "a direct connection to a media server". Dale From matthew.kaufman@skype.net Wed Oct 17 13:25:37 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD3921F86E5 for ; Wed, 17 Oct 2012 13:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qzrIxCclmhg for ; Wed, 17 Oct 2012 13:25:37 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.30]) by ietfa.amsl.com (Postfix) with ESMTP id A646021F86E2 for ; Wed, 17 Oct 2012 13:25:36 -0700 (PDT) Received: from BY2FFO11FD009.protection.gbl (10.1.15.201) by BY2FFO11HUB028.protection.gbl (10.1.14.139) with Microsoft SMTP Server (TLS) id 15.0.516.0; Wed, 17 Oct 2012 20:26:30 +0000 Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD009.mail.protection.outlook.com (10.1.14.73) with Microsoft SMTP Server (TLS) id 15.0.516.0 via Frontend Transport; Wed, 17 Oct 2012 20:26:29 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.52]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0318.003; Wed, 17 Oct 2012 20:25:04 +0000 From: Matthew Kaufman To: "Cullen Jennings (fluffy)" , Christer Holmberg Thread-Topic: Relaxing SDP O/A (was RE: [rtcweb] Agenda requests for Atlanta meeting) Thread-Index: Ac2soVaPkW4RjXahQS+tE0/0W+snsw== Date: Wed, 17 Oct 2012 20:25:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(3846001)(4396001)(8716001)(51856001)(42186003)(5343655001)(4196001)(20776001)(47776002)(31966008)(44976002)(1076001)(33656001)(50466001)(74662001)(46102001)(49866001)(16406001)(47976001)(47736001)(47446002)(50986001)(48376001)(16826001)(74502001)(16696001)(316001)(3556001)(3746001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0637FCE711 Cc: "rtcweb@ietf.org" Subject: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Oct 2012 20:25:37 -0000 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Cullen Jennings (fluffy) Sent: Tuesday, October 9, 2012 7:17 AM > I have not seen any reason to relax 3264 yet but if something comes up, a= gree we should carefully look at the cases. I think we can just do straight= up > 3264. Arguments that SIP early media in a 180 is not compliant with 3= 264 are just wrong. We've *already* "relaxed" 3264's requirements in JSEP (comments apply to dr= aft-ietf-rtcweb-jsep-01) =09 Straight from 3264: "At any time, either agent MAY generate a new offer tha= t updates the session. However, it MUST NOT generate a new offer if it has = received an offer which it has not yet answered or rejected. Furthermore, i= t MUST NOT generate a new offer if it has generated a prior offer for which= it has not yet received an answer or a rejection. If an agent receives an = offer after having sent one, but before receiving an answer to it, this is = considered a "glare" condition." The JSEP API enforces no such rules. If you want to change the API to bring= it into compliance with *just this section* of 3264, it would need all sor= ts of changes... - 5.1.1 createOffer ... "Calling this method does not change state; its use= is not required". Ok, so how then is JSEP to enforce the two "MUST NOT gen= erate a new offer" is the quote from 3264 above? I would think that createO= ffer must return an error whenever the "MUST NOT" cases apply. (Never mind = that if the "use is not required" then somehow I'm to guess what SDP is leg= al for this browser to pass in to setLocalDescription as an offer?) - 5.1.4 setLocalDescription... has no language indicating that it is prohib= ited to call "setLocalDescription" with an offer and then call it again wit= h a different offer without having supplied an answer. There also appears t= o be no way to pass a "reject" in. (These two issues appear in the W3C API = state description too, so appears to really be what we mean when we say tha= t we're going to "use JSEP") - 5.1.2 createAnswer... "Calling this method does not change state; its use= is not required". So then how can setLocalDescription know when it is forb= idden to accept an "offer" passed to it (as createOffer is not required) wh= en setRemoteDescription has been passed an "offer" but "createAnswer" has n= ot yet been called? And so on. This isn't the only section of 3264 that's gone out the window with JSEP, b= ut saying "I have not seen any reason to relax 3264 yet" doesn't make any s= ense... that ship sailed when JSEP was proposed. Matthew Kaufman From matthew.kaufman@skype.net Wed Oct 17 13:41:29 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B6921F86F0 for ; Wed, 17 Oct 2012 13:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5y8dFpCHV02 for ; Wed, 17 Oct 2012 13:41:29 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.30]) by ietfa.amsl.com (Postfix) with ESMTP id AEC1821F86F7 for ; Wed, 17 Oct 2012 13:41:28 -0700 (PDT) Received: from BY2FFO11FD014.protection.gbl (10.1.15.203) by BY2FFO11HUB037.protection.gbl (10.1.14.120) with Microsoft SMTP Server (TLS) id 15.0.516.0; Wed, 17 Oct 2012 20:42:28 +0000 Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD014.mail.protection.outlook.com (10.1.14.76) with Microsoft SMTP Server (TLS) id 15.0.516.0 via Frontend Transport; Wed, 17 Oct 2012 20:42:28 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.52]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0318.003; Wed, 17 Oct 2012 20:40:31 +0000 From: Matthew Kaufman To: Justin Uberti , Emil Ivov Thread-Topic: [rtcweb] Filling in details on "trickle ICE" Thread-Index: AQHNggtYU4RJsiahn0ePX6kIvBvYA5eG0euAgAzxmgCAAFJqAIAqM0Zw Date: Wed, 17 Oct 2012 20:40:30 +0000 Message-ID: References: <50508ED7.9080805@ericsson.com> <505B6A7E.6010309@jitsi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A484160ED5CDtk5ex14mbxc272r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(5343635001)(4396001)(8716001)(16826001)(47446002)(15202345001)(74502001)(4196001)(5343655001)(16696001)(49866001)(47976001)(16406001)(512874001)(3846001)(46102001)(2666001)(31966008)(33656001)(42186003)(20776001)(1076001)(44976002)(47736001)(50986001)(74662001)(51856001)(316001)(3556001)(3746001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0637FCE711 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Oct 2012 20:41:29 -0000 --_000_AE1A6B5FD507DC4FB3C5166F3A05A484160ED5CDtk5ex14mbxc272r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSBmZXcgcXVlc3Rpb25zIHJhaXNlZCBieSB0aGlzIHRocmVhZDoNCg0KMSkgICAgICBEaWQgdGhl IGRpc2N1c3Npb24gYWJvdXQg4oCcdHJpY2tsZSBJQ0XigJ0gYWN0dWFsbHkgdHVybiBpbnRvIGFu IEktRCBmb3IgKEkgc3VwcG9zZSkgTU1VU0lDIHRvIGxvb2sgYXQ/DQoNCjIpICAgICAgQXJlIHdl IHNlcmlvdXNseSBjb25zaWRlcmluZyBkZWZpbmluZyB0aGUgYWxsb3dlZCBTRFAgZm9yIFJUQ1dF Qi9XRUJSVEMgYnkgcmVmZXJlbmNpbmcgYW4gSS1EIGFuZCBub3QgYW4gUkZDLCBvciBhcmUgd2Ug Z29pbmcgdG8gZGVsYXkgZGVmaW5pbmcgdGhlIGFsbG93ZWQgU0RQIHVudGlsIHRyaWNrbGUgSUNF IGlzIGluIGFuIFJGQywgb3IgYXJlIHdlIGdvaW5nIHRvIGRyb3AgdHJpY2tsZSBJQ0UgZnJvbSBS VENXRUIgMS4wPw0KDQozKSAgICAgIElzIElFVEYgb3IgVzNDIHRoZSByaWdodCB2ZW51ZSBmb3Ig ZGVmaW5pbmcgdGhlIHNwZWNpZmljIFNEUCB0aGF0IGlzIHBlcm1pdHRlZCBpbiB0aGUgSlNFUCDi gJxzZXRMb2NhbERlc2NyaXB0aW9u4oCdIGFuZCDigJxzZXRSZW1vdGVEZXNjcmlwdGlvbuKAnSBj YWxscyAoYW5kIHdoYXQgZXJyb3JzIHdpbGwgYmUgcmVwb3J0ZWQgd2hlbiBkaXNhbGxvd2VkIFNE UCBpcyBwYXNzZWQgdG8gdGhvc2UgQVBJcyk/DQoNCjQpICAgICAgSG93IGRvZXMgdHJpY2tsZSBJ Q0Ugd29yayB3aXRob3V0IOKAnHJlbGF4aW5n4oCdIFJGQzMyNjQgTy9BPyBJdCBzZWVtcyBsaWtl IHlvdSByZWFsbHkgd2FudCB0byBiZSBhYmxlIHRvIHRyaWNrbGUgdmlhIHVwZGF0ZWQgb2ZmZXJz IHRoYXQgbWF5IGJlIGdlbmVyYXRlZCBwcmlvciB0byB0aGUgY29ycmVzcG9uZGluZyBhbnN3ZXIg b3IgcmVqZWN0Pw0KDQpTb3JyeSBpZiBzb21lIG9mIHRoZXNlIHNlZW0gbGlrZSB0aGUgYW5zd2Vy IGlzIG9idmlvdXMsIGJ1dCBJIHRoaW5rIHdlIG5lZWQgdG8gZ2V0IHByZXR0eSBzcGVjaWZpYyBi ZWZvcmUgd2Ugc3RhcnQgYXNraW5nIG1ham9yIGJyb3dzZXIgdmVuZG9ycyB0byBiYWtlIHNvbWUg b2YgdGhpcyBsb2dpYyBpbnRvIG1pc3Npb24tY3JpdGljYWwgc29mdHdhcmUuDQoNCk1hdHRoZXcg S2F1Zm1hbg0K --_000_AE1A6B5FD507DC4FB3C5166F3A05A484160ED5CDtk5ex14mbxc272r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdy YXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFy Z2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCglt YXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21z by1saXN0LWlkOjExMzc0MDk1MzA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOjEwMjEzNjE5OTQgNjc2OTg3MDUgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3 MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3Qg bDA6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBw dDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6 bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGlu O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkEgZmV3IHF1ZXN0aW9ucyByYWlzZWQgYnkgdGhpcyB0aHJlYWQ6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkRpZCB0aGUgZGlzY3Vzc2lvbiBhYm91dCDigJx0cmlja2xlIElDReKA nSBhY3R1YWxseSB0dXJuIGludG8gYW4gSS1EIGZvciAoSSBzdXBwb3NlKSBNTVVTSUMgdG8gbG9v ayBhdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+QXJlIHdlIHNlcmlvdXNseSBjb25zaWRlcmluZyBkZWZpbmlu ZyB0aGUgYWxsb3dlZCBTRFAgZm9yIFJUQ1dFQi9XRUJSVEMgYnkgcmVmZXJlbmNpbmcgYW4gSS1E IGFuZCBub3QgYW4gUkZDLCBvciBhcmUgd2UgZ29pbmcgdG8gZGVsYXkgZGVmaW5pbmcgdGhlDQog YWxsb3dlZCBTRFAgdW50aWwgdHJpY2tsZSBJQ0UgaXMgaW4gYW4gUkZDLCBvciBhcmUgd2UgZ29p bmcgdG8gZHJvcCB0cmlja2xlIElDRSBmcm9tIFJUQ1dFQiAxLjA/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1 aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj4zKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklz IElFVEYgb3IgVzNDIHRoZSByaWdodCB2ZW51ZSBmb3IgZGVmaW5pbmcgdGhlIHNwZWNpZmljIFNE UCB0aGF0IGlzIHBlcm1pdHRlZCBpbiB0aGUgSlNFUCDigJxzZXRMb2NhbERlc2NyaXB0aW9u4oCd IGFuZCDigJxzZXRSZW1vdGVEZXNjcmlwdGlvbuKAnSBjYWxscw0KIChhbmQgd2hhdCBlcnJvcnMg d2lsbCBiZSByZXBvcnRlZCB3aGVuIGRpc2FsbG93ZWQgU0RQIGlzIHBhc3NlZCB0byB0aG9zZSBB UElzKT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjQpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SG93IGRvZXMgdHJpY2tsZSBJQ0Ugd29yayB3aXRob3V0IOKA nHJlbGF4aW5n4oCdIFJGQzMyNjQgTy9BPyBJdCBzZWVtcyBsaWtlIHlvdSByZWFsbHkgd2FudCB0 byBiZSBhYmxlIHRvIHRyaWNrbGUgdmlhIHVwZGF0ZWQgb2ZmZXJzIHRoYXQgbWF5IGJlIGdlbmVy YXRlZA0KIHByaW9yIHRvIHRoZSBjb3JyZXNwb25kaW5nIGFuc3dlciBvciByZWplY3Q/IDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+U29ycnkgaWYgc29tZSBvZiB0aGVzZSBzZWVtIGxpa2UgdGhlIGFuc3dlciBpcyBvYnZp b3VzLCBidXQgSSB0aGluayB3ZSBuZWVkIHRvIGdldCBwcmV0dHkgc3BlY2lmaWMgYmVmb3JlIHdl IHN0YXJ0IGFza2luZyBtYWpvciBicm93c2VyIHZlbmRvcnMgdG8gYmFrZSBzb21lDQogb2YgdGhp cyBsb2dpYyBpbnRvIG1pc3Npb24tY3JpdGljYWwgc29mdHdhcmUuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NYXR0aGV3 IEthdWZtYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_AE1A6B5FD507DC4FB3C5166F3A05A484160ED5CDtk5ex14mbxc272r_-- From goran.ap.eriksson@ericsson.com Wed Oct 17 15:01:19 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7078B21F871C for ; Wed, 17 Oct 2012 15:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tP2KBL2p82oS for ; Wed, 17 Oct 2012 15:01:18 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2E47121F86E2 for ; Wed, 17 Oct 2012 15:01:17 -0700 (PDT) X-AuditID: c1b4fb25-b7f956d0000011c3-2a-507f2aacb512 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F5.B1.04547.CAA2F705; Thu, 18 Oct 2012 00:01:16 +0200 (CEST) Received: from ESESSHC011.ericsson.se (153.88.183.51) by esessmw0191.eemea.ericsson.se (153.88.115.84) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 18 Oct 2012 00:01:16 +0200 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 00:01:15 +0200 From: =?iso-8859-1?Q?G=F6ran_Eriksson_AP?= To: "sdeshika@cisco.com" , "DRUTA, DAN" , "paulej@packetizer.com" Thread-Topic: Comments on draft-ietf-rtcweb-qos-00.txt Thread-Index: AQHNqy+YmuK3A53r3ke18OIDB2OD9Ze9+Yhg Date: Wed, 17 Oct 2012 22:01:15 +0000 Message-ID: <532A6DC6F9C115439C41705FF73D138701D7C9@ESESSMB209.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvre4arfoAgwerdCwmtV9itZjf+5HR Yu2/dnaLA035DiweL/vnMHpM+b2R1WPJkp9MHg37jrIHsERx2aSk5mSWpRbp2yVwZXxr/8ta cE694nNvVgPjHPkuRk4OCQETiduvjzBD2GISF+6tZwOxhQROMUpMeFTQxcgFZO9klDi4u48Z wlnCKPGgr4MdpIpNwFti2oqzrCC2iEC9xIPlEJOYBdQl7iw+B1YjLGAo8ezGZiaIGjOJnR+O sUPYRhL3V20Fs1kEVCVerpjH2MXIwcELNHNOUylImFFAVuL+93ssECPFJW49mc8EcaiAxJI9 56GOFpV4+fgfK4StKPHx1T5GiHo9iRtTp7BB2NoSyxa+BqvnFRCUODnzCQvEk9oSE/qfsU9g FJuFZMUsJO2zkLTPQtK+gJFlFaNwbmJmTnq5kV5qUWZycXF+nl5x6iZGYHwd3PJbdQfjnXMi hxilOViUxHmtt+7xFxJITyxJzU5NLUgtii8qzUktPsTIxMEp1cCoMaf4loykyxKlMvYnhqK9 UT8W7zn06U10xYpb+y7sqjbpmhnnGHfp/THRArMXrx+WLFXmOWzbe+dUh/gBJdmJ3wy2P/CU 7Lh/OL6M82rC9Sdx8SGLWPTaUq/c9pE3XXQ2VD2++0VesezUpo6c3c9qX69tK3skGTg58szL tV/kuM5tM9kw5d8FJZbijERDLeai4kQAzhwgm30CAAA= Cc: "rtcweb@ietf.org" Subject: [rtcweb] Comments on draft-ietf-rtcweb-qos-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Oct 2012 22:01:19 -0000 Hi! I have some questions/comments about the draft (which I think is a nice sta= rt BTW, :-)!). Chapter 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D Paragraph 2: "This draft proposes how browser and other VOIP applications..= . Question: Addressing also non-browser "apps" widens the scope and this has= =20 implications on the amount to work that need to be covered to secure=20 completeness and correctness. Differences in security model for browser app= s vs other execution environments would need to be addressed. Would it hurt m= uch to limit the scope to browser *only*? Paragraph 6: "...defines some input..." Question: Are the references included in the "some", that is the use of tra= fficclass attribute in SDP [6] part of what webRTC should support, e.g. the solution = for the case with site (network) specific DSCP values? Question: "Some" implies other inputs as well- should this not be an exhaus= tive list if what governs the browser decision to ensure interoperability=20 between different implementations? Or am I missing something? Chapter 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D Question: I assume the "relative treament" input the Low, Medium and High v= alues in Table 1? Question: With "session" I understand one PeerConnection instantiation- cor= rect? Question: The priority indication used by the web app is coming from somewh= ere- is this an SDP issue? Chapter 6 =3D=3D=3D=3D=3D=3D=3D=3D=3D Question: What is the intent of having the LTE QCI Mapping table in the dra= ft? Which QCI that actually in the end will be associated to the trafficclass attribu= te is decided in the cellular network and it is I guess far from for sure one wou= ld get that QCI? Also, there are only a limited set of standardised QCI's- = there are and will be custom made QCI's out there. Isn't there a risk that = by putting it the readers will be lead to believe the web app will get that= treatment? Perhaps an "example LTE QCI mapping" is more appropriate? Comment: The reference to the GBR bearer in LTE leads us into the discussio= n about number and value of bw parameters in SDP for Max and Min bw. Perhaps just h= ighlighting that SDP issue/API requirement is in place referring to the app= ropriate rfc/draft where this will be covered? Chapter 8 =3D=3D=3D=3D=3D=3D=3D=3D=3D Question: Should not the trafficclass attribute [6] be mentioned here? Question: Should not the statistics API also include this information? Chapter 9: =3D=3D=3D=3D=3D=3D=3D=3D=3D Comment: The need to figure out IP address and port used makes sense but pe= rhaps the background to that requirement could be explained more in the cha= pters before since it covers sofar only on the use of priority and DSCP? Comment: I guess one potential risk is a maliceous/poortly written web app can mess with the trafficclass attribute/priority labeling/bw attribute and= =20 if the marking in the IP header cannot be trusted, then it will I guess be discarded in the network, e.g. in the LTE modem receiving the IP packet fro= m the browser when it decides which "QCI" to use- no trust and it ends up o= n the default bearer, :-). Many regards GE > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: den 16 oktober 2012 01:48 > To: i-d-announce@ietf.org > Cc: rtcweb@ietf.org > Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-qos-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Real-Time Communication in=20 > WEB-browsers Working Group of the IETF. >=20 > Title : DSCP and other packet markings for RTCWeb QoS > Author(s) : Subha Dhesikan > Dan Druta > Paul Jones > James Polk > Filename : draft-ietf-rtcweb-qos-00.txt > Pages : 10 > Date : 2012-10-15 >=20 > Abstract: > Many networks, such as Service Provider and Enterprise=20 > networks, can > provide per packet treatments based on Differentiated Services Code > Points (DSCP) on a per hop basis. This document defines the > recommended DSCP values for browsers to use for various classes of > traffic. >=20 > This draft is a very early and far from done. It is meant=20 > to provide > the structure for the idea of how to do this but much discussion is > needed about the details. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-qos >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-qos-00 >=20 >=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 > = From pkyzivat@alum.mit.edu Wed Oct 17 15:56:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661FB21F86FC for ; Wed, 17 Oct 2012 15:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.368 X-Spam-Level: X-Spam-Status: No, score=-0.368 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izfcDBCr37+l for ; Wed, 17 Oct 2012 15:56:45 -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 9E46421F86F6 for ; Wed, 17 Oct 2012 15:56:45 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta05.westchester.pa.mail.comcast.net with comcast id CBLA1k0051GhbT855NwpEu; Wed, 17 Oct 2012 22:56:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id CNsG1k00E3ZTu2S3TNsGC5; Wed, 17 Oct 2012 22:52:16 +0000 Message-ID: <507F3680.4060200@alum.mit.edu> Date: Wed, 17 Oct 2012 18:51:44 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 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 Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Oct 2012 22:56:46 -0000 Matthew, IIUC, JSEP is what can euphemistically called an "extended subset" of 3264. (Or less euphemistically, an incompatible dialect.) If so, how is one to interwork this with SIP components that are 3264 conformant? I have been assuming that this is to be accomplished by the server pushing javascript that is aware it is/may be interworking with sip, and which then constrains itself to the subset of JSEP that compatible with 3264. And then it is of course limited to those behaviors on the sip side that fall within the subset of 3264 that JSEP supports. Is that the right way to view it? Thanks, Paul On 10/17/12 4:25 PM, Matthew Kaufman wrote: > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings (fluffy) > Sent: Tuesday, October 9, 2012 7:17 AM > >> I have not seen any reason to relax 3264 yet but if something comes up, agree we should carefully look at the cases. I think we can just do straight up > 3264. Arguments that SIP early media in a 180 is not compliant with 3264 are just wrong. > > We've *already* "relaxed" 3264's requirements in JSEP (comments apply to draft-ietf-rtcweb-jsep-01) > > Straight from 3264: "At any time, either agent MAY generate a new offer that updates the session. However, it MUST NOT generate a new offer if it has received an offer which it has not yet answered or rejected. Furthermore, it MUST NOT generate a new offer if it has generated a prior offer for which it has not yet received an answer or a rejection. If an agent receives an offer after having sent one, but before receiving an answer to it, this is considered a "glare" condition." > > The JSEP API enforces no such rules. If you want to change the API to bring it into compliance with *just this section* of 3264, it would need all sorts of changes... > > - 5.1.1 createOffer ... "Calling this method does not change state; its use is not required". Ok, so how then is JSEP to enforce the two "MUST NOT generate a new offer" is the quote from 3264 above? I would think that createOffer must return an error whenever the "MUST NOT" cases apply. (Never mind that if the "use is not required" then somehow I'm to guess what SDP is legal for this browser to pass in to setLocalDescription as an offer?) > > - 5.1.4 setLocalDescription... has no language indicating that it is prohibited to call "setLocalDescription" with an offer and then call it again with a different offer without having supplied an answer. There also appears to be no way to pass a "reject" in. (These two issues appear in the W3C API state description too, so appears to really be what we mean when we say that we're going to "use JSEP") > > - 5.1.2 createAnswer... "Calling this method does not change state; its use is not required". So then how can setLocalDescription know when it is forbidden to accept an "offer" passed to it (as createOffer is not required) when setRemoteDescription has been passed an "offer" but "createAnswer" has not yet been called? > > And so on. > > This isn't the only section of 3264 that's gone out the window with JSEP, but saying "I have not seen any reason to relax 3264 yet" doesn't make any sense... that ship sailed when JSEP was proposed. > > Matthew Kaufman > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From christer.holmberg@ericsson.com Wed Oct 17 23:30:40 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73AC621F8584 for ; Wed, 17 Oct 2012 23:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.119 X-Spam-Level: X-Spam-Status: No, score=-6.119 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95Cxkt8ySIAr for ; Wed, 17 Oct 2012 23:30:39 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6141821F8582 for ; Wed, 17 Oct 2012 23:30:39 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-9a-507fa20d4835 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id AC.78.17130.D02AF705; Thu, 18 Oct 2012 08:30:37 +0200 (CEST) Received: from ESESSHC019.ericsson.se (153.88.183.75) by esessmw0256.eemea.ericsson.se (153.88.115.96) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 18 Oct 2012 08:30:37 +0200 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 08:30:37 +0200 From: Christer Holmberg To: Matthew Kaufman , Justin Uberti , Emil Ivov Thread-Topic: [rtcweb] Filling in details on "trickle ICE" Thread-Index: Ac2XjRRR2xT3N2ETRimioq1qbE99zgVCc2oAABiJLGA= Date: Thu, 18 Oct 2012 06:30:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B018842@ESESSMB209.ericsson.se> References: <50508ED7.9080805@ericsson.com> <505B6A7E.6010309@jitsi.org> 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.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGfG3Vpd3UX2AwaReHYs1OyewWGydKmQx 49ZZFou1/9rZHVg8Fmwq9Viy5CeTx/83gR63HkxiC2CJ4rJJSc3JLEst0rdL4Mp482YCY0EH b0XvzN0sDYx3eLoYOTkkBEwk+s4fZIawxSQu3FvP1sXIxSEkcIpR4sCD/1DOTkaJG0sWMUI4 Sxglti59AuRwcLAJWEh0/9MG6RYRKJI49vAf2CRmAXWJO4vPsYPYwgKWEus+XmGHqLGS+Lno OZx99uN7NhCbRUBV4seJx2C9vALeEl/610HtWssk8efXHEaQBKdAosTCHUtZQWxGoFO/n1rD BLFMXOLWk/lMEC8ISCzZcx7qHVGJl4//sULYihI7z7Yzg9zMLKApsX6XPkSrosSU7ofsEHsF JU7OfMICYgsJaEu0LJ7APoFRYhaSDbMQumch6Z6FpHsBI8sqRuHcxMyc9HJzvdSizOTi4vw8 veLUTYzAaDy45bfBDsZN98UOMUpzsCiJ8+qp7vcXEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnV wLiJ/4v/3XZ75tXdnz3OxnBphk5adrphYu0qHiEG9XKrqMWTTeRfcJpO2maUtVgk54Jh96WY wHhTyf9/vO5OTlVT9LLu7WfaubTuevskxZrEUy77jl5IvbviLNvf0lOXBWXXHSg4nXv07rki B+vgXUk36ip1dtvG3J0sOKM/SnKB4KKo9M5tMkosxRmJhlrMRcWJAHKhjLuUAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 06:30:40 -0000 SGkgTWF0dGhldywNCg0KPkEgZmV3IHF1ZXN0aW9ucyByYWlzZWQgYnkgdGhpcyB0aHJlYWQ6DQo+ DQo+MSkgRGlkIHRoZSBkaXNjdXNzaW9uIGFib3V0IOKAnHRyaWNrbGUgSUNF4oCdIGFjdHVhbGx5 IHR1cm4gaW50byBhbiBJLUQgZm9yIChJIHN1cHBvc2UpIE1NVVNJQyB0byBsb29rIGF0Pw0KDQpo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yZXNjb3JsYS1tbXVzaWMt aWNlLXRyaWNrbGUtMDAudHh0DQoNClRoZXJlIGhhcyBiZWVuIHNvbWUgZGlzY3Vzc2lvbiBvbiB0 aGUgbGlzdCBhbHJlYWR5Lg0KDQo+MikgQXJlIHdlIHNlcmlvdXNseSBjb25zaWRlcmluZyBkZWZp bmluZyB0aGUgYWxsb3dlZCBTRFAgZm9yIFJUQ1dFQi9XRUJSVEMgYnkgcmVmZXJlbmNpbmcgYW4g SS1EIGFuZCBub3QgYW4gUkZDLCBvciBhcmUgd2UgZ29pbmcgdG8gZGVsYXkgZGVmaW5pbmcgdGhl IGFsbG93ZWQgU0RQIHVudGlsIHRyaWNrbGUgSUNFIGlzIGluIGFuIFJGQywgb3IgYXJlIHdlIGdv aW5nIHRvIGRyb3AgdHJpY2tsZSBJQ0UgZnJvbSBSVENXRUIgMS4wPw0KDQpJIGd1ZXNzIHRoZSBz YW1lIHF1ZXN0aW9uIGFwcGxpZXMgYWxzbyB0byBCVU5ETEUsIGFuZCBwb3RlbnRpYWxseSB0byBh IG51bWJlciBvZiBvdGhlciBJLURzLg0KDQo+NCkgSG93IGRvZXMgdHJpY2tsZSBJQ0Ugd29yayB3 aXRob3V0IOKAnHJlbGF4aW5n4oCdIFJGQzMyNjQgTy9BPyBJdCBzZWVtcyBsaWtlIHlvdSByZWFs bHkgd2FudCB0byBiZSBhYmxlIHRvIHRyaWNrbGUgdmlhIHVwZGF0ZWQgb2ZmZXJzIHRoYXQgbWF5 IGJlIGdlbmVyYXRlZCBwcmlvciB0byB0aGUgY29ycmVzcG9uZGluZyBhbnN3ZXIgb3IgcmVqZWN0 PyANCg0KT25lIG9mIG15IGNvbW1lbnRzIG9uIHRoZSB0cmlja2xlIGRyYWZ0IHdhcyBhYm91dCB0 aGF0LiBUaGUgZHJhZnQgc2F5cyB0aGF0IGEgbmV3IG9mZmVyIGNhbiBiZSBzZW50ICJhdCBhbnkg dGltZSIsIGJ1dCBteSBjb21tZW50IHdhcyB0aGF0IGl0IHNob3VsZCBiZSBhY2NvcmRpbmcgdG8g MzI2NC4NCg0KSUYgd2UgYXJlIGdvaW5nIHRvIHJlbGF4IDMyNjQgKEkgcmVhbGx5IGhvcGUgd2Ug YXJlIE5PVCksIGl0IG5lZWRzIHRvIGJlIGNsZWFybHkgZGVzY3JpYmVkIHNvbWV3aGVyZS4gV2Ug Y2Fubm90IGhhdmUgYSBudW1iZXIgb2YgSS1EcyBkb2luZyBpdCAib24gdGhlIHJ1biIuLi4NCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg== From emil@sip-communicator.org Thu Oct 18 02:54:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E56221F85C4 for ; Thu, 18 Oct 2012 02:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jh5+jIsERwU6 for ; Thu, 18 Oct 2012 02:54:19 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5178121F85C2 for ; Thu, 18 Oct 2012 02:54:19 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so5481715wey.31 for ; Thu, 18 Oct 2012 02:54:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=FfnlzSr7Yb+6PhGv0MhWegNdSFJkEAg0c2g0Rs1OxQ0=; b=HW+44TiRhTSW5AaC9uwIo0Iq1M+lNxjyk8XsAjlavTUsW3f7fhZDWKmI9fbWXCksW3 k2ZoYYv3smfQsdB1WaRMGmSG3sALbSURjBwpRBuc1vxbRzSG210YLlmE2t+OHKSuK2kS dVxQiZ0uk2T3JZh/NGQuo53rT57AZ51b+CPcBeZM+wmvRZ4Vy85bXRd97HBdeF7uV5TC y9kNUBTZxtmZiUsfwcjRJ1uHw+Rh9NKcTOelvKOLLFYBqqo8iq8HE6m/HaCxODXG0d4R FH/ogIwypuKuHMbuyGB1EbxLO/uGxbuz/d1xK7X9tQejpbP8O7sNX07ezZNcVH9Jfg0d Sp1g== Received: by 10.180.100.136 with SMTP id ey8mr10150070wib.1.1350554058369; Thu, 18 Oct 2012 02:54:18 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:3d45:139d:6e4e:60df]) by mx.google.com with ESMTPS id dt9sm28737714wib.1.2012.10.18.02.54.17 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Oct 2012 02:54:17 -0700 (PDT) Message-ID: <507FD1C8.8000100@jitsi.org> Date: Thu, 18 Oct 2012 11:54:16 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <50508ED7.9080805@ericsson.com> <505B6A7E.6010309@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018842@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B018842@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnh3rHOE4On0yyVvPZ1NGXdDE1WZ5Qll4dYGbeHvTaXb4Nsl67Y2Y5FKF/kcmSJgtDWBJUo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 09:54:20 -0000 Hey folks, On 18.10.12, 08:30, Christer Holmberg wrote: > On 17.10.12, 22:40, Matthew Kaufman wrote: >>=20 >> 4) How does trickle ICE work without =E2=80=9Crelaxing=E2=80=9D RFC326= 4 O/A? It >> seems like you really want to be able to trickle via updated offers >> that may be generated prior to the corresponding answer or reject? >=20 > One of my comments on the trickle draft was about that. The draft > says that a new offer can be sent "at any time", but my comment was > that it should be according to 3264. That's not exactly what the draft says. What it does say is: At any point of ICE processing, a trickle ICE agent may receive new candidates from the remote agent. > IF we are going to relax 3264 (I really hope we are NOT), it needs to > be clearly described somewhere. We cannot have a number of I-Ds doing > it "on the run"... I don't see how trickle ICE would require any changes to the O/A model. Candidate trickling semantics are completely separate from those in 3264.= Yes, the 3264 offer may, in some cases, contain a first batch of candidates and the the 3264 may have to be delayed until ICE processing yields valid pairs for every component but that's about it. Am I missing something? Emil --=20 https://jitsi.org From christer.holmberg@ericsson.com Thu Oct 18 04:17:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B4121F8697 for ; Thu, 18 Oct 2012 04:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.12 X-Spam-Level: X-Spam-Status: No, score=-6.12 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oo6CtR1DwZIY for ; Thu, 18 Oct 2012 04:17:34 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 66EA521F8652 for ; Thu, 18 Oct 2012 04:17:33 -0700 (PDT) X-AuditID: c1b4fb25-b7f956d0000011c3-b8-507fe54c14f0 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B1.9F.04547.C45EF705; Thu, 18 Oct 2012 13:17:32 +0200 (CEST) Received: from ESESSHC022.ericsson.se (153.88.183.84) by esessmw0256.eemea.ericsson.se (153.88.115.96) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 18 Oct 2012 13:17:31 +0200 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 13:17:31 +0200 From: Christer Holmberg To: Emil Ivov Thread-Topic: [rtcweb] Filling in details on "trickle ICE" Thread-Index: Ac2XjRRR2xT3N2ETRimioq1qbE99zgVCc2oAABiJLGAAAy+oAAAG/KWg Date: Thu, 18 Oct 2012 11:17:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B018C70@ESESSMB209.ericsson.se> References: <50508ED7.9080805@ericsson.com> <505B6A7E.6010309@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018842@ESESSMB209.ericsson.se> <507FD1C8.8000100@jitsi.org> In-Reply-To: <507FD1C8.8000100@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3VtfnaX2AweGFwhZrdk5gsdg6Vchi xq2zLBZr/7WzO7B4LNhU6rFkyU8mj/9vAj1uPZjEFsASxWWTkpqTWZZapG+XwJXx5+AE5oIG wYp7Z2+wNzCeEOhi5OCQEDCRWLUjsYuRE8gUk7hwbz1bFyMXh5DAKUaJyZuOMEE4Oxklfnd2 M0M4SxglPj/+wQTSzSZgIdH9TxukW0RAXqK7bRETiM0sUCUx+docRhBbWMBSYt3HK+wQNVYS Pxc9h7LdJI5euAhWwyKgKjH3RDMriM0r4C3xrX89K8SuPmaJjoYPYEM5BTQl1my4D9bACHTq 91NroJaJS9x6Mp8J4gUBiSV7zjND2KISLx//Y4WwFSV2nm1nBrmZGWjO+l36EK2KElO6H7JD 7BWUODnzCQuILSSgLdGyeAL7BEaJWUg2zELonoWkexaS7gWMLKsYhXMTM3PSy430Uosyk4uL 8/P0ilM3MQJj8eCW36o7GO+cEznEKM3BoiTOa711j7+QQHpiSWp2ampBalF8UWlOavEhRiYO TqkGxllb8uZ2ChyWm+Cpu9Z79rfNL1cu61h2ws/68KL5/GserTOMiEu+p/XVxkQ8Zuttvlmt XTFHRITfV/5IWP46Za+DBdfU7xlPmjITPRo7RQ+kdH/81NtxWcOkVo595abiD+a2vv9mfdH8 cDAn+/HZWtUDl86l5i3k9k5g+lN9p4Lr4MrMTft8rimxFGckGmoxFxUnAgCas3CwkwIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 11:17:34 -0000 SGksDQogDQo+Pj4gNCkgSG93IGRvZXMgdHJpY2tsZSBJQ0Ugd29yayB3aXRob3V0IOKAnHJlbGF4 aW5n4oCdIFJGQzMyNjQgTy9BPyBJdCBzZWVtcyANCj4+PiBsaWtlIHlvdSByZWFsbHkgd2FudCB0 byBiZSBhYmxlIHRvIHRyaWNrbGUgdmlhIHVwZGF0ZWQgb2ZmZXJzIHRoYXQgDQo+Pj4gbWF5IGJl IGdlbmVyYXRlZCBwcmlvciB0byB0aGUgY29ycmVzcG9uZGluZyBhbnN3ZXIgb3IgcmVqZWN0Pw0K Pj4gDQo+PiBPbmUgb2YgbXkgY29tbWVudHMgb24gdGhlIHRyaWNrbGUgZHJhZnQgd2FzIGFib3V0 IHRoYXQuIFRoZSBkcmFmdCBzYXlzIA0KPj4gdGhhdCBhIG5ldyBvZmZlciBjYW4gYmUgc2VudCAi YXQgYW55IHRpbWUiLCBidXQgbXkgY29tbWVudCB3YXMgdGhhdCBpdCANCj4+IHNob3VsZCBiZSBh Y2NvcmRpbmcgdG8gMzI2NC4NCj4NCj5UaGF0J3Mgbm90IGV4YWN0bHkgd2hhdCB0aGUgZHJhZnQg c2F5cy4gV2hhdCBpdCBkb2VzIHNheSBpczoNCj4NCj4gIEF0IGFueSBwb2ludCBvZiBJQ0UgcHJv Y2Vzc2luZywgYSB0cmlja2xlIElDRSBhZ2VudCBtYXkgcmVjZWl2ZSBuZXcNCj4gIGNhbmRpZGF0 ZXMgZnJvbSB0aGUgcmVtb3RlIGFnZW50Lg0KDQpDb3JyZWN0Lg0KDQpBbmQsIGl0IGlzIG9mIGNv dXJzZSB0cnVlIGluIG9uZSBzZW5zZSwgYmVjYXVzZSBTVFVOIHJlcXVlc3RzIGNyZWF0aW5nIHBl ZXIgcmVmbGV4aXZlIGNhbmRpZGF0ZXMgY2FuIG9mIGNvdXJzZSBiZSByZWNlaXZlZCBhdCBhbnkg dGltZSA6KQ0KDQo+PiBJRiB3ZSBhcmUgZ29pbmcgdG8gcmVsYXggMzI2NCAoSSByZWFsbHkgaG9w ZSB3ZSBhcmUgTk9UKSwgaXQgbmVlZHMgdG8gDQo+PiBiZSBjbGVhcmx5IGRlc2NyaWJlZCBzb21l d2hlcmUuIFdlIGNhbm5vdCBoYXZlIGEgbnVtYmVyIG9mIEktRHMgZG9pbmcgDQo+PiBpdCAib24g dGhlIHJ1biIuLi4NCj4NCj4gSSBkb24ndCBzZWUgaG93IHRyaWNrbGUgSUNFIHdvdWxkIHJlcXVp cmUgYW55IGNoYW5nZXMgdG8gdGhlIE8vQSBtb2RlbC4NCj4gQ2FuZGlkYXRlIHRyaWNrbGluZyBz ZW1hbnRpY3MgYXJlIGNvbXBsZXRlbHkgc2VwYXJhdGUgZnJvbSB0aG9zZSBpbiAzMjY0Lg0KPg0K PiBZZXMsIHRoZSAzMjY0IG9mZmVyIG1heSwgaW4gc29tZSBjYXNlcywgY29udGFpbiBhIGZpcnN0 IGJhdGNoIG9mIGNhbmRpZGF0ZXMgYW5kIHRoZSB0aGUgMzI2NCBtYXkgaGF2ZSB0byBiZSBkZWxh eWVkIHVudGlsIElDRSBwcm9jZXNzaW5nIHlpZWxkcyB2YWxpZCBwYWlycyBmb3IgZXZlcnkgY29t cG9uZW50IGJ1dCB0aGF0J3MgYWJvdXQgaXQuDQo+DQo+IEFtIEkgbWlzc2luZyBzb21ldGhpbmc/ DQoNCkkgZ3Vlc3MgdGhlIHF1ZXN0aW9uIHdhcyB3aGV0aGVyIG9uZSwgYWZ0ZXIgdGhlIGZpcnN0 IGJhdGNoIG9mIGNhbmRpZGF0ZXMgaGF2ZSBiZWVuIHNlbnQgaW4gYW4gb2ZmZXIsIHNob3VsZCBi ZSBhbGxvd2VkIHRvIHNlbmQgdGhlIHNlY29uZCBiYXRjaCBpbiBhIG5ldyBvZmZlciAtIGJlZm9y ZSBhbiBhbnN3ZXIgdG8gdGhlIHByZXZpb3VzIG9mZmVyIGhhcyBiZWVuIHJlY2VpdmVkLiBUaGF0 IHdvdWxkIGJlIGFnYWluc3QgMzI2NC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K From christer.holmberg@ericsson.com Thu Oct 18 04:55:37 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE2D21F869F for ; Thu, 18 Oct 2012 04:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.121 X-Spam-Level: X-Spam-Status: No, score=-6.121 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjsTt+O+Fvkt for ; Thu, 18 Oct 2012 04:55:36 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2873F21F866E for ; Thu, 18 Oct 2012 04:55:35 -0700 (PDT) X-AuditID: c1b4fb25-b7f956d0000011c3-4e-507fee366852 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 62.95.04547.63EEF705; Thu, 18 Oct 2012 13:55:35 +0200 (CEST) Received: from ESESSHC001.ericsson.se (153.88.183.21) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 18 Oct 2012 13:55:35 +0200 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 13:55:34 +0200 From: Christer Holmberg To: Matthew Kaufman , "Cullen Jennings (fluffy)" Thread-Topic: Relaxing SDP O/A (was RE: [rtcweb] Agenda requests for Atlanta meeting) Thread-Index: Ac2soVaPkW4RjXahQS+tE0/0W+snswAhbkjg Date: Thu, 18 Oct 2012 11:55:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B018CD8@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.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvra75u/oAg75TfBYdk9ksZtw6y2Kx 9l87uwOzx5TfG1k9liz5yeRx68EktgDmKC6blNSczLLUIn27BK6M6y29jAXzpStO/j/F0sB4 Q7SLkZNDQsBEYseXRWwQtpjEhXvrgWwuDiGBU4wSN3bOZ4JwdjJKPDryFcpZwihx8+w3IIeD g03AQqL7nzaIKSKQIDFrWizIIGYBdYk7i8+xg4SFBcIkVj4rAQmLCIRLNP69wA5hG0nsfr6G EaSERUBV4uSsCBCTV8BbYvpSYZAKIaB5u5/sAbuMUyBRou3UVhYQmxHoyu+n1jBBLBKXuPVk PhPE9QISS/acZ4awRSVePv7HCmErSuw8284MUa8jsWD3JzYIW1ti2cLXYHFeAUGJkzOfsEDs 1ZZoWTyBfQKjxCwkK2YhaZ+FpH0WkvYFjCyrGIVzEzNz0suN9FKLMpOLi/Pz9IpTNzEC4+7g lt+qOxjvnBM5xCjNwaIkzmu9dY+/kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkan7FA/X72Q iYH73nS1Xtwg45K8/mpP03aJ3KvOxro9Yjy2U3bLnHn84Wfs4/BlMjNPVN4UfuhktN3xZe3i oC0WZiL/D2t8WRFTEm0obOLX4LmlqPbj/hOrTh5efqNbbIX+MVe1O3tfXuN1TeV7zTuvO7C2 7+i2i0feTzT/2Z04dznnpYxTeTeVWIozEg21mIuKEwGxcPpviQIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 11:55:37 -0000 Hi, I agree with Matthew. In my opinion, the default should be that JSEP O/A is aligned with RFC 3264= . Then, IF some relaxation is needed, we should look at it case by case. At t= he moment, one has to try to figure out him/herself what the relaxations ar= e. And, as the authors don't seem to think there are any relaxations in the f= irst place, I REALLY think we need to clarify this :) And, it's not only about PRANSWER - even without that there are relaxations= (as Matthew's e-mail describes). Regards, Christer -----Original Message----- From: Matthew Kaufman [mailto:matthew.kaufman@skype.net]=20 Sent: 17. lokakuuta 2012 23:25 To: Cullen Jennings (fluffy); Christer Holmberg Cc: rtcweb@ietf.org Subject: Relaxing SDP O/A (was RE: [rtcweb] Agenda requests for Atlanta mee= ting) From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Cullen Jennings (fluffy) Sent: Tuesday, October 9, 2012 7:17 AM > I have not seen any reason to relax 3264 yet but if something comes up, a= gree we should carefully look at the cases. I think we can just do straight= up > 3264. Arguments that SIP early media in a 180 is not compliant with 3= 264 are just wrong. We've *already* "relaxed" 3264's requirements in JSEP (comments apply to dr= aft-ietf-rtcweb-jsep-01) =09 Straight from 3264: "At any time, either agent MAY generate a new offer tha= t updates the session. However, it MUST NOT generate a new offer if it has = received an offer which it has not yet answered or rejected. Furthermore, i= t MUST NOT generate a new offer if it has generated a prior offer for which= it has not yet received an answer or a rejection. If an agent receives an = offer after having sent one, but before receiving an answer to it, this is = considered a "glare" condition." The JSEP API enforces no such rules. If you want to change the API to bring= it into compliance with *just this section* of 3264, it would need all sor= ts of changes... - 5.1.1 createOffer ... "Calling this method does not change state; its use= is not required". Ok, so how then is JSEP to enforce the two "MUST NOT gen= erate a new offer" is the quote from 3264 above? I would think that createO= ffer must return an error whenever the "MUST NOT" cases apply. (Never mind = that if the "use is not required" then somehow I'm to guess what SDP is leg= al for this browser to pass in to setLocalDescription as an offer?) - 5.1.4 setLocalDescription... has no language indicating that it is prohib= ited to call "setLocalDescription" with an offer and then call it again wit= h a different offer without having supplied an answer. There also appears t= o be no way to pass a "reject" in. (These two issues appear in the W3C API = state description too, so appears to really be what we mean when we say tha= t we're going to "use JSEP") - 5.1.2 createAnswer... "Calling this method does not change state; its use= is not required". So then how can setLocalDescription know when it is forb= idden to accept an "offer" passed to it (as createOffer is not required) wh= en setRemoteDescription has been passed an "offer" but "createAnswer" has n= ot yet been called? And so on. This isn't the only section of 3264 that's gone out the window with JSEP, b= ut saying "I have not seen any reason to relax 3264 yet" doesn't make any s= ense... that ship sailed when JSEP was proposed. Matthew Kaufman From emil@sip-communicator.org Thu Oct 18 05:21:11 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355B821F86B0 for ; Thu, 18 Oct 2012 05:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8+l8smuYZrT for ; Thu, 18 Oct 2012 05:21:10 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA6821F86A8 for ; Thu, 18 Oct 2012 05:21:09 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so1609915wib.13 for ; Thu, 18 Oct 2012 05:21:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=c/J5QXbz79Clg7ia86NCfw6ApUv7ttbzTExaM++oz4Y=; b=YOQX/apkGHBHDdnVkHhkiaeGtXetXE8s8SlkzDk3rpgroq4zt4FEew9SxniR6TK5ES KaIY9uXYF8QLTFXoQHiag7G+fl9anR0rP4wt1Nen2r0JV5WI++/DwgCFZmvr57ZPQPwW boB0HTry4arVxiAzCxrASZglejVNu2al2fKw/i2hS1uvbLMt5hv+FVQIqqO9IyKtRacT +mVnS8JWimipp/BfOAixtVo0KqYKNBqqZUOcN/pPFsxX5M/1C5UOMrK2Cjq/dtoitrwU 8AQnAd0FLtk0M0DyFsEzreHuYuLQ2rSuvqSPLtFRaFti2OTAbOD36mNywfVp7oa6HdNd cydg== Received: by 10.180.94.102 with SMTP id db6mr10947978wib.20.1350562869298; Thu, 18 Oct 2012 05:21:09 -0700 (PDT) Received: from pastropnet.u-strasbg.fr ([2001:660:4701:1001:d09b:d3d8:f1d4:17c4]) by mx.google.com with ESMTPS id v3sm33319513wiy.5.2012.10.18.05.21.07 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Oct 2012 05:21:08 -0700 (PDT) Message-ID: <507FF42E.5070106@jitsi.org> Date: Thu, 18 Oct 2012 14:21:02 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <50508ED7.9080805@ericsson.com> <505B6A7E.6010309@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018842@ESESSMB209.ericsson.se> <507FD1C8.8000100@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018C70@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B018C70@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmZRLqnu9eyQt2Lw+xLErUye1yRFgJ+tceAV9dkNrOw7jm38fUW74148Z9eW9KhlT8bjYJ3 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 12:21:11 -0000 Hey Christer, On 18.10.12, 13:17, Christer Holmberg wrote: > Hi, >=20 >>>> 4) How does trickle ICE work without =E2=80=9Crelaxing=E2=80=9D RFC3= 264 O/A? It >>>> seems like you really want to be able to trickle via updated >>>> offers that may be generated prior to the corresponding answer >>>> or reject? >>>=20 >>> One of my comments on the trickle draft was about that. The draft >>> says that a new offer can be sent "at any time", but my comment >>> was that it should be according to 3264. >>=20 >> That's not exactly what the draft says. What it does say is: >>=20 >> At any point of ICE processing, a trickle ICE agent may receive >> new candidates from the remote agent. >=20 > Correct. >=20 > And, it is of course true in one sense, because STUN requests > creating peer reflexive candidates can of course be received at any > time :) True but in the "Trickle ICE" case it would be more common to learn new candidates through signalling (rather than PR candidates during conn checks). This is what the text refers to. I agree we should make it clearer that we do not really mean PR candidates here. >>> IF we are going to relax 3264 (I really hope we are NOT), it >>> needs to be clearly described somewhere. We cannot have a number >>> of I-Ds doing it "on the run"... >>=20 >> I don't see how trickle ICE would require any changes to the O/A >> model. Candidate trickling semantics are completely separate from >> those in 3264. >>=20 >> Yes, the 3264 offer may, in some cases, contain a first batch of >> candidates and the the 3264 may have to be delayed until ICE >> processing yields valid pairs for every component but that's about >> it. >>=20 >> Am I missing something? >=20 > I guess the question was whether one, after the first batch of > candidates have been sent in an offer, should be allowed to send the > second batch in a new offer - before an answer to the previous offer > has been received. That would be against 3264. It would indeed but I am not sure why we would think of additional candidate drops as offers at all. They are just independent signalling and are only loosely related to the 3264 semantics. Of course with SIP we would have a problem caused by the fact that additional in-dialog signalling is blocked by the 3264 answer. However, that's specific to SIP and will probably be best served with a SIP specific solution (e.g. UPDATEs or forcing early answers, or something else). Does this make sense? Emil > Regards, >=20 > Christer >=20 --=20 https://jitsi.org From christer.holmberg@ericsson.com Thu Oct 18 05:26:58 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7BA21F86EB for ; Thu, 18 Oct 2012 05:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.122 X-Spam-Level: X-Spam-Status: No, score=-6.122 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYXf8xuM+Clb for ; Thu, 18 Oct 2012 05:26:58 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C59C421F866E for ; Thu, 18 Oct 2012 05:26:57 -0700 (PDT) X-AuditID: c1b4fb25-b7f956d0000011c3-31-507ff5904a6f Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 25.9A.04547.095FF705; Thu, 18 Oct 2012 14:26:56 +0200 (CEST) Received: from ESESSHC007.ericsson.se (153.88.183.39) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 18 Oct 2012 14:26:56 +0200 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 14:26:55 +0200 From: Christer Holmberg To: Emil Ivov Thread-Topic: [rtcweb] Filling in details on "trickle ICE" Thread-Index: Ac2XjRRR2xT3N2ETRimioq1qbE99zgVCc2oAABiJLGAAAy+oAAAG/KWg///xHAD//94bEA== Date: Thu, 18 Oct 2012 12:26:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B018D1F@ESESSMB209.ericsson.se> References: <50508ED7.9080805@ericsson.com> <505B6A7E.6010309@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018842@ESESSMB209.ericsson.se> <507FD1C8.8000100@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018C70@ESESSMB209.ericsson.se> <507FF42E.5070106@jitsi.org> In-Reply-To: <507FF42E.5070106@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGfG3VnfC1/oAg44lWhZrdk5gsdg6Vchi xq2zLBZr/7WzO7B4LNhU6rFkyU8mj/9vAj1uPZjEFsASxWWTkpqTWZZapG+XwJVx8tFctoJj MhVzOrrYGxhfSHcxcnJICJhIbJx0kh3CFpO4cG89WxcjF4eQwClGiclzJzJDODsZJVYt/cMI 4SxhlOjfsBYow8HBJmAh0f1PG6RbREBeorttEROIzSxQJTH52hxGEFtYwFJi3ccr7BA1VhI/ Fz2HssMkWn5NAathEVCVeLjlCVgvr4C3xOTFIBeB7HrPLPF+zhawBKeApsSd01/BbEagU7+f WgO1TFzi1pP5TBAvCEgs2XOeGcIWlXj5+B8rhK0osfNsO9jNzEBz1u/Sh2hVlJjS/ZAdYq+g xMmZT1hAbCEBbYmWxRPYJzBKzEKyYRZC9ywk3bOQdC9gZFnFKJybmJmTXm6kl1qUmVxcnJ+n V5y6iREYjQe3/FbdwXjnnMghRmkOFiVxXuute/yFBNITS1KzU1MLUovii0pzUosPMTJxcEo1 MCoFHXS5E7H5nD+vdkXoqwOCu3csVLM57y3SNMuxSGP7qsUbjzPJf9h+WnDKI4VDE4riDsyf 18zafu7jnU/r5x2Ld1wvwRCw7USAc4vhlurGmiuC5Vr3rvz5c2CH19JFslIzZ55tuXeFUULp ZETq3J9apfatO589mna3q3PHh6PS1mu3NguXftJWYinOSDTUYi4qTgQA9PrZrZQCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 12:26:59 -0000 SGksDQoNCj4+Pj4+IDQpIEhvdyBkb2VzIHRyaWNrbGUgSUNFIHdvcmsgd2l0aG91dCDigJxyZWxh eGluZ+KAnSBSRkMzMjY0IE8vQT8gSXQgDQo+Pj4+PiBzZWVtcyBsaWtlIHlvdSByZWFsbHkgd2Fu dCB0byBiZSBhYmxlIHRvIHRyaWNrbGUgdmlhIHVwZGF0ZWQgb2ZmZXJzIA0KPj4+Pj4gdGhhdCBt YXkgYmUgZ2VuZXJhdGVkIHByaW9yIHRvIHRoZSBjb3JyZXNwb25kaW5nIGFuc3dlciBvciByZWpl Y3Q/DQo+Pj4+IA0KPj4+PiBPbmUgb2YgbXkgY29tbWVudHMgb24gdGhlIHRyaWNrbGUgZHJhZnQg d2FzIGFib3V0IHRoYXQuIFRoZSBkcmFmdCANCj4+Pj4gc2F5cyB0aGF0IGEgbmV3IG9mZmVyIGNh biBiZSBzZW50ICJhdCBhbnkgdGltZSIsIGJ1dCBteSBjb21tZW50IHdhcyANCj4+Pj4gdGhhdCBp dCBzaG91bGQgYmUgYWNjb3JkaW5nIHRvIDMyNjQuDQo+Pj4gDQo+Pj4gVGhhdCdzIG5vdCBleGFj dGx5IHdoYXQgdGhlIGRyYWZ0IHNheXMuIFdoYXQgaXQgZG9lcyBzYXkgaXM6DQo+Pj4gDQo+Pj4g QXQgYW55IHBvaW50IG9mIElDRSBwcm9jZXNzaW5nLCBhIHRyaWNrbGUgSUNFIGFnZW50IG1heSBy ZWNlaXZlIG5ldyANCj4+PiBjYW5kaWRhdGVzIGZyb20gdGhlIHJlbW90ZSBhZ2VudC4NCj4+IA0K Pj4gQ29ycmVjdC4NCj4+IA0KPj4gQW5kLCBpdCBpcyBvZiBjb3Vyc2UgdHJ1ZSBpbiBvbmUgc2Vu c2UsIGJlY2F1c2UgU1RVTiByZXF1ZXN0cyBjcmVhdGluZyANCj4+IHBlZXIgcmVmbGV4aXZlIGNh bmRpZGF0ZXMgY2FuIG9mIGNvdXJzZSBiZSByZWNlaXZlZCBhdCBhbnkgdGltZSA6KQ0KPg0KPiBU cnVlIGJ1dCBpbiB0aGUgIlRyaWNrbGUgSUNFIiBjYXNlIGl0IHdvdWxkIGJlIG1vcmUgY29tbW9u IHRvIGxlYXJuIG5ldyBjYW5kaWRhdGVzIHRocm91Z2ggc2lnbmFsbGluZyAocmF0aGVyIHRoYW4g UFIgY2FuZGlkYXRlcyBkdXJpbmcgY29ubiBjaGVja3MpLiBUaGlzIA0KPiBpcyB3aGF0IHRoZSB0 ZXh0IHJlZmVycyB0by4gSSBhZ3JlZSB3ZSBzaG91bGQgbWFrZSBpdCBjbGVhcmVyIHRoYXQgd2Ug ZG8gbm90IHJlYWxseSBtZWFuIFBSIGNhbmRpZGF0ZXMgaGVyZS4NCg0KU3VyZS4NCg0KKFJlbWVt YmVyIG91ciBwcmV2aW91cyBkaXNjdXNzaW9uLCB0aG91Z2gsIGFib3V0IFBSIGNhbmRpZGF0ZXMg YmVpbmcgZW5vdWdoIGlmIHRoZSByZW1vdGUgcGVlciBpcyBJQ0UgbGl0ZSA7KQ0KDQo+Pj4+IElG IHdlIGFyZSBnb2luZyB0byByZWxheCAzMjY0IChJIHJlYWxseSBob3BlIHdlIGFyZSBOT1QpLCBp dCBuZWVkcyANCj4+Pj4gdG8gYmUgY2xlYXJseSBkZXNjcmliZWQgc29tZXdoZXJlLiBXZSBjYW5u b3QgaGF2ZSBhIG51bWJlciBvZiBJLURzIA0KPj4+PiBkb2luZyBpdCAib24gdGhlIHJ1biIuLi4N Cj4+PiANCj4+PiBJIGRvbid0IHNlZSBob3cgdHJpY2tsZSBJQ0Ugd291bGQgcmVxdWlyZSBhbnkg Y2hhbmdlcyB0byB0aGUgTy9BIA0KPj4+IG1vZGVsLiBDYW5kaWRhdGUgdHJpY2tsaW5nIHNlbWFu dGljcyBhcmUgY29tcGxldGVseSBzZXBhcmF0ZSBmcm9tIA0KPj4+IHRob3NlIGluIDMyNjQuDQo+ Pj4gDQo+Pj4gWWVzLCB0aGUgMzI2NCBvZmZlciBtYXksIGluIHNvbWUgY2FzZXMsIGNvbnRhaW4g YSBmaXJzdCBiYXRjaCBvZiANCj4+PiBjYW5kaWRhdGVzIGFuZCB0aGUgdGhlIDMyNjQgbWF5IGhh dmUgdG8gYmUgZGVsYXllZCB1bnRpbCBJQ0UgDQo+Pj4gcHJvY2Vzc2luZyB5aWVsZHMgdmFsaWQg cGFpcnMgZm9yIGV2ZXJ5IGNvbXBvbmVudCBidXQgdGhhdCdzIGFib3V0IA0KPj4+IGl0Lg0KPj4+ IA0KPj4+IEFtIEkgbWlzc2luZyBzb21ldGhpbmc/DQo+PiANCj4+IEkgZ3Vlc3MgdGhlIHF1ZXN0 aW9uIHdhcyB3aGV0aGVyIG9uZSwgYWZ0ZXIgdGhlIGZpcnN0IGJhdGNoIG9mIA0KPj4gY2FuZGlk YXRlcyBoYXZlIGJlZW4gc2VudCBpbiBhbiBvZmZlciwgc2hvdWxkIGJlIGFsbG93ZWQgdG8gc2Vu ZCB0aGUgDQo+PiBzZWNvbmQgYmF0Y2ggaW4gYSBuZXcgb2ZmZXIgLSBiZWZvcmUgYW4gYW5zd2Vy IHRvIHRoZSBwcmV2aW91cyBvZmZlciANCj4+IGhhcyBiZWVuIHJlY2VpdmVkLiBUaGF0IHdvdWxk IGJlIGFnYWluc3QgMzI2NC4NCj4NCj4gSXQgd291bGQgaW5kZWVkIGJ1dCBJIGFtIG5vdCBzdXJl IHdoeSB3ZSB3b3VsZCB0aGluayBvZiBhZGRpdGlvbmFsIGNhbmRpZGF0ZSBkcm9wcyBhcyBvZmZl cnMgYXQgYWxsLiBUaGV5IGFyZSBqdXN0IGluZGVwZW5kZW50IHNpZ25hbGxpbmcgYW5kIGFyZSBv bmx5IGxvb3NlbHkgcmVsYXRlZCB0byB0aGUgMzI2NCBzZW1hbnRpY3MuDQo+DQo+IE9mIGNvdXJz ZSB3aXRoIFNJUCB3ZSB3b3VsZCBoYXZlIGEgcHJvYmxlbSBjYXVzZWQgYnkgdGhlIGZhY3QgdGhh dCBhZGRpdGlvbmFsIGluLWRpYWxvZyBzaWduYWxsaW5nIGlzIGJsb2NrZWQgYnkgdGhlIDMyNjQg YW5zd2VyLiBIb3dldmVyLCB0aGF0J3Mgc3BlY2lmaWMgdG8gU0lQIGFuZCB3aWxsIHByb2JhYmx5 IA0KPiBiZSBiZXN0IHNlcnZlZCB3aXRoIGEgU0lQIHNwZWNpZmljIHNvbHV0aW9uIChlLmcuIFVQ REFURXMgb3IgZm9yY2luZyBlYXJseSBhbnN3ZXJzLCBvciBzb21ldGhpbmcgZWxzZSkuDQoNCkl0 IGlzIHN1cmUgdGhhdCBTSVAgbWF5IGFkZCBpdHMgb3duIGxpbWl0YXRpb25zLCBidXQgdGhlIGdl bmVyYWwgTy9BIGlzIGdlbmVyaWMuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQo= From emil@sip-communicator.org Thu Oct 18 05:31:08 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43FB21F8711 for ; Thu, 18 Oct 2012 05:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQWZ-FoUwK4H for ; Thu, 18 Oct 2012 05:31:08 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAE521F8701 for ; Thu, 18 Oct 2012 05:31:07 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so1668889wib.13 for ; Thu, 18 Oct 2012 05:31:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=QyM8q6ivlmKgeG3C/AQDNC3g7WPSpQ8rU3I6VuEeEZE=; b=BSblSM8xVnefO932GtpZU+9+DT9aZ84s5PpNZqpXDsxNnwgB6R++BgfXmvLvteu13f AihS1xQVZMGDqlpmK8dYBoPNHNSdXYVOd9PWYy8wHohhbvBp5xXfBGkiQGYD2ijCyH6z LMV9W4P11cCj0xSmLt5Pmz/60H5WQMyrW4+8a5Vkl+oCvbo0qiFmlv21G86pKaJIa/Yq 2LWY7r9wNi27MnX8Wjql9TrzAaQ5KED4PIVJcgKYhTtuHk5NXkQN4EY4gIIYKnXNYr8Z 5hDI+siO5XkhAACg4thk+/EndmZy8kRX6l/ta6QV1Wa1wGa3l/o+wG5ZYS6We9lCHBJf RiQQ== Received: by 10.181.13.208 with SMTP id fa16mr11055543wid.11.1350563466733; Thu, 18 Oct 2012 05:31:06 -0700 (PDT) Received: from pastropnet.u-strasbg.fr ([2001:660:4701:1001:d09b:d3d8:f1d4:17c4]) by mx.google.com with ESMTPS id w8sm29340154wif.4.2012.10.18.05.31.05 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Oct 2012 05:31:05 -0700 (PDT) Message-ID: <507FF688.2010704@jitsi.org> Date: Thu, 18 Oct 2012 14:31:04 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <50508ED7.9080805@ericsson.com> <505B6A7E.6010309@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018842@ESESSMB209.ericsson.se> <507FD1C8.8000100@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018C70@ESESSMB209.ericsson.se> <507FF42E.5070106@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018D1F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B018D1F@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkFcXeRCgzkTsPRLcIQKGRG7FbS8swt7FlDStK9zLkwC3MqEeTwEQyWw21RtBJCVRmUmFCr Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 12:31:08 -0000 On 18.10.12, 14:26, Christer Holmberg wrote: > Hi, >=20 >>>>>> 4) How does trickle ICE work without =E2=80=9Crelaxing=E2=80=9D RF= C3264 >>>>>> O/A? It seems like you really want to be able to trickle >>>>>> via updated offers that may be generated prior to the >>>>>> corresponding answer or reject? >>>>>=20 >>>>> One of my comments on the trickle draft was about that. The >>>>> draft says that a new offer can be sent "at any time", but my >>>>> comment was that it should be according to 3264. >>>>=20 >>>> That's not exactly what the draft says. What it does say is: >>>>=20 >>>> At any point of ICE processing, a trickle ICE agent may receive >>>> new candidates from the remote agent. >>>=20 >>> Correct. >>>=20 >>> And, it is of course true in one sense, because STUN requests >>> creating peer reflexive candidates can of course be received at >>> any time :) >>=20 >> True but in the "Trickle ICE" case it would be more common to learn >> new candidates through signalling (rather than PR candidates during >> conn checks). This is what the text refers to. I agree we should >> make it clearer that we do not really mean PR candidates here. >=20 > Sure. >=20 > (Remember our previous discussion, though, about PR candidates being > enough if the remote peer is ICE lite ;) I do :). >>>>> IF we are going to relax 3264 (I really hope we are NOT), it >>>>> needs to be clearly described somewhere. We cannot have a >>>>> number of I-Ds doing it "on the run"... >>>>=20 >>>> I don't see how trickle ICE would require any changes to the >>>> O/A model. Candidate trickling semantics are completely >>>> separate from those in 3264. >>>>=20 >>>> Yes, the 3264 offer may, in some cases, contain a first batch >>>> of candidates and the the 3264 may have to be delayed until ICE >>>> processing yields valid pairs for every component but that's >>>> about it. >>>>=20 >>>> Am I missing something? >>>=20 >>> I guess the question was whether one, after the first batch of=20 >>> candidates have been sent in an offer, should be allowed to send >>> the second batch in a new offer - before an answer to the >>> previous offer has been received. That would be against 3264. >>=20 >> It would indeed but I am not sure why we would think of additional >> candidate drops as offers at all. They are just independent >> signalling and are only loosely related to the 3264 semantics. >>=20 >> Of course with SIP we would have a problem caused by the fact that >> additional in-dialog signalling is blocked by the 3264 answer. >> However, that's specific to SIP and will probably be best served >> with a SIP specific solution (e.g. UPDATEs or forcing early >> answers, or something else). >=20 > It is sure that SIP may add its own limitations, but the general O/A > is generic. Sure, and we agree that the general O/A need not be used for trickle ICE, right? Emil --=20 https://jitsi.org From christer.holmberg@ericsson.com Thu Oct 18 05:34:15 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8D421F84C5 for ; Thu, 18 Oct 2012 05:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.123 X-Spam-Level: X-Spam-Status: No, score=-6.123 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCthg7sDdyIu for ; Thu, 18 Oct 2012 05:34:14 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B85AC21F869A for ; Thu, 18 Oct 2012 05:34:13 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-eb-507ff7440c6a Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 7F.EA.17130.447FF705; Thu, 18 Oct 2012 14:34:12 +0200 (CEST) Received: from ESESSHC017.ericsson.se (153.88.183.69) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 18 Oct 2012 14:34:11 +0200 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 14:34:11 +0200 From: Christer Holmberg To: Emil Ivov Thread-Topic: [rtcweb] Filling in details on "trickle ICE" Thread-Index: Ac2XjRRR2xT3N2ETRimioq1qbE99zgVCc2oAABiJLGAAAy+oAAAG/KWg///xHAD//94bEIAAJLMA///eFjA= Date: Thu, 18 Oct 2012 12:34:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B018D4B@ESESSMB209.ericsson.se> References: <50508ED7.9080805@ericsson.com> <505B6A7E.6010309@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018842@ESESSMB209.ericsson.se> <507FD1C8.8000100@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018C70@ESESSMB209.ericsson.se> <507FF42E.5070106@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018D1F@ESESSMB209.ericsson.se> <507FF688.2010704@jitsi.org> In-Reply-To: <507FF688.2010704@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM+Jvra7L9/oAg38/FSzW7JzAYrF1qpDF jFtnWSzW/mtnd2DxWLCp1GPJkp9MHv/fBHrcejCJLYAlissmJTUnsyy1SN8ugStj9bTfrAVL hCsenNjN1MD4RKiLkZNDQsBE4teXaUwQtpjEhXvr2boYuTiEBE4xSnyc8okVJCEksJNR4tG7 TIjEEqDE83agDg4ONgELie5/2iA1IgLyEt1ti8AGMQtUSUy+NocRxBYWsJRY9/EKO0SNlcTP Rc+h7CSJGZ/aGUHGsAioStz/DLaKV8Bb4sTlfewQqy6wSFzv+Q6W4BTQlDg4+zDYfEagQ7+f WgO1S1zi1pP5UA8ISCzZc54ZwhaVePn4HyuErSix82w7M8guZqA563fpQ7QqSkzpfsgOsVdQ 4uTMJywQ72pLtCyewD6BUWIWkg2zELpnIemehaR7ASPLKkbh3MTMnPRyc73Uoszk4uL8PL3i 1E2MwEg8uOW3wQ7GTffFDjFKc7AoifPqqe73FxJITyxJzU5NLUgtii8qzUktPsTIxMEp1cAo 0jpP+4fmp3kldyNM20KaQtXaTOdOe+J6g28rc2eq/uaAwwYzLk3tTDXjOW/eqSzGO7/wfyv7 5cntiXZNhnWB3RrfPFY/P/d+ytVV7zRyNk+fXiHUNVl6Xu3HzuPFod9W3u+RapLRrjNuLmK8 s7dnys/0KTffmj2Zku/tNF/8H7P1hA7OhapKLMUZiYZazEXFiQAUEidLkgIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 12:34:15 -0000 SGksDQoNCj4+Pj4+PiBJRiB3ZSBhcmUgZ29pbmcgdG8gcmVsYXggMzI2NCAoSSByZWFsbHkgaG9w ZSB3ZSBhcmUgTk9UKSwgaXQgbmVlZHMgDQo+Pj4+Pj4gdG8gYmUgY2xlYXJseSBkZXNjcmliZWQg c29tZXdoZXJlLiBXZSBjYW5ub3QgaGF2ZSBhIG51bWJlciBvZiBJLURzIA0KPj4+Pj4+IGRvaW5n IGl0ICJvbiB0aGUgcnVuIi4uLg0KPj4+Pj4gDQo+Pj4+PiBJIGRvbid0IHNlZSBob3cgdHJpY2ts ZSBJQ0Ugd291bGQgcmVxdWlyZSBhbnkgY2hhbmdlcyB0byB0aGUgTy9BIA0KPj4+Pj4gbW9kZWwu IENhbmRpZGF0ZSB0cmlja2xpbmcgc2VtYW50aWNzIGFyZSBjb21wbGV0ZWx5IHNlcGFyYXRlIGZy b20gDQo+Pj4+PiB0aG9zZSBpbiAzMjY0Lg0KPj4+Pj4gDQo+Pj4+PiBZZXMsIHRoZSAzMjY0IG9m ZmVyIG1heSwgaW4gc29tZSBjYXNlcywgY29udGFpbiBhIGZpcnN0IGJhdGNoIG9mIA0KPj4+Pj4g Y2FuZGlkYXRlcyBhbmQgdGhlIHRoZSAzMjY0IG1heSBoYXZlIHRvIGJlIGRlbGF5ZWQgdW50aWwg SUNFICANCj4+Pj4+IHByb2Nlc3NpbmcgeWllbGRzIHZhbGlkIHBhaXJzIGZvciBldmVyeSBjb21w b25lbnQgYnV0IHRoYXQncyBhYm91dCANCj4+Pj4+IGl0Lg0KPj4+Pj4gDQo+Pj4+PiBBbSBJIG1p c3Npbmcgc29tZXRoaW5nPw0KPj4+PiANCj4+Pj4gSSBndWVzcyB0aGUgcXVlc3Rpb24gd2FzIHdo ZXRoZXIgb25lLCBhZnRlciB0aGUgZmlyc3QgYmF0Y2ggb2YgDQo+Pj4+IGNhbmRpZGF0ZXMgaGF2 ZSBiZWVuIHNlbnQgaW4gYW4gb2ZmZXIsIHNob3VsZCBiZSBhbGxvd2VkIHRvIHNlbmQgdGhlIA0K Pj4+PiBzZWNvbmQgYmF0Y2ggaW4gYSBuZXcgb2ZmZXIgLSBiZWZvcmUgYW4gYW5zd2VyIHRvIHRo ZSBwcmV2aW91cyBvZmZlciANCj4+Pj4gaGFzIGJlZW4gcmVjZWl2ZWQuIFRoYXQgd291bGQgYmUg YWdhaW5zdCAzMjY0Lg0KPj4+IA0KPj4+IEl0IHdvdWxkIGluZGVlZCBidXQgSSBhbSBub3Qgc3Vy ZSB3aHkgd2Ugd291bGQgdGhpbmsgb2YgYWRkaXRpb25hbCANCj4+PiBjYW5kaWRhdGUgZHJvcHMg YXMgb2ZmZXJzIGF0IGFsbC4gVGhleSBhcmUganVzdCBpbmRlcGVuZGVudCANCj4+PiBzaWduYWxs aW5nIGFuZCBhcmUgb25seSBsb29zZWx5IHJlbGF0ZWQgdG8gdGhlIDMyNjQgc2VtYW50aWNzLg0K Pj4+IA0KPj4+IE9mIGNvdXJzZSB3aXRoIFNJUCB3ZSB3b3VsZCBoYXZlIGEgcHJvYmxlbSBjYXVz ZWQgYnkgdGhlIGZhY3QgdGhhdCANCj4+PiBhZGRpdGlvbmFsIGluLWRpYWxvZyBzaWduYWxsaW5n IGlzIGJsb2NrZWQgYnkgdGhlIDMyNjQgYW5zd2VyLg0KPj4+IEhvd2V2ZXIsIHRoYXQncyBzcGVj aWZpYyB0byBTSVAgYW5kIHdpbGwgcHJvYmFibHkgYmUgYmVzdCBzZXJ2ZWQgd2l0aCANCj4+PiBh IFNJUCBzcGVjaWZpYyBzb2x1dGlvbiAoZS5nLiBVUERBVEVzIG9yIGZvcmNpbmcgZWFybHkgYW5z d2Vycywgb3IgDQo+Pj4gc29tZXRoaW5nIGVsc2UpLg0KPj4gDQo+PiBJdCBpcyBzdXJlIHRoYXQg U0lQIG1heSBhZGQgaXRzIG93biBsaW1pdGF0aW9ucywgYnV0IHRoZSBnZW5lcmFsIE8vQSANCj4+ IGlzIGdlbmVyaWMuDQo+DQo+IFN1cmUsIGFuZCB3ZSBhZ3JlZSB0aGF0IHRoZSBnZW5lcmFsIE8v QSBuZWVkIG5vdCBiZSB1c2VkIGZvciB0cmlja2xlIElDRSwgcmlnaHQ/DQoNCldlbGwsIEkgdGhp bmsgZ2VuZXJhbCBPL0EgU0hBTEwgYmUgdXNlZCAtIG5vdCBvbmx5IGZvciB0cmlja2xlIElDRSwg YnV0IGFsc28gZm9yIEpTRVAgOikNCg0KKFZhbmlsbGEgSUNFIGlzIGFsc28gdXNpbmcgZ2VuZXJh bCBPL0EpDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From emil@sip-communicator.org Thu Oct 18 05:53:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2724521F874A for ; Thu, 18 Oct 2012 05:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuOqdTKrTFTC for ; Thu, 18 Oct 2012 05:53:13 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id EF54321F873D for ; Thu, 18 Oct 2012 05:53:12 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so5588663wey.31 for ; Thu, 18 Oct 2012 05:53:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=Vgyqv+EJ+kXCtyDYEYSB8etmIS0eoXkeXzsEcOJW8SQ=; b=ND3gCho76fBp0/H3nF6x4cY2ug8WwivH0Kk8whYHz3QCGiRIdCuiRb317u8frw+7jG nzcnJket0BGfs5f01W1SsTiSUW14Vo+uqaGQ8BTJ0EM9VgJwZiH0pv3S5bPy7UjwhQzk QNpNCb/LvK5k9MRWtVl/v9T1i/CYq4pyLDpjMIJ3N/CrYQf/T7d87I6RZe7CmEGpwNLg yYpQ3zIsw9oda4CDYUu2uFzaZPfO2iWyBrBjAq3o5oc/QvnC6iNVEvuncUfMl/uZOHDa zPyQk+FFKWPc6s3z/lFdfuQABwkhXdCMAvtLicycQlY8Rx/xcgQIZtabyqs78y4DmJ7J jZvQ== Received: by 10.180.77.34 with SMTP id p2mr11228655wiw.0.1350564792024; Thu, 18 Oct 2012 05:53:12 -0700 (PDT) Received: from pastropnet.u-strasbg.fr ([2001:660:4701:1001:d09b:d3d8:f1d4:17c4]) by mx.google.com with ESMTPS id j8sm29463260wiy.9.2012.10.18.05.53.10 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Oct 2012 05:53:11 -0700 (PDT) Message-ID: <507FFBB5.4080904@jitsi.org> Date: Thu, 18 Oct 2012 14:53:09 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <50508ED7.9080805@ericsson.com> <505B6A7E.6010309@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018842@ESESSMB209.ericsson.se> <507FD1C8.8000100@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018C70@ESESSMB209.ericsson.se> <507FF42E.5070106@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018D1F@ESESSMB209.ericsson.se> <507FF688.2010704@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018D4B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B018D4B@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnqET24sNmgPxy1u2FGNwmWFlBnZOr2fbz5EqyZsH0xVHmzx1L3BMBoO49utYKUG+YSytnL Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 12:53:14 -0000 Hey Christer, On 18.10.12, 14:34, Christer Holmberg wrote: > Hi, > >>>>>>> IF we are going to relax 3264 (I really hope we are NOT), it needs >>>>>>> to be clearly described somewhere. We cannot have a number of I-Ds >>>>>>> doing it "on the run"... >>>>>> >>>>>> I don't see how trickle ICE would require any changes to the O/A >>>>>> model. Candidate trickling semantics are completely separate from >>>>>> those in 3264. >>>>>> >>>>>> Yes, the 3264 offer may, in some cases, contain a first batch of >>>>>> candidates and the the 3264 may have to be delayed until ICE >>>>>> processing yields valid pairs for every component but that's about >>>>>> it. >>>>>> >>>>>> Am I missing something? >>>>> >>>>> I guess the question was whether one, after the first batch of >>>>> candidates have been sent in an offer, should be allowed to send the >>>>> second batch in a new offer - before an answer to the previous offer >>>>> has been received. That would be against 3264. >>>> >>>> It would indeed but I am not sure why we would think of additional >>>> candidate drops as offers at all. They are just independent >>>> signalling and are only loosely related to the 3264 semantics. >>>> >>>> Of course with SIP we would have a problem caused by the fact that >>>> additional in-dialog signalling is blocked by the 3264 answer. >>>> However, that's specific to SIP and will probably be best served with >>>> a SIP specific solution (e.g. UPDATEs or forcing early answers, or >>>> something else). >>> >>> It is sure that SIP may add its own limitations, but the general O/A >>> is generic. >> >> Sure, and we agree that the general O/A need not be used for trickle ICE, right? > > Well, I think general O/A SHALL be used - not only for trickle ICE, But why? What do we get from trickling via offers and answers other than problems? Or did you mean that > but also for JSEP :) > > (Vanilla ICE is also using general O/A) Not really. At least not always. ICE is quite nicely separated from the media O/A in XMPP. Both are indeed stuffed together for SIP by 5245 but that's just a design choice that we don't need to stick with. At least I don't see why we would. Emil -- https://jitsi.org From christer.holmberg@ericsson.com Thu Oct 18 06:03:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB7021F8417 for ; Thu, 18 Oct 2012 06:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.124 X-Spam-Level: X-Spam-Status: No, score=-6.124 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BWXxRGioXFQ for ; Thu, 18 Oct 2012 06:03:31 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5997A21F8658 for ; Thu, 18 Oct 2012 06:03:21 -0700 (PDT) X-AuditID: c1b4fb25-b7f956d0000011c3-f0-507ffe1819f4 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B2.E0.04547.81EFF705; Thu, 18 Oct 2012 15:03:20 +0200 (CEST) Received: from ESESSHC006.ericsson.se (153.88.183.36) by esessmw0247.eemea.ericsson.se (153.88.115.93) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 18 Oct 2012 15:03:20 +0200 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 15:03:19 +0200 From: Christer Holmberg To: Emil Ivov Thread-Topic: [rtcweb] Filling in details on "trickle ICE" Thread-Index: Ac2XjRRR2xT3N2ETRimioq1qbE99zgVCc2oAABiJLGAAAy+oAAAG/KWg///xHAD//94bEIAAJLMA///eFjCAACgVgP//3hxA Date: Thu, 18 Oct 2012 13:03:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B018DA9@ESESSMB209.ericsson.se> References: <50508ED7.9080805@ericsson.com> <505B6A7E.6010309@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018842@ESESSMB209.ericsson.se> <507FD1C8.8000100@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018C70@ESESSMB209.ericsson.se> <507FF42E.5070106@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018D1F@ESESSMB209.ericsson.se> <507FF688.2010704@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018D4B@ESESSMB209.ericsson.se> <507FFBB5.4080904@jitsi.org> In-Reply-To: <507FFBB5.4080904@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGfG3VlfiX32AQeNSSYs1OyewWGydKmQx 49ZZFou1/9rZHVg8Fmwq9Viy5CeTx/83gR63HkxiC2CJ4rJJSc3JLEst0rdL4Mpou/6fqeCG VMXWr+tZGxgbpLoYOTkkBEwkOi7fY4awxSQu3FvP1sXIxSEkcIpR4vblBVDOTkaJvqXfWSGc JYwSp2YtBWrh4GATsJDo/qcN0i0iIC/R3baICcRmFqiSmHxtDiOILSxgKbHu4xV2iBoriZ+L nkPZeRLP1pxkAbFZBFQlzjX3gtm8At4SB+Y1MEPs2sgqcXzjVrDzOAU0JTrn/AIbygh06vdT a6CWiUvcejKfCeIFAYkle85DvSMq8fLxP1YIW1Fi59l2sJuZgeas36UP0aooMaX7ITvEXkGJ kzOfgN0gJKAt0bJ4AvsERolZSDbMQuiehaR7FpLuBYwsqxiFcxMzc9LLjfRSizKTi4vz8/SK UzcxAqPx4JbfqjsY75wTOcQozcGiJM5rvXWPv5BAemJJanZqakFqUXxRaU5q8SFGJg5OqQbG xKfZt97kWkhp9Yj82PFDyPP8L++tEo52vtodR+4znuybNX3Tqqr3BW+jJXxtxSQ49j94HKCy /Pd05q8ef1WnswbcEdM8eKyYV/n4dQbXBR1f3JJ3H3x96NglN97Pweckf6W/8LtSs/ryyW+R /29tYq7xvZl7zGSffTD7vVLh6qk8VyT8K6YtVGIpzkg01GIuKk4EAFfjnjaUAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 13:03:31 -0000 SGksDQoNCj4+Pj4+Pj4+IElGIHdlIGFyZSBnb2luZyB0byByZWxheCAzMjY0IChJIHJlYWxseSBo b3BlIHdlIGFyZSBOT1QpLCBpdCANCj4+Pj4+Pj4+IG5lZWRzIHRvIGJlIGNsZWFybHkgZGVzY3Jp YmVkIHNvbWV3aGVyZS4gV2UgY2Fubm90IGhhdmUgYSBudW1iZXIgDQo+Pj4+Pj4+PiBvZiBJLURz IGRvaW5nIGl0ICJvbiB0aGUgcnVuIi4uLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBJIGRvbid0IHNlZSBo b3cgdHJpY2tsZSBJQ0Ugd291bGQgcmVxdWlyZSBhbnkgY2hhbmdlcyB0byB0aGUgTy9BIA0KPj4+ Pj4+PiBtb2RlbC4gQ2FuZGlkYXRlIHRyaWNrbGluZyBzZW1hbnRpY3MgYXJlIGNvbXBsZXRlbHkg c2VwYXJhdGUgZnJvbSANCj4+Pj4+Pj4gdGhvc2UgaW4gMzI2NC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4g WWVzLCB0aGUgMzI2NCBvZmZlciBtYXksIGluIHNvbWUgY2FzZXMsIGNvbnRhaW4gYSBmaXJzdCBi YXRjaCBvZiANCj4+Pj4+Pj4gY2FuZGlkYXRlcyBhbmQgdGhlIHRoZSAzMjY0IG1heSBoYXZlIHRv IGJlIGRlbGF5ZWQgdW50aWwgSUNFIA0KPj4+Pj4+PiBwcm9jZXNzaW5nIHlpZWxkcyB2YWxpZCBw YWlycyBmb3IgZXZlcnkgY29tcG9uZW50IGJ1dCB0aGF0J3MgDQo+Pj4+Pj4+IGFib3V0IGl0Lg0K Pj4+Pj4+Pg0KPj4+Pj4+PiBBbSBJIG1pc3Npbmcgc29tZXRoaW5nPw0KPj4+Pj4+DQo+Pj4+Pj4g SSBndWVzcyB0aGUgcXVlc3Rpb24gd2FzIHdoZXRoZXIgb25lLCBhZnRlciB0aGUgZmlyc3QgYmF0 Y2ggb2YgDQo+Pj4+Pj4gY2FuZGlkYXRlcyBoYXZlIGJlZW4gc2VudCBpbiBhbiBvZmZlciwgc2hv dWxkIGJlIGFsbG93ZWQgdG8gc2VuZCANCj4+Pj4+PiB0aGUgc2Vjb25kIGJhdGNoIGluIGEgbmV3 IG9mZmVyIC0gYmVmb3JlIGFuIGFuc3dlciB0byB0aGUgcHJldmlvdXMgDQo+Pj4+Pj4gb2ZmZXIg aGFzIGJlZW4gcmVjZWl2ZWQuIFRoYXQgd291bGQgYmUgYWdhaW5zdCAzMjY0Lg0KPj4+Pj4NCj4+ Pj4+IEl0IHdvdWxkIGluZGVlZCBidXQgSSBhbSBub3Qgc3VyZSB3aHkgd2Ugd291bGQgdGhpbmsg b2YgYWRkaXRpb25hbCANCj4+Pj4+IGNhbmRpZGF0ZSBkcm9wcyBhcyBvZmZlcnMgYXQgYWxsLiBU aGV5IGFyZSBqdXN0IGluZGVwZW5kZW50IA0KPj4+Pj4gc2lnbmFsbGluZyBhbmQgYXJlIG9ubHkg bG9vc2VseSByZWxhdGVkIHRvIHRoZSAzMjY0IHNlbWFudGljcy4NCj4+Pj4+DQo+Pj4+PiBPZiBj b3Vyc2Ugd2l0aCBTSVAgd2Ugd291bGQgaGF2ZSBhIHByb2JsZW0gY2F1c2VkIGJ5IHRoZSBmYWN0 IHRoYXQgDQo+Pj4+PiBhZGRpdGlvbmFsIGluLWRpYWxvZyBzaWduYWxsaW5nIGlzIGJsb2NrZWQg YnkgdGhlIDMyNjQgYW5zd2VyLg0KPj4+Pj4gSG93ZXZlciwgdGhhdCdzIHNwZWNpZmljIHRvIFNJ UCBhbmQgd2lsbCBwcm9iYWJseSBiZSBiZXN0IHNlcnZlZCANCj4+Pj4+IHdpdGggYSBTSVAgc3Bl Y2lmaWMgc29sdXRpb24gKGUuZy4gVVBEQVRFcyBvciBmb3JjaW5nIGVhcmx5IA0KPj4+Pj4gYW5z d2Vycywgb3Igc29tZXRoaW5nIGVsc2UpLg0KPj4+Pg0KPj4+PiBJdCBpcyBzdXJlIHRoYXQgU0lQ IG1heSBhZGQgaXRzIG93biBsaW1pdGF0aW9ucywgYnV0IHRoZSBnZW5lcmFsIE8vQSANCj4+Pj4g aXMgZ2VuZXJpYy4NCj4+Pg0KPj4+IFN1cmUsIGFuZCB3ZSBhZ3JlZSB0aGF0IHRoZSBnZW5lcmFs IE8vQSBuZWVkIG5vdCBiZSB1c2VkIGZvciB0cmlja2xlIElDRSwgcmlnaHQ/DQo+PiANCj4+IFdl bGwsIEkgdGhpbmsgZ2VuZXJhbCBPL0EgU0hBTEwgYmUgdXNlZCAtIG5vdCBvbmx5IGZvciB0cmlj a2xlIElDRSwNCj4NCj4gQnV0IHdoeT8gV2hhdCBkbyB3ZSBnZXQgZnJvbSB0cmlja2xpbmcgdmlh IG9mZmVycyBhbmQgYW5zd2VycyBvdGhlciB0aGFuIHByb2JsZW1zPw0KPg0KPiBPciBkaWQgeW91 IG1lYW4gdGhhdA0KPg0KPj4gYnV0IGFsc28gZm9yIEpTRVAgOikNCj4+IA0KPj4gKFZhbmlsbGEg SUNFIGlzIGFsc28gdXNpbmcgZ2VuZXJhbCBPL0EpDQo+DQo+IE5vdCByZWFsbHkuIEF0IGxlYXN0 IG5vdCBhbHdheXMuIElDRSBpcyBxdWl0ZSBuaWNlbHkgc2VwYXJhdGVkIGZyb20gdGhlIG1lZGlh IE8vQSBpbiBYTVBQLg0KPg0KPiBCb3RoIGFyZSBpbmRlZWQgc3R1ZmZlZCB0b2dldGhlciBmb3Ig U0lQIGJ5IDUyNDUgYnV0IHRoYXQncyBqdXN0IGEgZGVzaWduIGNob2ljZSB0aGF0IHdlIGRvbid0 IG5lZWQgdG8gc3RpY2sgd2l0aC4gQXQgbGVhc3QgSSBkb24ndCBzZWUgd2h5IHdlIHdvdWxkLg0K DQpJIHdhcyB0aGlua2luZyBhYm91dCA1MjQ1LCBhbmQgSlNFUCwgYm90aCB3aXRoIHVzZSAzMjY0 Lg0KDQpZb3UgYXJlIHJpZ2h0IHRoYXQgb3RoZXIgcHJvdG9jb2xzIChlLmcuIFhNUFApIGFsc28g Y2FuIHVzZSBJQ0UuIEhvd2V2ZXIsIHlvdSBkbyB1c2UgIk9mZmVyIiBhbmQgIkFuc3dlciIgdGVy bWlub2xvZ3kgaW4geW91ciBkcmFmdCwgYW5kIGF0IGxlYXN0IEkgYXNzb2NpYXRlIHRoYXQgd2l0 aCAzMjY0Li4uDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCg0K From harald@alvestrand.no Thu Oct 18 06:44:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7F821F84E2 for ; Thu, 18 Oct 2012 06:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.424 X-Spam-Level: X-Spam-Status: No, score=-110.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23xQb0V4FHlM for ; Thu, 18 Oct 2012 06:44:45 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 28B0D21F8720 for ; Thu, 18 Oct 2012 06:44:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 40DE439E0F3 for ; Thu, 18 Oct 2012 15:44:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lJ10Qs1fdhX for ; Thu, 18 Oct 2012 15:44:41 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 58BA739E04C for ; Thu, 18 Oct 2012 15:44:41 +0200 (CEST) Message-ID: <508007C8.7070508@alvestrand.no> Date: Thu, 18 Oct 2012 15:44:40 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 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 Subject: Re: [rtcweb] SVC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 13:44:46 -0000 On 10/16/2012 07:35 PM, Bernard Aboba wrote: > Some chipsets do support temporal scaling (search 'soc support for H.264/SVC'), and there are sw implementations that support temporal, quality and spatial scaling ( http://www.polycom.com/company/news/press-releases/2012/20121004.html). I did search for what you suggested, but what came up seemed to be software running on System-on-a-chip processors (eInfochips' C library from 2009, an IEEE Explore article detailing an implementation running on a Linux system with a DSP). Your search results may be different. These may have satisfactory performance - using DSPs for video codec tasks kind of blurs the distinction between "hardware implementation" and "software implementation". But I guess that the more the processors are general purpose, the less it matters which particular codec you choose to implement on them - so they become irrelevant to whether a particular codec has "hardware support". Harald From emil@sip-communicator.org Thu Oct 18 06:58:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C80021F8780 for ; Thu, 18 Oct 2012 06:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmnZe722fdyU for ; Thu, 18 Oct 2012 06:58:09 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2C53A21F877F for ; Thu, 18 Oct 2012 06:58:08 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so5631753wey.31 for ; Thu, 18 Oct 2012 06:58:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=JIVl6Oypq85mYH6asWRKnj80F1yvZcBxybfEfpoCwmQ=; b=XuSZPy/NTv6aIPuzockZv67jUArZymQuMGXsRiqv/VpzAqwZe/paogEsiSLJfKFKK+ 0BAWnHGf+zCFsZCFkbrjt2b+DTHryMPSq6cQL3tFgmRBAdxu2W5B/kZIQFwWA6zBpiUO k+G/1sykp7vVg4GTIGwPae1x88tXOL8jVPWIVGhvP7J/fGYrvIfCwswhBgKBx8n+TCc/ +Ws+CnfF0S+fYlsAZ496q2WqF2W0T3rIkn+abjhtdCT3dptDQMKz3XQp7CIVvUPjD6F1 b2MMye0KL8r5BwbMxB+4cAUe83bwtPd6uIcQntiUXCu4r4rhKehYHO4d6UVxxakYIYkk Jaow== Received: by 10.180.79.34 with SMTP id g2mr11557793wix.19.1350568687542; Thu, 18 Oct 2012 06:58:07 -0700 (PDT) Received: from pastropnet.u-strasbg.fr (pastropnet.u-strasbg.fr. [130.79.90.87]) by mx.google.com with ESMTPS id q7sm33843750wiy.11.2012.10.18.06.58.05 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Oct 2012 06:58:05 -0700 (PDT) Message-ID: <50800AEC.2070400@jitsi.org> Date: Thu, 18 Oct 2012 15:58:04 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <50508ED7.9080805@ericsson.com> <505B6A7E.6010309@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018842@ESESSMB209.ericsson.se> <507FD1C8.8000100@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018C70@ESESSMB209.ericsson.se> <507FF42E.5070106@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018D1F@ESESSMB209.ericsson.se> <507FF688.2010704@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018D4B@ESESSMB209.ericsson.se> <507FFBB5.4080904@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018DA9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B018DA9@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnFA4OVb86TJIOZmeVgZkWeHql9ZfWpAkvpG2BBhS/ZwQ0YEU7/sYOsa3gs9MhPN6+dpL2R Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 13:58:10 -0000 Hey Christer, On 18.10.12, 15:03, Christer Holmberg wrote: > Hi, > >>>>>>>>> IF we are going to relax 3264 (I really hope we are NOT), it >>>>>>>>> needs to be clearly described somewhere. We cannot have a number >>>>>>>>> of I-Ds doing it "on the run"... >>>>>>>> >>>>>>>> I don't see how trickle ICE would require any changes to the O/A >>>>>>>> model. Candidate trickling semantics are completely separate from >>>>>>>> those in 3264. >>>>>>>> >>>>>>>> Yes, the 3264 offer may, in some cases, contain a first batch of >>>>>>>> candidates and the the 3264 may have to be delayed until ICE >>>>>>>> processing yields valid pairs for every component but that's >>>>>>>> about it. >>>>>>>> >>>>>>>> Am I missing something? >>>>>>> >>>>>>> I guess the question was whether one, after the first batch of >>>>>>> candidates have been sent in an offer, should be allowed to send >>>>>>> the second batch in a new offer - before an answer to the previous >>>>>>> offer has been received. That would be against 3264. >>>>>> >>>>>> It would indeed but I am not sure why we would think of additional >>>>>> candidate drops as offers at all. They are just independent >>>>>> signalling and are only loosely related to the 3264 semantics. >>>>>> >>>>>> Of course with SIP we would have a problem caused by the fact that >>>>>> additional in-dialog signalling is blocked by the 3264 answer. >>>>>> However, that's specific to SIP and will probably be best served >>>>>> with a SIP specific solution (e.g. UPDATEs or forcing early >>>>>> answers, or something else). >>>>> >>>>> It is sure that SIP may add its own limitations, but the general O/A >>>>> is generic. >>>> >>>> Sure, and we agree that the general O/A need not be used for trickle ICE, right? >>> >>> Well, I think general O/A SHALL be used - not only for trickle ICE, >> >> But why? What do we get from trickling via offers and answers other than problems? >> >> Or did you mean that >> >>> but also for JSEP :) >>> >>> (Vanilla ICE is also using general O/A) >> >> Not really. At least not always. ICE is quite nicely separated from the media O/A in XMPP. >> >> Both are indeed stuffed together for SIP by 5245 but that's just a design choice that we don't need to stick with. At least I don't see why we would. > > I was thinking about 5245, and JSEP, both with use 3264. > > You are right that other protocols (e.g. XMPP) also can use ICE. However, you do use "Offer" and "Answer" terminology in your draft, and at least I associate that with 3264... Yes, but I already agreed that the term was somewhat abused and we need to review that. We may probably just switch to calling them ICE initiation request/response ... or something along those lines. We will do this in the 01 version which should be coming later this week. Cheers, Emil -- https://jitsi.org From ted.ietf@gmail.com Thu Oct 18 07:52:09 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0173621F8797 for ; Thu, 18 Oct 2012 07:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-S-zUqUpwX7 for ; Thu, 18 Oct 2012 07:52:08 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 578BB21F878A for ; Thu, 18 Oct 2012 07:52:08 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so9892240vbb.31 for ; Thu, 18 Oct 2012 07:52:07 -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=W7uo1r3cBUY/KKBVzGRiMbnuoVrP9Slq92OkDmHfIyg=; b=ApjjagujXrt9jGI8U0qdvtlOcUHjRQRFf2SBasXEbPxi60P3py9PTgHmmPlqSc3ryl FT/vjloap1W4QZ11JwYTZEpL4Ghqo2NKLAgr7JFN9owGPtNOP8XisPZQk68JezitfyV8 DVXyAEx/08b9FcjlwJMxhISKHBoqa22T7b85fgq0vxY58K8LCMfORSHYsI1p5x2/upgP sj6OoG+5uQApE3rq17aUl4oWilSSe48jbT5MmnbQzkzxulX+1UmXouisnnVWd1SQMnIr SUL58ZG1qQ+P9W6OGIc1K9FgAdB2VzyNocRyYMU/D6tvemaLh2ZvSWU6UCog/AjxPkTe ApLQ== MIME-Version: 1.0 Received: by 10.52.96.167 with SMTP id dt7mr12718302vdb.118.1350571927474; Thu, 18 Oct 2012 07:52:07 -0700 (PDT) Received: by 10.58.245.39 with HTTP; Thu, 18 Oct 2012 07:52:06 -0700 (PDT) In-Reply-To: References: <50508ED7.9080805@ericsson.com> <505B6A7E.6010309@jitsi.org> Date: Thu, 18 Oct 2012 07:52:06 -0700 Message-ID: From: Ted Hardie To: Matthew Kaufman Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 14:52:09 -0000 On Wed, Oct 17, 2012 at 1:40 PM, Matthew Kaufman wrote: > 2) Are we seriously considering defining the allowed SDP for > RTCWEB/WEBRTC by referencing an I-D and not an RFC, or are we going to delay > defining the allowed SDP until trickle ICE is in an RFC, or are we going to > drop trickle ICE from RTCWEB 1.0? > It's fairly normal for an I-D to reference other I-Ds spawned by the work. There's an obvious race condition, and a common set of responses to that. Typically, if the I-D making the reference is ready to advance before the one it refers to is published, there's discussion at that point just prior to IETF Last Call of whether the reference is stable enough for a down reference. If it is not, there's a reference hold at the RFC publication stage (Bill Fenner has produced some lovely/scary graphs of what can occur with these holds). Basically, we don't need to decide which path to take now, but it's clear that paying attention to the drafts in other working groups is a good thing for the advancement of our work. regards, Ted From andrew.hutton@siemens-enterprise.com Thu Oct 18 08:55:18 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F013A21F851C for ; Thu, 18 Oct 2012 08:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0k2gxDdDyi7 for ; Thu, 18 Oct 2012 08:55:18 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 513BE21F84FE for ; Thu, 18 Oct 2012 08:55:17 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 51D8D1EB854F; Thu, 18 Oct 2012 17:55:15 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.76]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 17:55:15 +0200 From: "Hutton, Andrew" To: Christer Holmberg , Matthew Kaufman , "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) Thread-Index: Ac2soVaPkW4RjXahQS+tE0/0W+snswAhbkjgAAZaPeA= Date: Thu, 18 Oct 2012 15:55:14 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF01308C08@MCHP04MSX.global-ad.net> References: <7594FB04B1934943A5C02806D1A2204B018CD8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B018CD8@ESESSMB209.ericsson.se> 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 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 15:55:19 -0000 Also agree in general we need more clarity on SDP usage and it would be goo= d if the default use of JSEP was to maintain compatibility with 3264 offer/= answer but I assume it is really the application that has to ensure that. I am assuming that jsep-02 will start to clarify some of this and align wit= h the W3C spec which for example does require createOffer and createAnswer = to be used. Also wondering if jsep-02 will clarify the current thinking on how rehydrat= ion is going to work I am thinking that in this case it would be has to be = down to the application to do what it can to stick to O/A rules but there w= ill be limitation. I look forward to reviewing jsep-02 in detail when it is available. Regards Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: 18 October 2012 12:56 > To: Matthew Kaufman; Cullen Jennings (fluffy) > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for > Atlanta meeting) >=20 > Hi, >=20 > I agree with Matthew. >=20 > In my opinion, the default should be that JSEP O/A is aligned with RFC > 3264. >=20 > Then, IF some relaxation is needed, we should look at it case by case. > At the moment, one has to try to figure out him/herself what the > relaxations are. >=20 > And, as the authors don't seem to think there are any relaxations in > the first place, I REALLY think we need to clarify this :) >=20 > And, it's not only about PRANSWER - even without that there are > relaxations (as Matthew's e-mail describes). >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Matthew Kaufman [mailto:matthew.kaufman@skype.net] > Sent: 17. lokakuuta 2012 23:25 > To: Cullen Jennings (fluffy); Christer Holmberg > Cc: rtcweb@ietf.org > Subject: Relaxing SDP O/A (was RE: [rtcweb] Agenda requests for Atlanta > meeting) >=20 > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Cullen Jennings (fluffy) > Sent: Tuesday, October 9, 2012 7:17 AM >=20 > > I have not seen any reason to relax 3264 yet but if something comes > up, agree we should carefully look at the cases. I think we can just do > straight up > 3264. Arguments that SIP early media in a 180 is not > compliant with 3264 are just wrong. >=20 > We've *already* "relaxed" 3264's requirements in JSEP (comments apply > to draft-ietf-rtcweb-jsep-01) >=20 > Straight from 3264: "At any time, either agent MAY generate a new offer > that updates the session. However, it MUST NOT generate a new offer if > it has received an offer which it has not yet answered or rejected. > Furthermore, it MUST NOT generate a new offer if it has generated a > prior offer for which it has not yet received an answer or a rejection. > If an agent receives an offer after having sent one, but before > receiving an answer to it, this is considered a "glare" condition." >=20 > The JSEP API enforces no such rules. If you want to change the API to > bring it into compliance with *just this section* of 3264, it would > need all sorts of changes... >=20 > - 5.1.1 createOffer ... "Calling this method does not change state; its > use is not required". Ok, so how then is JSEP to enforce the two "MUST > NOT generate a new offer" is the quote from 3264 above? I would think > that createOffer must return an error whenever the "MUST NOT" cases > apply. (Never mind that if the "use is not required" then somehow I'm > to guess what SDP is legal for this browser to pass in to > setLocalDescription as an offer?) >=20 > - 5.1.4 setLocalDescription... has no language indicating that it is > prohibited to call "setLocalDescription" with an offer and then call it > again with a different offer without having supplied an answer. There > also appears to be no way to pass a "reject" in. (These two issues > appear in the W3C API state description too, so appears to really be > what we mean when we say that we're going to "use JSEP") >=20 > - 5.1.2 createAnswer... "Calling this method does not change state; its > use is not required". So then how can setLocalDescription know when it > is forbidden to accept an "offer" passed to it (as createOffer is not > required) when setRemoteDescription has been passed an "offer" but > "createAnswer" has not yet been called? >=20 > And so on. >=20 > This isn't the only section of 3264 that's gone out the window with > JSEP, but saying "I have not seen any reason to relax 3264 yet" doesn't > make any sense... that ship sailed when JSEP was proposed. >=20 > Matthew Kaufman > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Thu Oct 18 09:19:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535F921F881E for ; Thu, 18 Oct 2012 09:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.656 X-Spam-Level: X-Spam-Status: No, score=-2.656 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84MXApih9MMD for ; Thu, 18 Oct 2012 09:19:54 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9DC21F8832 for ; Thu, 18 Oct 2012 09:19:53 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so6783675lbo.31 for ; Thu, 18 Oct 2012 09:19:53 -0700 (PDT) X-Google-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:content-transfer-encoding:x-gm-message-state; bh=jnZmwkaU5P53cI2sAgt2tIPKZGYTdaB27OwO7r/1fSw=; b=g7FDjtphXrpfXBh7l3lqh8y8wLrmcmF+CX/Zz1LWsP/yy5x+ky+AvnBk5gJLdWTmae FkvT+xvOHTzQlFVbQQxCmOr2JOHx1hY42Jj+U27395sGZn/rCR7Zzni3+Rd8RnadO5QN pEs7gDXR/A3ezJBRrGNGtb5MEpPUtEA0n2unNdB09Fyw/h9N6OcOrxn+zvmzDeLZ/PwR lapc3kdBPe6KJR/qGKHkaOPjK2JCP7axV1x3GV67sq0D2xpL1JKVkQu+gM6jjofgQpve td7IKEKn7HyM51hQ3KrDVoiFVPC8Tw51YKEsLgxUptiHKO6m9dWQWBtaDZXIwO3BSimz qlgQ== Received: by 10.112.29.129 with SMTP id k1mr8195253lbh.102.1350577192998; Thu, 18 Oct 2012 09:19:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Thu, 18 Oct 2012 09:19:32 -0700 (PDT) In-Reply-To: <507F3680.4060200@alum.mit.edu> References: <507F3680.4060200@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 18 Oct 2012 18:19:32 +0200 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkONm0bNpH97EugXl/OK6HunZCK/gJS/BGwxVFyY68SY1C3L2X09DSqTgnc+QbSrpZS2gqN Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:19:55 -0000 2012/10/18 Paul Kyzivat : > I have been assuming that this is to be accomplished by the server pushin= g > javascript that is aware it is/may be interworking with sip, and which th= en > constrains itself to the subset of JSEP that compatible with 3264. And th= en > it is of course limited to those behaviors on the sip side that fall with= in > the subset of 3264 that JSEP supports. > > Is that the right way to view it? Hi Paul, what about is the JavaScript app directly speaks SIP? please let's also consider this case. Current web apps based on HTML5 and modern JavaScript are powerful like any other desktop application. No need to consider them limited and rely all the logic in the web server (like 5 years ago). Regards. --=20 I=C3=B1aki Baz Castillo From andrew.hutton@siemens-enterprise.com Thu Oct 18 09:26:17 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7638021F8744 for ; Thu, 18 Oct 2012 09:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXicrYtupTYk for ; Thu, 18 Oct 2012 09:26:17 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id E069121F8741 for ; Thu, 18 Oct 2012 09:26:16 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 0D2AE1EB843B for ; Thu, 18 Oct 2012 18:26:16 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.76]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 18:26:15 +0200 From: "Hutton, Andrew" To: "rtcweb@ietf.org" Thread-Topic: draft-nandakumar-rtcweb-sdp-00 - Legacy Interop Thread-Index: Ac2tTUtPbWy6cYmJS3KVgCOuI1zIcQ== Date: Thu, 18 Oct 2012 16:26:15 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF01308E45@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 Subject: [rtcweb] draft-nandakumar-rtcweb-sdp-00 - Legacy Interop X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:26:17 -0000 Hi, Just looking at the legacy interop examples in this draft at http://tools.i= etf.org/html/draft-nandakumar-rtcweb-sdp-00#section-6.=20 I know it states "The ideas included in here are not fully baked into the s= tandards and might be controversial in nature" but don't they actually conf= lict directly with existing decisions made? For example section 6.1 implies that the browser could be made to generate = an m line for RTP/AVP which it of course will not do. I know that actually = this is trick because DTLS-SRTP is still used but does look very messy. Or = do I misunderstand something? I am wondering whether the authors envisage that this SDP is generated by t= he browser or somehow handcrafted by the application but I assume the brows= er would have to do this, correct? Regards Andy From martin.thomson@gmail.com Thu Oct 18 09:36:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D762421F86EF for ; Thu, 18 Oct 2012 09:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.719 X-Spam-Level: X-Spam-Status: No, score=-3.719 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 326eBxBhgQcG for ; Thu, 18 Oct 2012 09:36:02 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE3B21F86EC for ; Thu, 18 Oct 2012 09:36:01 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so6729669lam.31 for ; Thu, 18 Oct 2012 09:36: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:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IY7dbnpMiAWSh//zMnHBYOHKeb5Mn0K7EagnWh2NfWY=; b=DtWfBBtT+HlzRkEwfP0KyhgyM7H5V6KlKhoHQsWwpKyzdF3Y076r11PRlCHjgLK93o T3O/hU82KAnUIMY3WpnTsT4HOYTKwvuFuBZ+kJsQw7sKwNVWmgrHv/ARtMXldd6cWuvp Ec7n1yATBWMwX/2h4aS0PpU2bKFDSffePQPXaw3nIMQDijStuGL+JtZ5OS5y1OJ399I1 Sc7YJ1ryHk5YrUxHrfX2Xyd9PaLvgKQwmGKfVVEdbTePgDhbuh2acIbVJnz90FdEBfLy ixgRXb2Qu/E3yS84Ut6ol/s2wYBG/2egmDxIiWUrrU9TyMfdShQqwhG08LmxUPulZDeB mZzg== MIME-Version: 1.0 Received: by 10.112.43.34 with SMTP id t2mr8073385lbl.109.1350578161094; Thu, 18 Oct 2012 09:36:01 -0700 (PDT) Received: by 10.112.83.2 with HTTP; Thu, 18 Oct 2012 09:36:00 -0700 (PDT) In-Reply-To: References: <507F3680.4060200@alum.mit.edu> Date: Thu, 18 Oct 2012 09:36:00 -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 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:36:02 -0000 On 18 October 2012 09:19, I=C3=B1aki Baz Castillo wrote: > 2012/10/18 Paul Kyzivat : >> I have been assuming that this is to be accomplished by the server pushi= ng >> javascript that is aware it is/may be interworking with sip, and which t= hen >> constrains itself to the subset of JSEP that compatible with 3264. And t= hen >> it is of course limited to those behaviors on the sip side that fall wit= hin >> the subset of 3264 that JSEP supports. >> >> Is that the right way to view it? > > Hi Paul, what about is the JavaScript app directly speaks SIP? please > let's also consider this case. Current web apps based on HTML5 and > modern JavaScript are powerful like any other desktop application. No > need to consider them limited and rely all the logic in the web server > (like 5 years ago). I=C3=B1aki, I think that is *exactly* what Paul said. After all, the Javascript has to come from somewhere. That's usually a server. The alternative is that there is a server somewhere that does this work. I find the distinction uninteresting. Server or Javascript are both "application" and where this code is executed matters very little. --Martin From martin.thomson@gmail.com Thu Oct 18 09:47:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D9421F8786 for ; Thu, 18 Oct 2012 09:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.862 X-Spam-Level: X-Spam-Status: No, score=-3.862 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeaWNS3BuP5f for ; Thu, 18 Oct 2012 09:47:43 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB1B21F8776 for ; Thu, 18 Oct 2012 09:47:36 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so6738183lam.31 for ; Thu, 18 Oct 2012 09:47:36 -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=0nCRT4XjWDJpA8lCFGBRuzlx2ZnPpxm9kNehCPBQPOQ=; b=F3I8D7x8hZGi1tjFf8ZXbtEPSjFF7pIseFm2OEX8JrqHByaeD6bzU/YuIFZI1+lHmF tJgaYTfR225uzkKc1BH3H/hVwNARrZVpJzFtojMWVT5CcZiJTtxlY0CINHBx1+xwt01M 1OmaAvXNZjbl2ciOZskK8AZfU7TcjtwSVFuD3IQslHtwllFBRXGupOJ2eXAEkCdN2fyE XA9e2+yFX+DyzkGICXaI8zovky95hAPTEa3gkeFI28U/XDI3lLizwRmMcj4GNGgGgs6n vAve5fI0WLfE3wzUj7DCg1TNWtjWMsDwgRjaPMgdubTR9cWDkLvOgzuieZiy5XRLp+dz k6lw== MIME-Version: 1.0 Received: by 10.152.148.40 with SMTP id tp8mr18982914lab.30.1350578856337; Thu, 18 Oct 2012 09:47:36 -0700 (PDT) Received: by 10.112.83.2 with HTTP; Thu, 18 Oct 2012 09:47:36 -0700 (PDT) Date: Thu, 18 Oct 2012 09:47:36 -0700 Message-ID: From: Martin Thomson To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [rtcweb] Comments on draft-miniero-rtcweb-http-fallback X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:47:45 -0000 This seems grossly inefficient. Even if you assume that we have to tolerate the head-of-line blocking properties of a stream transport, the overhead of HTTP headers is immense. What is wrong with WebSockets for this use case? Why is there so much discussion on topology? It seems that the topology used for TURN is perfectly good and would require the least disruption. From ibc@aliax.net Thu Oct 18 09:49:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE13D21F86E0 for ; Thu, 18 Oct 2012 09:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.658 X-Spam-Level: X-Spam-Status: No, score=-2.658 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cIKEyLHPDq6 for ; Thu, 18 Oct 2012 09:49:45 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8742021F86DC for ; Thu, 18 Oct 2012 09:49:45 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so6806507lbo.31 for ; Thu, 18 Oct 2012 09:49:44 -0700 (PDT) X-Google-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:content-transfer-encoding:x-gm-message-state; bh=lq/+oDT6WaPt3ZTdqtvxtZZB2NgzvqglGdj8PrWiHkk=; b=mmYYHD3gWr86BVfbX4w0PKdM8+T8dn55o851VnJCXe0JyDdW2h0GGmKCjmPgsl8+2i i7GypROkBy/mT+mdp4+FsTS04KFLgrLaKHUWBFnYFJ+40+cEI7Qnyvpf9AdY/efV+9fn 30D4bm13vDAicJq7OKvsi3T2ZwUnRRC4xeFkZYzeBKnE4QykOo0OBBNk5Lewfrdehtrl AMeWWMDMypDZ+G71rCYBAXyUr/4WdYrQAGscQ5Dhw1VMXxOlB/AwNAuyiM9N9JE82/hW cXAA+Saxz6JVW/iue+/4ciQkwmqm6mpqLClFJ1VedggV8xClVdVmh9ciBiNtCmbUF37x puPw== Received: by 10.152.110.42 with SMTP id hx10mr12610669lab.0.1350578984481; Thu, 18 Oct 2012 09:49:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Thu, 18 Oct 2012 09:49:24 -0700 (PDT) In-Reply-To: References: <507F3680.4060200@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 18 Oct 2012 18:49:24 +0200 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmnVhbMZQr4jiLOmvpdZb93A4UzTmb9wL3vQiM6EYpVBbzUz1NDpCPht/egbkKXk9/IktWj Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:49:46 -0000 2012/10/18 Martin Thomson : > I=C3=B1aki, > > I think that is *exactly* what Paul said. After all, the Javascript > has to come from somewhere. That's usually a server. The alternative > is that there is a server somewhere that does this work. Sorry then, I understood something more similar to a "B2BUA" , my fault :) --=20 I=C3=B1aki Baz Castillo From lorenzo@meetecho.com Thu Oct 18 10:30:32 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6BF21F8766 for ; Thu, 18 Oct 2012 10:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.189 X-Spam-Level: * X-Spam-Status: No, score=1.189 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHtcJqhgo0fL for ; Thu, 18 Oct 2012 10:30:31 -0700 (PDT) Received: from smtplq03.aruba.it (smtplqs-out31.aruba.it [62.149.158.71]) by ietfa.amsl.com (Postfix) with SMTP id 2A52021F8757 for ; Thu, 18 Oct 2012 10:30:30 -0700 (PDT) Received: (qmail 22574 invoked by uid 89); 18 Oct 2012 17:30:28 -0000 Received: from unknown (HELO smtp1.aruba.it) (62.149.158.221) by smtplq03.aruba.it with SMTP; 18 Oct 2012 17:30:28 -0000 Received: (qmail 29569 invoked by uid 89); 18 Oct 2012 17:30:28 -0000 Received: from unknown (HELO localhost) (lorenzo@meetecho.com@2.196.0.110) by smtp1.ad.aruba.it with SMTP; 18 Oct 2012 17:30:26 -0000 Date: Thu, 18 Oct 2012 19:30:59 +0200 Message-ID: <8i6fnmcv0sk8fx1ay2w18wcw.1350581459437@email.android.com> From: Lorenzo Miniero To: Martin Thomson , rtcweb@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Spam-Rating: smtp1.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N Subject: Re: [rtcweb] Comments on draft-miniero-rtcweb-http-fallback X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 17:30:32 -0000 TWFydGluLAoKaXQgbG9va3MgbGlrZSB5b3UgbWlzc2VkIHRoaXM6CgpodHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvcnRjd2ViL2N1cnJlbnQvbXNnMDUwMzUuaHRtbCAKClRoZSBk cmFmdCB3YXMgbm90IGF0IGFsbCBtZWFudCBhcyBhIHByb3Bvc2VkIHNvbHV0aW9uIChhcyAiZ3Jv c3NseSBpbmVmZmljaWVudCIgYXMgaXQgaXMpLCBidXQganVzdCBhcyBhIHdheSB0byBwb2xsIGZv ciBpbnRlcmVzdCBhYm91dCB3b3JrIGluIHRoYXQgZGlyZWN0aW9uIGluIHRoZSBncm91cCwgYW5k IGRpc2N1c3Mgd2hldGhlciBvciBub3Qgc29tZXRoaW5nIGxpa2UgdGhhdCB3b3VsZCBiZSBuZWVk ZWQgaW4gZmlyc3QgcGxhY2UuCgpGZWVsIGZyZWUgdG8gdGFrZSBpdCBmcm9tIHRoZXJlIGFuZCBy ZXZpdmUgdGhlIGRpc2N1c3Npb24sIGlmIG5lZWRlZC4KCkxvcmVuem8KCk1hcnRpbiBUaG9tc29u IDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+IGhhIHNjcml0dG86Cgo+VGhpcyBzZWVtcyBncm9z c2x5IGluZWZmaWNpZW50LiAgRXZlbiBpZiB5b3UgYXNzdW1lIHRoYXQgd2UgaGF2ZSB0bwo+dG9s ZXJhdGUgdGhlIGhlYWQtb2YtbGluZSBibG9ja2luZyBwcm9wZXJ0aWVzIG9mIGEgc3RyZWFtIHRy YW5zcG9ydCwKPnRoZSBvdmVyaGVhZCBvZiBIVFRQIGhlYWRlcnMgaXMgaW1tZW5zZS4KPgo+V2hh dCBpcyB3cm9uZyB3aXRoIFdlYlNvY2tldHMgZm9yIHRoaXMgdXNlIGNhc2U/Cj4KPldoeSBpcyB0 aGVyZSBzbyBtdWNoIGRpc2N1c3Npb24gb24gdG9wb2xvZ3k/ICBJdCBzZWVtcyB0aGF0IHRoZQo+ dG9wb2xvZ3kgdXNlZCBmb3IgVFVSTiBpcyBwZXJmZWN0bHkgZ29vZCBhbmQgd291bGQgcmVxdWly ZSB0aGUgbGVhc3QKPmRpc3J1cHRpb24uCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwo+cnRjd2ViIG1haWxpbmcgbGlzdAo+cnRjd2ViQGlldGYub3JnCj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYgo= From martin.thomson@gmail.com Thu Oct 18 10:47:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1EF21F8702 for ; Thu, 18 Oct 2012 10:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.858 X-Spam-Level: X-Spam-Status: No, score=-3.858 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swHuwbYRv+Jh for ; Thu, 18 Oct 2012 10:47:43 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7FF21F86DA for ; Thu, 18 Oct 2012 10:47:42 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so1986953wib.13 for ; Thu, 18 Oct 2012 10:47:41 -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=ste6/xe9DI++80oa1CU0dg9nx/jD1FR/obAiwXDane4=; b=vRoCStUYTZ+9FFz7QG5TS9pVZU/3eCpnBe9oi7LnJVmWdc/eO6VhaktssludlFZH6D ihw3v3+dcDcXvbZXXzi702d9XUDHUm1lnBDEXogYATxrJ9Zmi8fcY/kIV4Mr6H7JdgLF nyLGLI3R3Z+GaU2Af340kmJClmRpQ9859aTfdRQPrZAipKooR93DSTEOTNFHTkfoftuj YKIrsthoIgL78NVI9pmdWm9aDGo9dNNvcC5Dt1eN5s2u7bXatKs78w0N4KaFpa3qUgXM HcNNqLJxfekZOpVB6DdQ5J7NxOJcjaW3euY7mP98Wo0ETsrB5tSODk3fopMnteKha0NB HIvg== MIME-Version: 1.0 Received: by 10.180.88.130 with SMTP id bg2mr12896007wib.22.1350582461403; Thu, 18 Oct 2012 10:47:41 -0700 (PDT) Received: by 10.180.92.39 with HTTP; Thu, 18 Oct 2012 10:47:41 -0700 (PDT) In-Reply-To: <8i6fnmcv0sk8fx1ay2w18wcw.1350581459437@email.android.com> References: <8i6fnmcv0sk8fx1ay2w18wcw.1350581459437@email.android.com> Date: Thu, 18 Oct 2012 10:47:41 -0700 Message-ID: From: Martin Thomson To: Lorenzo Miniero Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Comments on draft-miniero-rtcweb-http-fallback X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 17:47:43 -0000 On 18 October 2012 10:30, Lorenzo Miniero wrote: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg05035.html I remember reading that, but considered that starting a new thread was appropriate, that's all. My view on the subject is that firewall circumvention is not and should not be the goal of any such work. A proper approach would be to use a TURN server that manages access control in a transparent fashion. That said, firewalls often block UDP for reasons other than a deep and abiding hatred of VoIP. Those firewalls are probably not doing anything that would prevent something like WebSockets from working. In those environments, a standard method for using the available communication channels could be helpful. WebSockets is also far more efficient with its use of bits. Hence, WebSockets. The main objection to something like WebSockets is that some environments actively block WebSockets. These firewalls often block HTTPS in the same way. In that case, I see no reason to continue to build ever more elaborate circumvention methods. I've said enough. I just realized that this is not really an rtcweb topic. (behave?) From worley@shell01.TheWorld.com Thu Oct 18 11:18:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1263821F8470 for ; Thu, 18 Oct 2012 11:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A88C6ZYue3UF for ; Thu, 18 Oct 2012 11:18:03 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 67D1A21F8519 for ; Thu, 18 Oct 2012 11:18:03 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id q9IIH3AD027513 for ; Thu, 18 Oct 2012 14:17:06 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9IIH3U84837221 for ; Thu, 18 Oct 2012 14:17:03 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9IIH3Vm4836109; Thu, 18 Oct 2012 14:17:03 -0400 (EDT) Date: Thu, 18 Oct 2012 14:17:03 -0400 (EDT) Message-Id: <201210181817.q9IIH3Vm4836109@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: rtcweb@ietf.org In-reply-to: (matthew.kaufman@skype.net) Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 18:18:04 -0000 > From: Matthew Kaufman > > The JSEP API enforces no such rules. If you want to change the API > to bring it into compliance with *just this section* of 3264, it > would need all sorts of changes... I'm not familiar with the details of JSEP, but on general architectural principles, my suspicion is that the key regarding interworking with SIP is not whether a JSEP-using application can send offers at times that the 3264 offer/answer model forbids it, but rather whether JSEP/WebRTC can *reject* an offer. Certainly in SIP, a new offer presented in a re-INVITE or UPDATE request can be rejected by the other UA by returning a failure response. Any WebRTC protocol that can interwork smoothly with SIP will require this capability. Given that, if the JSEP model permits an application to send offers at times when SIP does not, the WebRTC/SIP gateway/server can immediately send rejection of such offers back to the client, without sending a SIP request containing the offer. This approach tolerates considerable difference between the rules enforced by JSEP and the rules enforced by SIP, which may be convenient. Dale From christer.holmberg@ericsson.com Thu Oct 18 11:28:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A589521F8524 for ; Thu, 18 Oct 2012 11:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.126 X-Spam-Level: X-Spam-Status: No, score=-6.126 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2JJR2bH1DhB for ; Thu, 18 Oct 2012 11:28:02 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA3D21F8522 for ; Thu, 18 Oct 2012 11:28:01 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-d3-50804a304448 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 8E.F5.11467.03A40805; Thu, 18 Oct 2012 20:28:00 +0200 (CEST) Received: from ESESSHC019.ericsson.se (153.88.183.75) by esessmw0247.eemea.ericsson.se (153.88.115.93) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 18 Oct 2012 20:28:00 +0200 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 20:27:59 +0200 From: Christer Holmberg To: "'Dale R. Worley'" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) Thread-Index: AQHNrVzFTM0DTQrCn0GUNE1Z7ldS3Je/YPSw Date: Thu, 18 Oct 2012 18:27:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B019321@ESESSMB209.ericsson.se> References: (matthew.kaufman@skype.net) <201210181817.q9IIH3Vm4836109@shell01.TheWorld.com> In-Reply-To: <201210181817.q9IIH3Vm4836109@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+Jvra6BV0OAwcx7OhZr/7WzW7w8UebA 5DF5/1dmjyVLfjIFMEVx2aSk5mSWpRbp2yVwZfyb8IS14D9nxaIz91gbGP+wdzFyckgImEhs OXyGEcIWk7hwbz1bFyMXh5DAKUaJLWsfQjk7GSU+f2hmgXCWMEp8enuTuYuRg4NNwEKi+582 SLeIQJDEqwP/mUBsYYEwiZlPQOpB4uES32+9YoKwjSS2rXnFCmKzCKhK9C17BnYFr4C3xImL d1kh5m9hlHhy4TcTyHxOAQeJ9XdCQWoYga77fmoN2BxmAXGJW0/mM0FcLSCxZM95ZghbVOLl 43+sELaixMdX+xgh6nUkFuz+xAZha0ssW/iaGWKvoMTJmU/A7hQCircsnsA+gVF8FpIVs5C0 z0LSPgtJ+wJGllWMwrmJmTnp5YZ6qUWZycXF+Xl6xambGIExdXDLb90djKfOiRxilOZgURLn 5Ura7y8kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUUG9SP7jJqHdfZNTv9ycF5W+Xv81ayfr qkUZy/Te6Vs9L5yozdggPZNNNMDkSye/aclKhYcb7/xf0L42/PnikBqX0OCHLiJO216fk1q7 MrJ7glvPzvSP088J5G2LdRYR8p6fc71Ufunl9/deh9d+jnuxYIl67Y8FzJrqrj2VzCxp/ULO XaaVSizFGYmGWsxFxYkArX/BSXcCAAA= Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 18:28:02 -0000 Hi,=20 >> The JSEP API enforces no such rules. If you want to change the API to=20 >> bring it into compliance with *just this section* of 3264, it would=20 >> need all sorts of changes... > >I'm not familiar with the details of JSEP, but on general architectural pr= inciples, my suspicion is that the key regarding interworking with SIP is n= ot whether a JSEP-using application can send offers at times that the 3264= =20 >offer/answer model forbids it, but rather whether JSEP/WebRTC can *reject*= an offer. > >Certainly in SIP, a new offer presented in a re-INVITE or UPDATE request c= an be rejected by the other UA by returning a failure response. Any WebRTC= protocol that can interwork smoothly with SIP will require this capability= . > >Given that, if the JSEP model permits an application to send offers at tim= es when SIP does not, the WebRTC/SIP gateway/server can immediately send re= jection of such offers back to the client, without sending a SIP request co= ntaining=20 >the offer. For sure it must be possible to reject things which are not allowed by the = state machnine. The issue, however, is that the JSUP SDP O/A state machine currently does a= llow things which are not alligned with 3264. Regards, Christer From harald@alvestrand.no Thu Oct 18 11:35:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8172D21F859E for ; Thu, 18 Oct 2012 11:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.431 X-Spam-Level: X-Spam-Status: No, score=-110.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMaK40+ZSUDC for ; Thu, 18 Oct 2012 11:35:55 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 503CF21F854C for ; Thu, 18 Oct 2012 11:35:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 542C439E1AC for ; Thu, 18 Oct 2012 20:35:41 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzEz0Qvza649 for ; Thu, 18 Oct 2012 20:35:39 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 44BD539E04C for ; Thu, 18 Oct 2012 20:35:39 +0200 (CEST) Message-ID: <50804BFA.2030700@alvestrand.no> Date: Thu, 18 Oct 2012 20:35:38 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201210181817.q9IIH3Vm4836109@shell01.TheWorld.com> In-Reply-To: <201210181817.q9IIH3Vm4836109@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 18:35:56 -0000 On 10/18/2012 08:17 PM, Dale R. Worley wrote: >> From: Matthew Kaufman >> >> The JSEP API enforces no such rules. If you want to change the API >> to bring it into compliance with *just this section* of 3264, it >> would need all sorts of changes... > I'm not familiar with the details of JSEP, but on general > architectural principles, my suspicion is that the key regarding > interworking with SIP is not whether a JSEP-using application can send > offers at times that the 3264 offer/answer model forbids it, but > rather whether JSEP/WebRTC can *reject* an offer. > > Certainly in SIP, a new offer presented in a re-INVITE or UPDATE > request can be rejected by the other UA by returning a failure > response. Any WebRTC protocol that can interwork smoothly with SIP > will require this capability. > > Given that, if the JSEP model permits an application to send offers at > times when SIP does not, the WebRTC/SIP gateway/server can immediately > send rejection of such offers back to the client, without sending a > SIP request containing the offer. > > This approach tolerates considerable difference between the rules > enforced by JSEP and the rules enforced by SIP, which may be > convenient. Note that the JSEP API never sends anything. It permits the application to generate an offer (using CreateOffer), and it permits the application to tell the browser that it should set the local configuration according to an offer (using setLocal). The assumption is that the normal way of using the API when interworking with SIP is to generate the offer, set it locally with SetLocal(), and send it as a SIP OFFER. The API also offers signals (negotiationneeded) to tell the application that it would be good to change the offer it's sending; if the application intends to obey SIP rules, it will schedule that renegotiation after the current negotiation round finishes. But the API never forces the application to send an offer; sending or not sending an offer is strictly the application's responsibility. From ibc@aliax.net Thu Oct 18 11:58:45 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8C021F854F for ; Thu, 18 Oct 2012 11:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.66 X-Spam-Level: X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CLnrWSGLgp9 for ; Thu, 18 Oct 2012 11:58:44 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7719F21F84CC for ; Thu, 18 Oct 2012 11:58:44 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so6832980lam.31 for ; Thu, 18 Oct 2012 11:58:43 -0700 (PDT) X-Google-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:content-transfer-encoding:x-gm-message-state; bh=3BHIp2c2z1+RofCx1ozZDw9rFPTQfCO4RdBaVLSesgc=; b=OFUF9YZJUcp1Efm2AjaohnvAnY6wYi3Wc3dM8Is3vKvwQZuW5jSx61LZnRE6tSCIfe i0vtHcNJ1sR0vsxhvxL9+xaRgQ+h/YNREFg+ssjK9sy2lf+kYw1XAil29XYGKVJhaVvT ZccNjsu5vmLDM/LmlNpq7jyoSmXIvjP4bbCe81kXOZCiXHoiGtKFC8vcK2fD3Bc6k78n 7suXQQLJ/2xLMcXE9tGP3OW0YvUibehhA2YP6+eBAKrE2xW3I8oGco/frLW3KwZ2t+IY tepJTzVCyITfv8owdx+aQEE95qgIGK5dmN1DJzj9hlGxgRg3aSUHba7qwNOj1TKWEpRq V68A== Received: by 10.112.25.42 with SMTP id z10mr5290329lbf.103.1350586723415; Thu, 18 Oct 2012 11:58:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Thu, 18 Oct 2012 11:58:23 -0700 (PDT) In-Reply-To: <50804BFA.2030700@alvestrand.no> References: <201210181817.q9IIH3Vm4836109@shell01.TheWorld.com> <50804BFA.2030700@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 18 Oct 2012 20:58:23 +0200 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlVtLxjK3mDZJzPt5KvBxF9pPYG9vjKgRkmHayJ2YAsoUPwQwHpo/b+BJlScgupMcTvPpTP Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 18:58:45 -0000 2012/10/18 Harald Alvestrand : > But the API never forces the application to send an offer; sending or not > sending an offer is strictly the application's responsibility. In other words, the API allows implementing SIP's SDP usage, or not. That's up to the application. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Thu Oct 18 13:10:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6D021F84EA for ; Thu, 18 Oct 2012 13:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.127 X-Spam-Level: X-Spam-Status: No, score=-6.127 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKdsyIvF-zxu for ; Thu, 18 Oct 2012 13:10:34 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id AD3F721F8512 for ; Thu, 18 Oct 2012 13:10:33 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-a7-5080623846ee Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 38.9C.11467.83260805; Thu, 18 Oct 2012 22:10:32 +0200 (CEST) Received: from ESESSHC005.ericsson.se (153.88.183.33) by esessmw0191.eemea.ericsson.se (153.88.115.84) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 18 Oct 2012 22:10:31 +0200 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 22:10:31 +0200 From: Christer Holmberg To: 'Matthew Kaufman' , Emil Ivov Thread-Topic: [rtcweb] Filling in details on "trickle ICE" Thread-Index: Ac2XjRRR2xT3N2ETRimioq1qbE99zgVCc2oAABiJLGAAAy+oAAAG/KWg///xHAD//94bEIAAJLMA///eFjCAACgVgIAAaa2A///PAeA= Date: Thu, 18 Oct 2012 20:10:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0193AD@ESESSMB209.ericsson.se> References: <50508ED7.9080805@ericsson.com> <505B6A7E.6010309@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018842@ESESSMB209.ericsson.se> <507FD1C8.8000100@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018C70@ESESSMB209.ericsson.se> <507FF42E.5070106@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018D1F@ESESSMB209.ericsson.se> <507FF688.2010704@jitsi.org> <7594FB04B1934943A5C02806D1A2204B018D4B@ESESSMB209.ericsson.se>, <507FFBB5.4080904@jitsi.org> 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.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3VtciqSHA4OQONYs1OyewWGydKmQx 49ZZFou1/9rZHVg8Fmwq9Viy5CeTx/83gR63HkxiC2CJ4rJJSc3JLEst0rdL4Mr4vuYBc8F6 qYqW72fZGxj/iHQxcnJICJhILLlxgBXCFpO4cG89WxcjF4eQwClGiVkz+sESQgI7GSUWHXOC SCxhlGi+cJKli5GDg03AQqL7nzZIjYiAn8TuL/MZQWxmAW+JT4sesIPYwgKWEus+XmGHqLGS +LnoOZRdJjHt4Dkwm0VAVWLqzFYmEJsXqLfv21omiF1tbBKPlu4DK+IUSJSYfeMDM4jNCHTp 91NrmCCWiUvcejKfCeIDAYkle84zQ9iiEi8f/4P6TFHi46t9UMfpSCzY/YkNwtaWWLbwNTPE YkGJkzOfsEA8rC3RsngC+wRgGCBZMQtJ+ywk7bOQtC9gZFnFKJybmJmTXm6ol1qUmVxcnJ+n V5y6iREYjwe3/NbdwXjqnMghRmkOFiVxXq6k/f5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUa GH0Flx+T6mG+YNgS7f3nirxt6qaLm2vEMvZuXZbX9qtFOmnG+13P4hU2T56gsV6iZ+1j//m1 EhuzvXobLx0qPZ1//qSjh34e39cAFW8WzvokmwWfGHQ/OrpyGx+sMd/yIn4j+24lr/7aKbts A9X2fXxcslU4q969t3rT3w03PF44Tq9gWr2jQ4mlOCPRUIu5qDgRAKSS8L2VAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Filling in details on "trickle ICE" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 20:10:41 -0000 Hi,=20 >Oh, I agree wholeheartedly here... in order to support things like trickle= ICE it would be enormously helpful to separate the ICE negotiation=20 >from the SDP O/A state machine, so that candidates may be added without ma= king them part of an "Offer". > >The "Microsoft API proposal" neatly handles the ICE negotiation in a way t= hat is separated from the media negotiation... I suggest we use that=20 >method instead of trying to bend SDP O/A all out of shape in order to do t= rickle ICE. Sure, between the browser and the JS App we might choose to separate ICE fr= om SDP and O/A completely. However, the way the trickle-ICE draft is written, I assume it focuses on t= he interactions between two entities, and what is sent on the wire. Regards, Christer ________________________________________ From: Emil Ivov [emcho@jitsi.org] Sent: Thursday, October 18, 2012 5:53 AM To: Christer Holmberg Cc: Matthew Kaufman; Justin Uberti; rtcweb@ietf.org Subject: Re: [rtcweb] Filling in details on "trickle ICE" Hey Christer, On 18.10.12, 14:34, Christer Holmberg wrote: > Hi, > >>>>>>> IF we are going to relax 3264 (I really hope we are NOT), it=20 >>>>>>> needs to be clearly described somewhere. We cannot have a number=20 >>>>>>> of I-Ds doing it "on the run"... >>>>>> >>>>>> I don't see how trickle ICE would require any changes to the O/A=20 >>>>>> model. Candidate trickling semantics are completely separate from=20 >>>>>> those in 3264. >>>>>> >>>>>> Yes, the 3264 offer may, in some cases, contain a first batch of=20 >>>>>> candidates and the the 3264 may have to be delayed until ICE=20 >>>>>> processing yields valid pairs for every component but that's=20 >>>>>> about it. >>>>>> >>>>>> Am I missing something? >>>>> >>>>> I guess the question was whether one, after the first batch of=20 >>>>> candidates have been sent in an offer, should be allowed to send=20 >>>>> the second batch in a new offer - before an answer to the previous=20 >>>>> offer has been received. That would be against 3264. >>>> >>>> It would indeed but I am not sure why we would think of additional=20 >>>> candidate drops as offers at all. They are just independent=20 >>>> signalling and are only loosely related to the 3264 semantics. >>>> >>>> Of course with SIP we would have a problem caused by the fact that=20 >>>> additional in-dialog signalling is blocked by the 3264 answer. >>>> However, that's specific to SIP and will probably be best served=20 >>>> with a SIP specific solution (e.g. UPDATEs or forcing early=20 >>>> answers, or something else). >>> >>> It is sure that SIP may add its own limitations, but the general O/A=20 >>> is generic. >> >> Sure, and we agree that the general O/A need not be used for trickle ICE= , right? > > Well, I think general O/A SHALL be used - not only for trickle ICE, But why? What do we get from trickling via offers and answers other than pr= oblems? Or did you mean that > but also for JSEP :) > > (Vanilla ICE is also using general O/A) Not really. At least not always. ICE is quite nicely separated from the med= ia O/A in XMPP. Both are indeed stuffed together for SIP by 5245 but that's just a design c= hoice that we don't need to stick with. At least I don't see why we would. Emil -- https://jitsi.org From worley@shell01.TheWorld.com Thu Oct 18 14:12:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDEF21F8493 for ; Thu, 18 Oct 2012 14:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.923 X-Spam-Level: X-Spam-Status: No, score=-2.923 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9brX70fOKUq for ; Thu, 18 Oct 2012 14:12:03 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 9667621F84E9 for ; Thu, 18 Oct 2012 14:12:03 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id q9ILArhS013537; Thu, 18 Oct 2012 17:10:55 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9ILArbO4841940; Thu, 18 Oct 2012 17:10:53 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9ILAq4K4836140; Thu, 18 Oct 2012 17:10:52 -0400 (EDT) Date: Thu, 18 Oct 2012 17:10:52 -0400 (EDT) Message-Id: <201210182110.q9ILAq4K4836140@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Harald Alvestrand In-reply-to: <50804BFA.2030700@alvestrand.no> (harald@alvestrand.no) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 21:12:04 -0000 > From: Harald Alvestrand > > But the API never forces the application to send an offer; sending or > not sending an offer is strictly the application's responsibility. Is the API able to report that the far end has rejected the offer? Dale From ekr@rtfm.com Thu Oct 18 14:22:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9CA21F85B3 for ; Thu, 18 Oct 2012 14:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.777 X-Spam-Level: X-Spam-Status: No, score=-102.777 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiPEcsQROFYu for ; Thu, 18 Oct 2012 14:22:01 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 70A1E21F8604 for ; Thu, 18 Oct 2012 14:21:57 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so6990985lbo.31 for ; Thu, 18 Oct 2012 14:21:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=lq8ugEN5YydutXeaBScVNM4c2LlV3OenswjcsZJ/An0=; b=TApqoe37YT+QCj4dlddx8k+QEUWPqTP2Y1rVjqIO1+sl61LvRwpqpGX711IpMxHgrA clH0OL5MOxBD9aB18KMGoJdAsncbcG+eqh4zukiv/Sgsxn65JKTWKibMYO9SnQCv2jNy YlaCaubZ/kAQB4YZmOvp3JDNgEVxvqmeD0nQ46VhXEnvQoNCr/JepferC0vxdatIvDsF lScKkuwDHQVi0sei5HLFexpPYlW5YZ9ENxc5c6s55Q6lUeFesYs2TDNB49LuoVWln5cS Gc4hrFg5AMu/ODxi8bp16HCddrCn4OBlhsO9FMRchy+Loy+bAQLG0s4EwNan5C09dPl4 nfKg== Received: by 10.152.47.112 with SMTP id c16mr19801924lan.50.1350595316386; Thu, 18 Oct 2012 14:21:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.25.39 with HTTP; Thu, 18 Oct 2012 14:21:15 -0700 (PDT) X-Originating-IP: [74.95.2.174] In-Reply-To: <201210182110.q9ILAq4K4836140@shell01.TheWorld.com> References: <50804BFA.2030700@alvestrand.no> <201210182110.q9ILAq4K4836140@shell01.TheWorld.com> From: Eric Rescorla Date: Thu, 18 Oct 2012 14:21:15 -0700 Message-ID: To: "Dale R. Worley" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmkcZrhfAuISNYarFm5x6kdUmSYGCP3sXvEFcnCXBSg+ozKffE5bHwnU3L7Xw6wB8N7Hohj Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 21:22:02 -0000 On Thu, Oct 18, 2012 at 2:10 PM, Dale R. Worley wrote: >> From: Harald Alvestrand >> >> But the API never forces the application to send an offer; sending or >> not sending an offer is strictly the application's responsibility. > > Is the API able to report that the far end has rejected the offer? No. It's able to report that the local end couldn't negotiate but learning about the far end depends on messaging... -Ekr From martin.thomson@gmail.com Thu Oct 18 14:28:38 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07E521F841F for ; Thu, 18 Oct 2012 14:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJPYl-J1-OVz for ; Thu, 18 Oct 2012 14:28:38 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5AA21F841E for ; Thu, 18 Oct 2012 14:28:37 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so5900422wey.31 for ; Thu, 18 Oct 2012 14:28: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=ZcZf27N+Y9of+Cyxsu7xfI7rG7zalwJLuoZd60G3LV4=; b=L8vUwSMtP6kcgR5raZMWerIeqIlwpkvNXqlxi2MSz9EljbUAHwA1EMjZp+r+ObLVZL 4yB28LZI1uBQr/CIgHfz/2rE8MhnG0/rSGTWsfJuLz/fryDyAe/y2ES5qD8ckUm+WgKQ 5fTTs28ySKosL3HHLQDVkMvb21BY01wzLKcrZ7jFYwz/gG5YBDJY1AAqu/s8UCu6Ruwx ktEvJ76PU4A1Yx5n84D+0InZv/2XZ6LZ6JeCaCaMPGmsX6yIA/3B/ERi68i/KJz0UsBQ Mc42kK/skqmSRJV+HCcbgOgTagLPAkiFDNve8eVRu6p7GCqn5rqvJyDf93faeTQIc2iV Ukxg== MIME-Version: 1.0 Received: by 10.180.83.101 with SMTP id p5mr14060498wiy.2.1350595716837; Thu, 18 Oct 2012 14:28:36 -0700 (PDT) Received: by 10.180.92.39 with HTTP; Thu, 18 Oct 2012 14:28:36 -0700 (PDT) In-Reply-To: References: <50804BFA.2030700@alvestrand.no> <201210182110.q9ILAq4K4836140@shell01.TheWorld.com> Date: Thu, 18 Oct 2012 14:28:36 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 21:28:38 -0000 On 18 October 2012 14:21, Eric Rescorla wrote: > On Thu, Oct 18, 2012 at 2:10 PM, Dale R. Worley wrote: >> Is the API able to report that the far end has rejected the offer? > > No. It's able to report that the local end couldn't negotiate but > learning about the far end depends on messaging... That doesn't quite answer the question. I think that the question is, if I setLocalDescription(offer), but the remote peer rejects this offer, what do I do to (as 3264 dictates) revert the session to the state it was in prior to "making the offer". From ekr@rtfm.com Thu Oct 18 14:56:16 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460A721F8501 for ; Thu, 18 Oct 2012 14:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.787 X-Spam-Level: X-Spam-Status: No, score=-102.787 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9aArjZhpU9R for ; Thu, 18 Oct 2012 14:56:15 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6593D21F8419 for ; Thu, 18 Oct 2012 14:56:15 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so7008470lbo.31 for ; Thu, 18 Oct 2012 14:56:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=WTKBQiWaKWDFXOjW3ExGziTrBCcGuZaaE8yUS64pr3U=; b=W5NK8Jz9BJDLyLcEpAMX4Nf2s6kTMjB3mKuGR8haSI1bMVRM8FAnVqpNAE5Sk8BbCr ShyBHbZNPH9ZNeOocr8LMBiP+M6R18bmKsjskYd5NdTocbiaHWYPj+nqpV4rdl8L6WUe HtSATuisKpQG6LKstpCB2Xlsa+YmmaIEc8Dr9kVF2a5w4MIQ8mW/alexYCPJqqC38XVO 785CAiEwv4LIj+grSWzxBHYUQHZPZOKUqtCwWrDmD8qTiYyNtnaxoIuDKYTVzxXTMcp2 I0MSzOHnH6FLAmnw900UboJACJ7UEmfUA9oRQ9GhYxXyqtn+eLlaS/E+a3rcWBs0cmuc Lofw== Received: by 10.112.47.129 with SMTP id d1mr8317306lbn.115.1350597371716; Thu, 18 Oct 2012 14:56:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.25.39 with HTTP; Thu, 18 Oct 2012 14:55:31 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <50804BFA.2030700@alvestrand.no> <201210182110.q9ILAq4K4836140@shell01.TheWorld.com> From: Eric Rescorla Date: Thu, 18 Oct 2012 14:55:31 -0700 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmAi2Tg5m2yxChz3dfB44QN3QnswlauJgysBJX9w2ZSXO4guXu+ddBoertx1UBYHJBY7TJF Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 21:56:16 -0000 On Thu, Oct 18, 2012 at 2:28 PM, Martin Thomson wrote: > On 18 October 2012 14:21, Eric Rescorla wrote: >> On Thu, Oct 18, 2012 at 2:10 PM, Dale R. Worley wrote: >>> Is the API able to report that the far end has rejected the offer? >> >> No. It's able to report that the local end couldn't negotiate but >> learning about the far end depends on messaging... > > That doesn't quite answer the question. > > I think that the question is, if I setLocalDescription(offer), but the > remote peer rejects this offer, what do I do to (as 3264 dictates) > revert the session to the state it was in prior to "making the offer". I assume you mean in an update scenario, since in the initial offer scenario, you do pc.close(); In the update scenario it seems to me that with the current API, the natural gesture is setRemoteDescription() with the previous answer. But obviously the world would be better if this were written down. -Ekr From martin.thomson@gmail.com Thu Oct 18 15:11:00 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DC521F849B for ; Thu, 18 Oct 2012 15:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.854 X-Spam-Level: X-Spam-Status: No, score=-3.854 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfy0nukvkSYN for ; Thu, 18 Oct 2012 15:11:00 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id DA46B21F849A for ; Thu, 18 Oct 2012 15:10:59 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so2252886wib.13 for ; Thu, 18 Oct 2012 15:10: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=wSwnzOCleehqRpVJgmFE+LTItVBk8CPAJxX980Oflcc=; b=TdF/k2qzxOtc3WMOVc+WQwrRrNlTj9VCkWnSMZARcVseUTZ1GrgRN1B7vcpwKY+t2S eGr3hBAGzcEDF1wkG22tgaMHvywV5vNftKAeBqZGNlLQl5qDt2lBM9N/kTknmkLxalEQ J3CMgtjBpJjYMvz4YaDQ5U2XhsGtdUe+OqzL1YGHi5fIShrVkwaroI/lfGT1p/+VaUwT ZfVGouqLImzLOjz8xbB43wd8pThPpBEVkAYIGntI3CUZfZfIkFIbuxsIgmN60W6iEZH1 TkyVVVa+ga9+QkXRUmo0UDjDy4mWnnuRGWbjevCg/WXhQbSLeDzfn0+UEPVZ6ISeoEiD 9/yg== MIME-Version: 1.0 Received: by 10.180.108.45 with SMTP id hh13mr14214841wib.15.1350598258909; Thu, 18 Oct 2012 15:10:58 -0700 (PDT) Received: by 10.180.92.39 with HTTP; Thu, 18 Oct 2012 15:10:58 -0700 (PDT) In-Reply-To: References: <50804BFA.2030700@alvestrand.no> <201210182110.q9ILAq4K4836140@shell01.TheWorld.com> Date: Thu, 18 Oct 2012 15:10:58 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 22:11:00 -0000 On 18 October 2012 14:55, Eric Rescorla wrote: > I assume you mean in an update scenario, since in the initial offer > scenario, you do pc.close(); > > In the update scenario it seems to me that with the current > API, the natural gesture is setRemoteDescription() with the previous > answer. But obviously the world would be better if this were written > down. Or maybe setLocalDescription + setRemoteDescription with the entirety of the previous session state. From roman@telurix.com Thu Oct 18 15:22:29 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C0121F8589 for ; Thu, 18 Oct 2012 15:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvK18HnqX7Is for ; Thu, 18 Oct 2012 15:22:28 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE1521F855F for ; Thu, 18 Oct 2012 15:22:28 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so8715028pbb.31 for ; Thu, 18 Oct 2012 15:22:28 -0700 (PDT) X-Google-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:x-gm-message-state; bh=SrWBRxhTkZ8fxxMVVSl5OjhS1Je5f98cQJPETU/ymrA=; b=RtlmwwfKEn/gNOkzWw98n5VC+VfRZ6kLiRwySvxO0FTJ8ayjAD0qXLU/qp5rpSchm0 zg9kao7Pb1beM10edKBdNMofcNzXtSwqcCBmAeUJKnL8J6BgScdKEw6VZaPjMQQirTTb v4UmdMDvwkM3AzHsEvqKDqeVIVYU+8m4fNY5heK3o3pZaB0UcABAjfv8+OxdYG4HSBzD mVYnEWBGZB4RxT6PC0jJyXzXDdLWwnBCmTe4rpIITOduRmGGzq0GnO+bZN8m8aD4L+ak XpQhppfKNUxL7Rn4u59kZdBSzg9XaDQ94PM/SJjvY4Bf9r4g27XZdOJ0HWIBa/jZCQgn Eh7Q== Received: by 10.68.136.100 with SMTP id pz4mr70275206pbb.135.1350598947938; Thu, 18 Oct 2012 15:22:27 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by mx.google.com with ESMTPS id nc10sm122913pbc.17.2012.10.18.15.22.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Oct 2012 15:22:27 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so8655393pad.31 for ; Thu, 18 Oct 2012 15:22:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.225.7 with SMTP id rg7mr72044557pbc.32.1350598946160; Thu, 18 Oct 2012 15:22:26 -0700 (PDT) Received: by 10.68.42.8 with HTTP; Thu, 18 Oct 2012 15:22:26 -0700 (PDT) In-Reply-To: References: <50804BFA.2030700@alvestrand.no> <201210182110.q9ILAq4K4836140@shell01.TheWorld.com> Date: Thu, 18 Oct 2012 18:22:26 -0400 Message-ID: From: Roman Shpount To: Eric Rescorla Content-Type: multipart/alternative; boundary=047d7b2e79886b7fb904cc5cd232 X-Gm-Message-State: ALoCoQk+Gx9trqWyg7R7kRzow/ZqM88gctqZnZEPSSi3J0kXCrj5IdfvdkBBej4y8MmcJVFPD13l Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 22:22:29 -0000 --047d7b2e79886b7fb904cc5cd232 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 18, 2012 at 5:55 PM, Eric Rescorla wrote: > > I think that the question is, if I setLocalDescription(offer), but the > > remote peer rejects this offer, what do I do to (as 3264 dictates) > > revert the session to the state it was in prior to "making the offer". > > I assume you mean in an update scenario, since in the initial offer > scenario, you do pc.close(); > > In the update scenario it seems to me that with the current > API, the natural gesture is setRemoteDescription() with the previous > answer. But obviously the world would be better if this were written > down. > > In case of the session update scenario where update was refused (ie something similar to re-INVITE failure), would not giving the previous answer cause ICE and DTLS negotiations to run again or do we assume that browser O/A logic is smart enough to know that since the SDP version is the same it should be ignored? Also, description that we passed in setLocalDescription might be very different from the description that was passed in the previous setLocalDescription call (for instance we added or removed video). Would sending the previous answer in setRemoteDescription still work? I would feel better if we had some sort of cancel offer command, which can be just setRemoteDescription with an empty string instead of SDP. _____________ Roman Shpount --047d7b2e79886b7fb904cc5cd232 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Oct 18, 2012 at 5:= 55 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> I think that the question is, if I setLocalDescription(offer), but the=
> remote peer rejects this offer, what do I do to (as 3264 dictates)
> revert the session to the state it was in prior to "making the of= fer".

I assume you mean in an update scenario, since in the initial offer
scenario, you do pc.close();

In the update scenario it seems to me that with the current
API, the natural gesture is setRemoteDescription() with the previous
answer. But obviously the world would be better if this were written
down.


In case of the session update scenario= where update was refused (ie something similar to re-INVITE failure), woul= d not giving the previous answer cause ICE and DTLS negotiations to run aga= in or do we assume that browser O/A logic is smart enough to know that sinc= e the SDP version is the same it should be ignored?

Also, description that we passed in setLocalDescription= might be very different from the description that was passed in the previo= us=A0setLocalDescription=A0call (for instance we added or removed video). W= ould sending the previous answer in setRemoteDescription still work?

I would feel better if we had some sort of cancel offer= command, which can be just setRemoteDescription with an empty string inste= ad of SDP.
_____________
Roman Shpount

=A0
--047d7b2e79886b7fb904cc5cd232-- From martin.thomson@gmail.com Thu Oct 18 17:23:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1866921F8495 for ; Thu, 18 Oct 2012 17:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2EX9s21GSQR for ; Thu, 18 Oct 2012 17:23:53 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6746F21F8487 for ; Thu, 18 Oct 2012 17:23:53 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so7076043lbo.31 for ; Thu, 18 Oct 2012 17:23:52 -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=7pHmJ63JMZpENLD40MnRx0UOg5m9vHPHUYiwxWcXn7M=; b=H30mriTFAmLKFZoUMd3hTYRKRiI7iblOf5UwVhlX/X3npliq/WmpTkcLAYr2DOjKot HZlbAs3VyRHkypIKJaevfUXuorQJHzu+DSiAjXzfmacdAFSSgQd7jUt3HUXV42Z3UZQk 9e1w8ZfG/O1Ti01+xCf0t/O7XnG000fNl0i+9MzzXypaFbJApC/FYCDxfG870oADz56x f5dXTGdmXYzAwpbYw2V+YzNYldIgMMSHH2aTcFHHnouV/2Y2VAAkFlSSjwrIfaa4YNfV ki+1KU+IS5syRhj/YIDL7dEymd606D0aiG52bN3P+MlH7E6ZPtio3tgsk98TYmc4C4mn bnBg== MIME-Version: 1.0 Received: by 10.152.108.66 with SMTP id hi2mr19746855lab.11.1350606232371; Thu, 18 Oct 2012 17:23:52 -0700 (PDT) Received: by 10.112.83.2 with HTTP; Thu, 18 Oct 2012 17:23:52 -0700 (PDT) Date: Thu, 18 Oct 2012 17:23:52 -0700 Message-ID: From: Martin Thomson To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [rtcweb] Change ice ufrag or password X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 00:23:54 -0000 -jsep-01 currently includes the following option: - change ICE ufrag/password (a=ice-ufrag/pwd) That's a no-go [-security-arch, S5.3]. Will this be removed from the next draft? I'm interested though, was there a specific case that motivated the inclusion of this option? From bernard_aboba@hotmail.com Thu Oct 18 19:48:08 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A628021F858C for ; Thu, 18 Oct 2012 19:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.082 X-Spam-Level: X-Spam-Status: No, score=-102.082 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAG-K8DFOfHH for ; Thu, 18 Oct 2012 19:48:08 -0700 (PDT) Received: from blu0-omc2-s25.blu0.hotmail.com (blu0-omc2-s25.blu0.hotmail.com [65.55.111.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1508E21F8589 for ; Thu, 18 Oct 2012 19:48:08 -0700 (PDT) Received: from BLU402-EAS240 ([65.55.111.72]) by blu0-omc2-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Oct 2012 19:48:07 -0700 X-Originating-IP: [24.16.96.166] X-EIP: [EW7OMHT3WVYkyVRHHxvGd4P+jYRCB6jc] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Date: Thu, 18 Oct 2012 19:48:03 -0700 From: Bernard Aboba To: Martin Thomson MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-OriginalArrivalTime: 19 Oct 2012 02:48:07.0321 (UTC) FILETIME=[2B1D8890:01CDADA4] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 02:48:08 -0000 It seems to me that some scenarios would definitely require both APIs=2C fo= r example if hold or key changes or codec additions are involved. Martin Thomson wrote: On 18 October 2012 14:55=2C Eric Rescorla wrote: > I assume you mean in an update scenario=2C since in the initial offer > scenario=2C you do pc.close()=3B > > In the update scenario it seems to me that with the current > API=2C the natural gesture is setRemoteDescription() with the previous > answer. But obviously the world would be better if this were written > down. Or maybe setLocalDescription + setRemoteDescription with the entirety of the previous session state. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Thu Oct 18 23:23:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C504E21F87DB for ; Thu, 18 Oct 2012 23:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJRXxs13GeZU for ; Thu, 18 Oct 2012 23:23:41 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D2B2D21F8724 for ; Thu, 18 Oct 2012 23:23:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6647339E106; Fri, 19 Oct 2012 08:23:38 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICPZNvAd9c+h; Fri, 19 Oct 2012 08:23:37 +0200 (CEST) Received: from [172.30.42.70] (c-f8f1e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.241.248]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id AF7D539E020; Fri, 19 Oct 2012 08:23:37 +0200 (CEST) Message-ID: <5080F1E9.2050509@alvestrand.no> Date: Fri, 19 Oct 2012 08:23:37 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Dale R. Worley" References: <201210182110.q9ILAq4K4836140@shell01.TheWorld.com> In-Reply-To: <201210182110.q9ILAq4K4836140@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 06:23:42 -0000 On 10/18/2012 11:10 PM, Dale R. Worley wrote: >> From: Harald Alvestrand >> >> But the API never forces the application to send an offer; sending or >> not sending an offer is strictly the application's responsibility. > Is the API able to report that the far end has rejected the offer? The concept of "the far end" (application far end, not RTP far end) and "reject" are application-level concepts, not API-level concepts. So in the context of the API, I can't parse the question. The API can report that it was handed an SDP blob it couldn't use. The API can also report that the ICE state ended up in "failed" because communication didn't work. But figuring out that a 500 error code in the SDP session (or whatever other method the signalling protocol uses to say "no, I don't want to talk to you") means "offer rejectd" has to be done at the application. The application then has to tell the API not to bother with this PeerConnection any more - probably by calling close() or by deleting its references to the PeerConnection, so that it's garbage collected. From stefan.lk.hakansson@ericsson.com Thu Oct 18 23:37:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9061A21F85B0 for ; Thu, 18 Oct 2012 23:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkauBCfsvAbL for ; Thu, 18 Oct 2012 23:37:01 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF4021F85B4 for ; Thu, 18 Oct 2012 23:36:59 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-45-5080f50ab520 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A4.3E.17130.A05F0805; Fri, 19 Oct 2012 08:36:58 +0200 (CEST) Received: from [150.132.142.225] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Fri, 19 Oct 2012 08:36:58 +0200 Message-ID: <5080F509.5020102@ericsson.com> Date: Fri, 19 Oct 2012 08:36:57 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201210182110.q9ILAq4K4836140@shell01.TheWorld.com> <5080F1E9.2050509@alvestrand.no> In-Reply-To: <5080F1E9.2050509@alvestrand.no> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNJMWRmVeSWpSXmKPExsUyM+JvrS7X14YAg92dJhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEro2P2duaCeZwV+7/1MDYwrmbvYuTkkBAwkXj78jsbhC0mceHe eiCbi0NI4BSjxIL+l+wQzlpGiftXG5lBqngFtCXeP3zHBGKzCKhK7H62nQXEZhOwkVjbPQUs LioQJrF852YmiHpBiZMzn4DViAgIS2x91QsWFwaqmXJyOpgtJJAgMaHnPdhFnAK6Em9Xzwar Zxawlbgw5zqULS+x/e0cZoh6XYl3r++xTmAUmIVkxSwkLbOQtCxgZF7FKJybmJmTXm6ul1qU mVxcnJ+nV5y6iREYgAe3/DbYwbjpvtghRmkOFiVxXj3V/f5CAumJJanZqakFqUXxRaU5qcWH GJk4OKUaGAU2Hy+PX8N8VjUpzG0xa9biQ3mP0oxMHbVfOyqav7zjmbY06Jpmc8LJt1sWfZ79 7133od4ll2OeqhheStUID1vceoOx4CTbxOOF685uTD7peK4xR99trXug8veN9xRzN22R3ZLP s2Zu/xcRbsG8A8+ZLE54ya081qfYGlvz4nr11szob5L9BkosxRmJhlrMRcWJAP6waXYOAgAA Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 06:37:01 -0000 On 10/19/2012 08:23 AM, Harald Alvestrand wrote: > On 10/18/2012 11:10 PM, Dale R. Worley wrote: >>> From: Harald Alvestrand >>> >>> But the API never forces the application to send an offer; sending or >>> not sending an offer is strictly the application's responsibility. >> Is the API able to report that the far end has rejected the offer? > The concept of "the far end" (application far end, not RTP far end) and > "reject" are application-level concepts, not API-level concepts. > So in the context of the API, I can't parse the question. > > The API can report that it was handed an SDP blob it couldn't use. One discussion I think we've not had yet is the granularity the API could report "can't use this SDP blob" on. Say that a new offer (in on ongoing sessions) was received indicating the addition of two audio and two video tracks (from Alice to Bob). What if Bob's browser could decode both audio tracks but has resources to handle only one of the video tracks, should it be able to tell so (perhaps with the result that two audio and one video track was added)? Or should the update of the session just fail? From salvatore.loreto@ericsson.com Fri Oct 19 00:17:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BC421F8567 for ; Fri, 19 Oct 2012 00:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.383 X-Spam-Level: X-Spam-Status: No, score=-106.383 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSBQmbUb9zY2 for ; Fri, 19 Oct 2012 00:17:55 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id DB13221F855B for ; Fri, 19 Oct 2012 00:17:54 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-c1-5080fea1acc1 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E4.55.17130.1AEF0805; Fri, 19 Oct 2012 09:17:53 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Fri, 19 Oct 2012 09:17:53 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4496C2AD2 for ; Fri, 19 Oct 2012 10:17:53 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id DEFB4539DF for ; Fri, 19 Oct 2012 10:17:52 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7EECC536DC for ; Fri, 19 Oct 2012 10:17:52 +0300 (EEST) Message-ID: <5080FEA0.1030600@ericsson.com> Date: Fri, 19 Oct 2012 10:17:52 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <8i6fnmcv0sk8fx1ay2w18wcw.1350581459437@email.android.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUyM+Jvre7Cfw0BBjs3Glqs/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujEvz3rAXHOSvWDflHlsD42aeLkZODgkBE4m+JU+ZIWwxiQv3 1rN1MXJxCAmcYpR4fLOXFcLZwCgxd9sJZgjnIqPErC+voTJHGCXuvb/GBOGcZZR4ufIyK8gw XgFtiYWvFoANZhFQlThzew2YzSZgJvH84RYwW1QgWWLehqvMEPWCEidnPmEBsUUEhCW2vupl ArGFBVwklu76xgixoJtRYs6ERWBFnAKBEicO94LZzAK2EhfmXIey5SW2v50D9ZGaxNVzm8Bs IQEtid6znUwTGEVmIdk3C0n7LCTtCxiZVzEK5yZm5qSXm+ulFmUmFxfn5+kVp25iBAb6wS2/ DXYwbrovdohRmoNFSZxXT3W/v5BAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGqZe1nmx6tLhH uczokflcrRi1qNCViy5+bA2MilrCsGiW+6XqSe8Z+3ZufHsrf6X63PgF0p0itsenMTaeXvfi sD2nt8iS9iPfRXRmHUvTWnuecU5i8/LtSi3tB55pTJXfFjpFub87w2fu/jlKPxaxz2op1P52 smON6Me8VKmZN2tr/zp91yj+rsRSnJFoqMVcVJwIAOBB6sNCAgAA Subject: Re: [rtcweb] Comments on draft-miniero-rtcweb-http-fallback X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 07:17:56 -0000 On 10/18/12 8:47 PM, Martin Thomson wrote: > On 18 October 2012 10:30, Lorenzo Miniero wrote: >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg05035.html > I remember reading that, but considered that starting a new thread was > appropriate, that's all. > > My view on the subject is that firewall circumvention is not and > should not be the goal of any such work. A proper approach would be > to use a TURN server that manages access control in a transparent > fashion. > > That said, firewalls often block UDP for reasons other than a deep and > abiding hatred of VoIP. Those firewalls are probably not doing > anything that would prevent something like WebSockets from working. > In those environments, a standard method for using the available > communication channels could be helpful. WebSockets is also far more > efficient with its use of bits. Hence, WebSockets. > > The main objection to something like WebSockets is that some > environments actively block WebSockets. These firewalls often block > HTTPS in the same way. that is interesting, I have heard a lot people saying that usually the firewalls (well some time they talk of the proxy really more then firewall) are more likely to block WebSocket then HTTP and they use that statement to promote an HTTP fallback (here I am talking in general not specifically for webrtc) However if we are talking of secure WebSocket and https fallback I agree that if a firewall block secure Websocket then it will most likely block HTTP as well ! > In that case, I see no reason to continue to > build ever more elaborate circumvention methods. then I tend to agree in not trying to define a fallback of the fallback > > I've said enough. I just realized that this is not really an rtcweb > topic. (behave?) I would say that is rtcweb until we do not define what we want to do ciao Salvatore -- Salvatore Loreto, PhD www.sloreto.com From ibc@aliax.net Fri Oct 19 01:19:53 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9002021F86AF for ; Fri, 19 Oct 2012 01:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKgL1O5JOLeX for ; Fri, 19 Oct 2012 01:19:53 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F93E21F868B for ; Fri, 19 Oct 2012 01:19:52 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so158991lam.31 for ; Fri, 19 Oct 2012 01:19:48 -0700 (PDT) X-Google-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:content-transfer-encoding:x-gm-message-state; bh=9qxo9l9THHdb3PBFbKmSVwPEKfLwSo72VImavizn+mk=; b=cgCUHn6sdCfGy7WeIrMH1uFU2Ml/bx+qDctR4y5Ij+UIP3prZSzI37GA//60KpBstE skeMB0CVN9pOIvzdu5FFaIrxkxMf4M7KFqs/caUNq/8/Y+ol3QP21uz4JDcKECxz0vHY Y2eOVwbnZrL2ExU9ZpME34BDqGiVnnvjRiuZcRQLRTEeiFj1VyiGtqf9DvpiIejkm3OP /5kqdEurj2PbH7S7jcX/YsGVjCZr/dIG2Hvd2qPJlItYnlB/+8FPNTZrVq7OdmqCr7/C rB1/2L+BX12mHj9fFZhSumLQLil6kU6ROPYXw2vIsBi6eR+6GXYoDBS9Y52GrS6cd0Nj ZAgQ== Received: by 10.112.101.72 with SMTP id fe8mr312873lbb.107.1350634787890; Fri, 19 Oct 2012 01:19:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Fri, 19 Oct 2012 01:19:27 -0700 (PDT) In-Reply-To: <5080F1E9.2050509@alvestrand.no> References: <201210182110.q9ILAq4K4836140@shell01.TheWorld.com> <5080F1E9.2050509@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 19 Oct 2012 10:19:27 +0200 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkRsNUhQbwtMu32OQtORHZm/153mvJx0cx55FP5AbWUrheuA4HDct08PSiH4vrL3CITxU/j Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 08:19:53 -0000 2012/10/19 Harald Alvestrand : > But figuring out that a 500 error code in the SDP session (or whatever ot= her > method the signalling protocol uses to say "no, I don't want to talk to > you") means "offer rejectd" has to be done at the application. Right. SDP must be signaled by the application making use of it. SDP is not a "end-to-end" protocol, it must be carried somehow (via a signaling protocol in which the remote endpoint can reject the SDP offer with some signaling code that the local endpoint must understand for closing/aborting its SDP offer). SIP and XMPP are signaling protocols using SDP and fit very well into the state machine defined in RFC 3264. In WebRTC we DON'T have a (network) signaling protocol and, thus, it's the JavaScript responsability to respect or not RFC 3264 rules, but those rules cannot be mandated at the media stack level. So honestly I don't fully understand what we are discussing in this thread. Regards. --=20 I=C3=B1aki Baz Castillo From andrew.hutton@siemens-enterprise.com Fri Oct 19 02:23:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D3B21F8688 for ; Fri, 19 Oct 2012 02:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oe9LdRzbBw-H for ; Fri, 19 Oct 2012 02:23:46 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6D81321F8684 for ; Fri, 19 Oct 2012 02:23:45 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 26AB41EB8540; Fri, 19 Oct 2012 11:23:42 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.76]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Fri, 19 Oct 2012 11:23:41 +0200 From: "Hutton, Andrew" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) Thread-Index: AQHNrdKI8nNhjZaHZU2vQ34thA/7fZfATuww Date: Fri, 19 Oct 2012 09:23:40 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0130A101@MCHP04MSX.global-ad.net> References: <201210182110.q9ILAq4K4836140@shell01.TheWorld.com> <5080F1E9.2050509@alvestrand.no> 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 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 09:23:46 -0000 T25tMTkgT2N0b2JlciAyMDEyIDA5OjE5IEnDsWFraSBCYXogQ2FzdGlsbG8gd3JvdGU6DQo+IA0K PiBSaWdodC4gU0RQIG11c3QgYmUgc2lnbmFsZWQgYnkgdGhlIGFwcGxpY2F0aW9uIG1ha2luZyB1 c2Ugb2YgaXQuIFNEUA0KPiBpcyBub3QgYSAiZW5kLXRvLWVuZCIgcHJvdG9jb2wsIGl0IG11c3Qg YmUgY2FycmllZCBzb21laG93ICh2aWEgYQ0KPiBzaWduYWxpbmcgcHJvdG9jb2wgaW4gd2hpY2gg dGhlIHJlbW90ZSBlbmRwb2ludCBjYW4gcmVqZWN0IHRoZSBTRFANCj4gb2ZmZXIgd2l0aCBzb21l IHNpZ25hbGluZyBjb2RlIHRoYXQgdGhlIGxvY2FsIGVuZHBvaW50IG11c3QgdW5kZXJzdGFuZA0K PiBmb3IgY2xvc2luZy9hYm9ydGluZyBpdHMgU0RQIG9mZmVyKS4NCj4gDQo+IFNJUCBhbmQgWE1Q UCBhcmUgc2lnbmFsaW5nIHByb3RvY29scyB1c2luZyBTRFAgYW5kIGZpdCB2ZXJ5IHdlbGwgaW50 bw0KPiB0aGUgc3RhdGUgbWFjaGluZSBkZWZpbmVkIGluIFJGQyAzMjY0LiBJbiBXZWJSVEMgd2Ug RE9OJ1QgaGF2ZSBhDQo+IChuZXR3b3JrKSBzaWduYWxpbmcgcHJvdG9jb2wgYW5kLCB0aHVzLCBp dCdzIHRoZSBKYXZhU2NyaXB0DQo+IHJlc3BvbnNhYmlsaXR5IHRvIHJlc3BlY3Qgb3Igbm90IFJG QyAzMjY0IHJ1bGVzLCBidXQgdGhvc2UgcnVsZXMNCj4gY2Fubm90IGJlIG1hbmRhdGVkIGF0IHRo ZSBtZWRpYSBzdGFjayBsZXZlbC4NCj4gDQo+IFNvIGhvbmVzdGx5IEkgZG9uJ3QgZnVsbHkgdW5k ZXJzdGFuZCB3aGF0IHdlIGFyZSBkaXNjdXNzaW5nIGluIHRoaXMNCj4gdGhyZWFkLiBSZWdhcmRz Lg0KPiANCg0KV2hhdCBpcyBiZWluZyBkaXNjdXNzZWQgaXMgd2hldGhlciBpdCBpcyBwb3NzaWJs ZSB0byBidWlsZCBhIFJGQyAzMjY0IGNvbXBsaWFudCBhcHBsaWNhdGlvbiB1c2luZyB0aGUgY3Vy cmVudCBBUEkgYXMgaXQgaXMgYSByZXF1aXJlbWVudCB0byBiZSBhYmxlIHRvIGRvIHNvLg0KDQpJ dCB3b3VsZCBiZSBnb29kIGlmIHRoZSBBUEkgbWFkZSB0aGlzIGVhc3kgZm9yIHRoZSBhcHBsaWNh dGlvbiBhcyBpdCB3aWxsIGJlIGEgY29tbW9uIHVzZSBjYXNlIGFuZCBJIHRoaW5rIEpTRVAgcHJv YmFibHkgbmVlZHMgdG8gZXhwbGFpbiBob3cgdG8gZG8gdGhpcy4gDQoNClJGQzM2MjQgcmVxdWly ZXMgdGhhdCB0aGUgc2Vzc2lvbiByZXZlcnRzIHRvIHRoZSBzdGF0ZSBwcmlvciB0byB0aGUgb2Zm ZXIgaWYgdGhlIG9mZmVyL2Fuc3dlciBleGNoYW5nZSBmYWlscy4gDQoNCklmIGFuIGFwcGxpY2F0 aW9ucyBhdHRlbXB0cyB0byBtb2RpZnkgYSBzZXNzaW9uIGJ1dCB0aGUgdXBkYXRlZCBvZmZlciBp cyByZWplY3RlZCBieSB0aGUgZmFyIGVuZCB0aGVyZSBzaG91bGQgYmUgbm8gaW50ZXJydXB0aW9u IHRvIHRoZSBleGlzdGluZyBzZXNzaW9uLiBMaWtlIFJvbWFuIHN1Z2dlc3RlZCBJIGFtIGFsc28g dGhpbmtpbmcgaXQgd291bGQgYmUgbmljZSBpZiB0aGUgQVBJIHByb3ZpZGVkIHNvbWUgd2F5IG9m IGNhbmNlbGxpbmcgYW4gb2ZmZXIgYW5kIHJldmVydGluZyB0byB0aGUgb3JpZ2luYWwgc3RhdGUg YnV0IGlmIHRoaXMgaXMgcHV0dGluZyB0b28gbXVjaCBzdGF0ZSBiYWNrIGluIHRoZSBicm93c2Vy IHdlIHdvdWxkIG5lZWQgYSBjbGVhcmx5IGRvY3VtZW50ZWQgbWVjaGFuaXNtLg0KDQpBbmR5DQoN Cg== From harald@alvestrand.no Fri Oct 19 02:24:03 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C42D21F8698 for ; Fri, 19 Oct 2012 02:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHdUNVPnoVAZ for ; Fri, 19 Oct 2012 02:24:02 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B36A421F8444 for ; Fri, 19 Oct 2012 02:23:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 51BB339E106 for ; Fri, 19 Oct 2012 11:23:57 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERDAUezXBwQG for ; Fri, 19 Oct 2012 11:23:56 +0200 (CEST) Received: from [10.130.0.147] (4.234.241.83.in-addr.dgcsystems.net [83.241.234.4]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7DDB239E020 for ; Fri, 19 Oct 2012 11:23:56 +0200 (CEST) Message-ID: <50811C2B.9080906@alvestrand.no> Date: Fri, 19 Oct 2012 11:23:55 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201210182110.q9ILAq4K4836140@shell01.TheWorld.com> <5080F1E9.2050509@alvestrand.no> <5080F509.5020102@ericsson.com> In-Reply-To: <5080F509.5020102@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Handling a partially-useful offer (Re: Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting)) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 09:24:03 -0000 Forking thread, since this is a new topic.... On 10/19/2012 08:36 AM, Stefan Hakansson LK wrote: > On 10/19/2012 08:23 AM, Harald Alvestrand wrote: >> On 10/18/2012 11:10 PM, Dale R. Worley wrote: >>>> From: Harald Alvestrand >>>> >>>> But the API never forces the application to send an offer; sending or >>>> not sending an offer is strictly the application's responsibility. >>> Is the API able to report that the far end has rejected the offer? >> The concept of "the far end" (application far end, not RTP far end) and >> "reject" are application-level concepts, not API-level concepts. >> So in the context of the API, I can't parse the question. >> >> The API can report that it was handed an SDP blob it couldn't use. > > One discussion I think we've not had yet is the granularity the API > could report "can't use this SDP blob" on. Say that a new offer (in on > ongoing sessions) was received indicating the addition of two audio > and two video tracks (from Alice to Bob). What if Bob's browser could > decode both audio tracks but has resources to handle only one of the > video tracks, should it be able to tell so (perhaps with the result > that two audio and one video track was added)? Or should the update of > the session just fail? This seems to be something that should be happening to SIP endpoints too. I can imagine either answering with capabilities reduced to reflect what could be handled, accepting the offer followed by generating a new offer of reduced capabilities, or rejecting the offer. What is existing practice in this area? (I would not be surprised if it was "it depends"....) From harald@alvestrand.no Fri Oct 19 02:26:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83C321F8689 for ; Fri, 19 Oct 2012 02:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bb4lO559fJDU for ; Fri, 19 Oct 2012 02:26:42 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 299E721F8584 for ; Fri, 19 Oct 2012 02:26:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2249D39E106; Fri, 19 Oct 2012 11:26:40 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFn7MX8Dl0MP; Fri, 19 Oct 2012 11:26:39 +0200 (CEST) Received: from [10.130.0.147] (4.234.241.83.in-addr.dgcsystems.net [83.241.234.4]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 710E139E020; Fri, 19 Oct 2012 11:26:39 +0200 (CEST) Message-ID: <50811CCE.3070707@alvestrand.no> Date: Fri, 19 Oct 2012 11:26:38 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Matthew Kaufman References: <201210181817.q9IIH3Vm4836109@shell01.TheWorld.com> <50804BFA.2030700@alvestrand.no>, In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 09:26:42 -0000 On 10/18/2012 09:08 PM, Matthew Kaufman wrote: > I think this interpretation is correct... which of course leads to the same question I asked on one of the last W3C calls on the subject: *IF* we are going to be producing an API which does not in fact comply with RFC 3264, but in fact significantly relaxes the rules of SDP O/A (which this email thread has confirmed is the case, as I suspected it would), then why are we so hung up on producing an API which looks anything like it (as opposed to, say, the proposal I jointly made with others here at Microsoft)? Because making an interface that makes following an existing practice easy (but does not enforce all the constraints of that practice) is better than making an interface that makes following that practice very complex? From ibc@aliax.net Fri Oct 19 02:28:49 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A37321F8475 for ; Fri, 19 Oct 2012 02:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDEDYoNx3FvE for ; Fri, 19 Oct 2012 02:28:48 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7FF21F8472 for ; Fri, 19 Oct 2012 02:28:48 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so253166lbo.31 for ; Fri, 19 Oct 2012 02:28:47 -0700 (PDT) X-Google-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:content-transfer-encoding:x-gm-message-state; bh=IiriycBYpeAZ1AHbHezQVi9Lc0kZc5rMAT8xMqch5FE=; b=Ik4gbh81eQtTte6mVBzjrlxvQt4s0QRxrU/Zva8UqMtfZ1Ygzjp82Fjl+hY2uEotSm Rs9rXo4EyX6kNA8yELZ9xeVzr4VyNwMkfEC6oGOKIGDxr3ab8II3hal4YrqGOSTtZ++0 HKnb1R+UDU+mtOfElZ6NRqPWe6b4OOc5KIXY/DtsyB197aTbXpuqQC/jBxS0oc1ruUG3 ApTR1GJC73n3whpznctZJ5uAmOBvqWV7LNlW1rWAqlQdqsRxJTvMZ0m+dYe+tHzDP6/H v5wWoZ4cmxAi+tmSIqyEoJrw+rvBhQXx35CDm8MvO5dwCb2JiChDkXGQVLgZMXCG9ywT 7A3g== Received: by 10.112.101.72 with SMTP id fe8mr382010lbb.107.1350638927338; Fri, 19 Oct 2012 02:28:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Fri, 19 Oct 2012 02:28:26 -0700 (PDT) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0130A101@MCHP04MSX.global-ad.net> References: <201210182110.q9ILAq4K4836140@shell01.TheWorld.com> <5080F1E9.2050509@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF0130A101@MCHP04MSX.global-ad.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 19 Oct 2012 11:28:26 +0200 Message-ID: To: "Hutton, Andrew" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmCDH1DbE6jZj6ZaJXAB1y+/zkMSqvulbQcQnNeKH8OOBvtrx2ASD8IuxiikV12KYAyj2fJ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 09:28:49 -0000 2012/10/19 Hutton, Andrew : > RFC3624 requires that the session reverts to the state prior to the offer= if the offer/answer exchange fails. > > If an applications attempts to modify a session but the updated offer is = rejected by the far end there should be no interruption to the existing ses= sion. Like Roman suggested I am also thinking it would be nice if the API p= rovided some way of cancelling an offer and reverting to the original state= but if this is putting too much state back in the browser we would need a = clearly documented mechanism. Ok, I understand. Then I agree that the API should provide some mechanism for respecting that rule in RFC 3264. --=20 I=C3=B1aki Baz Castillo From andrew.hutton@siemens-enterprise.com Fri Oct 19 04:55:49 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D74B21F8594 for ; Fri, 19 Oct 2012 04:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmK0U1H5+64B for ; Fri, 19 Oct 2012 04:55:49 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id F41C721F8589 for ; Fri, 19 Oct 2012 04:55:48 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 20FFB1EB858C; Fri, 19 Oct 2012 13:55:48 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.76]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Fri, 19 Oct 2012 13:55:47 +0200 From: "Hutton, Andrew" To: Stefan Hakansson LK , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) Thread-Index: AQHNrXUNkW4RjXahQS+tE0/0W+sns5fACBqAgAADuoCAAGCjoA== Date: Fri, 19 Oct 2012 11:55:46 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0130A402@MCHP04MSX.global-ad.net> References: <201210182110.q9ILAq4K4836140@shell01.TheWorld.com> <5080F1E9.2050509@alvestrand.no> <5080F509.5020102@ericsson.com> In-Reply-To: <5080F509.5020102@ericsson.com> 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 Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 11:55:49 -0000 On 19 October 2012 07:37 Stefan Hakansson LK wrote: >=20 > One discussion I think we've not had yet is the granularity the API > could report "can't use this SDP blob" on. Say that a new offer (in on > ongoing sessions) was received indicating the addition of two audio and > two video tracks (from Alice to Bob). What if Bob's browser could > decode > both audio tracks but has resources to handle only one of the video > tracks, should it be able to tell so (perhaps with the result that two > audio and one video track was added)? Or should the update of the > session just fail? >=20 The update to the session should not just fail. Normally in this case the a= nswer would simple reject the one video stream and not the whole offer. =20 Andy From andrew.hutton@siemens-enterprise.com Fri Oct 19 06:58:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C6421F89BC for ; Fri, 19 Oct 2012 06:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqYy0-Cxfqq9 for ; Fri, 19 Oct 2012 06:58:50 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7B321F8968 for ; Fri, 19 Oct 2012 06:58:50 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 3316D1EB8592; Fri, 19 Oct 2012 15:58:49 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.76]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Fri, 19 Oct 2012 15:58:48 +0200 From: "Hutton, Andrew" To: "rtcweb@ietf.org" Thread-Topic: Video Codec - Possible to use. Thread-Index: Ac2uAdvfNfH0YMcdSYGJWOnt/4GLHA== Date: Fri, 19 Oct 2012 13:58:48 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0130A96F@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 Subject: [rtcweb] Video Codec - Possible to use. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 13:58:51 -0000 Hi, The question of whether it will be possible for a webrtc application to mak= e us of video codec's (or audio codec) which are not implemented in the bro= wser itself has been raised before but I don't think there has been a clear= answer. Some clarity on this might help some of us to come to a conclusion on where= we stand in the MTI debate. I looked through the archives and found some statements that indicate this = should be possible but I not sure we have a definitive statement on this. F= or example: On 06 September 2012 00:29 Randall Gellens >=20 > One of the goals of rtcweb is to encourage greater use of native > codecs, and greater access to such codecs by applications such as > those running in browsers. These are worthy goals, since native > codecs often have better performance within the environment. > (Examples include AMR and EVRC on handsets.) These codecs also can > be supported out-of-the-box, no separate downloads, no signed forms. > Is this really a goal we have agreement on? There does not seem to specific= requirements in the requirements draft. Also I think there are SDP implications relating to this. How would the bro= wser and/or application be able to build the correct SDP to offer additiona= l codecs? Regards Andy=20 From stefan.lk.hakansson@ericsson.com Fri Oct 19 07:22:36 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE02721F86E5 for ; Fri, 19 Oct 2012 07:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZH45uLLJ-vr for ; Fri, 19 Oct 2012 07:22:36 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id EEEB421F85A4 for ; Fri, 19 Oct 2012 07:22:35 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-0c-5081622a2653 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 7A.59.11467.A2261805; Fri, 19 Oct 2012 16:22:34 +0200 (CEST) Received: from [150.132.142.225] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Fri, 19 Oct 2012 16:22:34 +0200 Message-ID: <50816228.4040605@ericsson.com> Date: Fri, 19 Oct 2012 16:22:32 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <9F33F40F6F2CD847824537F3C4E37DDF0130A96F@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0130A96F@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNJMWRmVeSWpSXmKPExsUyM+Jvra5WUmOAQd9hSYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8aFzKVvBLJaKnq2TWBoYFzN3MXJySAiYSGz+fIcNwhaTuHBv PZDNxSEkcIpR4tzOQ8wQzlpGiZ71zWAdvALaEsd//QfrYBFQlbh7+AQLiM0mYCOxtnsKE4gt KhAmsXznZiaIekGJkzOfgNWICAhLbH3VCxYXBtp8tXkqK4gtJOAn8eDgXjCbU8Bf4vPnHjCb WcBW4sKc6ywQtrzE9rdzmCHqdSXevb7HOoFRYBaSFbOQtMxC0rKAkXkVo3BuYmZOermhXmpR ZnJxcX6eXnHqJkZgAB7c8lt3B+OpcyKHGKU5WJTEebmS9vsLCaQnlqRmp6YWpBbFF5XmpBYf YmTi4JRqYOyZn5C7sqm061n2nKBXaeJFczd7LJ3kbfxQ5JWN2YnDuzVczVR+PtC89/gbk8/N ghN1d8rbbCQKzGSjnsceERD9mSxgYPfy32keiyjZw1EV9r/WZX0R6xRs0s+9pLPhSHGPuOFa p5k/xav2nrpd9GT6dBGhk0HRzWYMkcxam60+7LSuZZuwW4mlOCPRUIu5qDgRAK3+EaoOAgAA Subject: Re: [rtcweb] Video Codec - Possible to use. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:22:36 -0000 On 10/19/2012 03:58 PM, Hutton, Andrew wrote: > > Also I think there are SDP implications relating to this. How would > the browser and/or application be able to build the correct SDP to > offer additional codecs? To me this is a "must". Regardless of what codecs are made MTI now, they are likely to not be state-of-art in a few years time. I had the impression this was one of the main advantages with using SDP: it offers a well established way to negotiate what codec(s) to use between end-points. Br, Stefan From ekr@rtfm.com Fri Oct 19 07:58:29 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41FE721F8699 for ; Fri, 19 Oct 2012 07:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.796 X-Spam-Level: X-Spam-Status: No, score=-102.796 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+UJ7Hl19-DR for ; Fri, 19 Oct 2012 07:58:28 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2C42021F8639 for ; Fri, 19 Oct 2012 07:58:27 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so422871lam.31 for ; Fri, 19 Oct 2012 07:58:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=8O9h7FuXpNlnVy5fpKHKrkNZ9C6/A5MgqKjdc30mQaE=; b=cLw9fQqvOxiVH5egvj/cKrNEfJqsBTPlOQSb5EiMy8kyMPPDuYb6n5jd6Wn87/rhdI HwrYUG6s6Qnv48DZMPeNJuywH9BfD7/TwhPvtGE049esudi06QfFC5liKak8V8BGjdWE H57opgUrl7LCWx24WG4wnQQ8sLH6z1V5SAWLvmquZ8RYRGmNlH5KDQFk8iU0ZopezaRt V0zEntN4iLz3QmXPz+VSqWNTTgg9D7T9+PrTPUYRN0hsGnbTuoQv56sdgCqQd72XlduQ iNtTHPpMMp/I3pRm09RNPNCPSmzXQpTt/cXPolq5PUF8g5DGwGSt9G5UQxPR5VB8sG03 p1Nw== Received: by 10.152.103.38 with SMTP id ft6mr1386691lab.40.1350658706962; Fri, 19 Oct 2012 07:58:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.25.39 with HTTP; Fri, 19 Oct 2012 07:57:46 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0130A96F@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF0130A96F@MCHP04MSX.global-ad.net> From: Eric Rescorla Date: Fri, 19 Oct 2012 07:57:46 -0700 Message-ID: To: "Hutton, Andrew" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnMchvyH6nJZlGVJ/miIZfbZLmGo+7qvtW8+sF2HH3iCKr5wSMmv4a056OGy7UHseK9RcDv Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec - Possible to use. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:58:29 -0000 I don't really understand the question. Obviously, it should be possible for WebRTC implementations (e.g., browsers) to derive codecs from the underlying platform (just as some browsers get their libc or their crypto libraries from the underlying platform). Similarly, it should be possible for browsers to allow pluggable additional codecs. In both cases these seem like features browser implementors might choose to provide at their discretion and which wouldn't be visible to Web content. Did you have something else in mind? -Ekr On Fri, Oct 19, 2012 at 6:58 AM, Hutton, Andrew wrote: > Hi, > > The question of whether it will be possible for a webrtc application to make us of video codec's (or audio codec) which are not implemented in the browser itself has been raised before but I don't think there has been a clear answer. > > Some clarity on this might help some of us to come to a conclusion on where we stand in the MTI debate. > > I looked through the archives and found some statements that indicate this should be possible but I not sure we have a definitive statement on this. For example: > > On 06 September 2012 00:29 Randall Gellens >> >> One of the goals of rtcweb is to encourage greater use of native >> codecs, and greater access to such codecs by applications such as >> those running in browsers. These are worthy goals, since native >> codecs often have better performance within the environment. >> (Examples include AMR and EVRC on handsets.) These codecs also can >> be supported out-of-the-box, no separate downloads, no signed forms. >> > > Is this really a goal we have agreement on? There does not seem to specific requirements in the requirements draft. > > Also I think there are SDP implications relating to this. How would the browser and/or application be able to build the correct SDP to offer additional codecs? > > Regards > Andy > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From pkyzivat@alum.mit.edu Fri Oct 19 08:02:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A782E21F86E9 for ; Fri, 19 Oct 2012 08:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.379 X-Spam-Level: X-Spam-Status: No, score=-0.379 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hi+OuD+Irqxo for ; Fri, 19 Oct 2012 08:02:23 -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 057F121F86E8 for ; Fri, 19 Oct 2012 08:02:21 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta14.westchester.pa.mail.comcast.net with comcast id D2aZ1k0011ei1Bg5E32S45; Fri, 19 Oct 2012 15:02:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id D32L1k00f3ZTu2S3k32MVX; Fri, 19 Oct 2012 15:02:21 +0000 Message-ID: <50816B7B.3080205@alum.mit.edu> Date: Fri, 19 Oct 2012 11:02:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201210182110.q9ILAq4K4836140@shell01.TheWorld.com> <5080F1E9.2050509@alvestrand.no> <5080F509.5020102@ericsson.com> <50811C2B.9080906@alvestrand.no> In-Reply-To: <50811C2B.9080906@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Handling a partially-useful offer (Re: Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting)) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 15:02:23 -0000 On 10/19/12 5:23 AM, Harald Alvestrand wrote: > Forking thread, since this is a new topic.... > > On 10/19/2012 08:36 AM, Stefan Hakansson LK wrote: >> On 10/19/2012 08:23 AM, Harald Alvestrand wrote: >>> On 10/18/2012 11:10 PM, Dale R. Worley wrote: >>>>> From: Harald Alvestrand >>>>> >>>>> But the API never forces the application to send an offer; sending or >>>>> not sending an offer is strictly the application's responsibility. >>>> Is the API able to report that the far end has rejected the offer? >>> The concept of "the far end" (application far end, not RTP far end) and >>> "reject" are application-level concepts, not API-level concepts. >>> So in the context of the API, I can't parse the question. >>> >>> The API can report that it was handed an SDP blob it couldn't use. >> >> One discussion I think we've not had yet is the granularity the API >> could report "can't use this SDP blob" on. Say that a new offer (in on >> ongoing sessions) was received indicating the addition of two audio >> and two video tracks (from Alice to Bob). What if Bob's browser could >> decode both audio tracks but has resources to handle only one of the >> video tracks, should it be able to tell so (perhaps with the result >> that two audio and one video track was added)? Or should the update of >> the session just fail? > > This seems to be something that should be happening to SIP endpoints too. > > I can imagine either answering with capabilities reduced to reflect what > could be handled, accepting the offer followed by generating a new offer > of reduced capabilities, or rejecting the offer. > > What is existing practice in this area? (I would not be surprised if it > was "it depends"....) Andy just talked about this. The existing practice in sip is that the answerer will accept that part of the offer that it understands and is willing to use, and refuses the rest - by setting the port number to zero in the m-lines it can't/won't support. Thanks, Paul From andrew.hutton@siemens-enterprise.com Fri Oct 19 08:08:40 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E280721F86C7 for ; Fri, 19 Oct 2012 08:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0OgNvGj1MGA for ; Fri, 19 Oct 2012 08:08:40 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 5766221F8685 for ; Fri, 19 Oct 2012 08:08:40 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 24DDC23F0596; Fri, 19 Oct 2012 17:08:39 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.76]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Fri, 19 Oct 2012 17:08:38 +0200 From: "Hutton, Andrew" To: Stefan Hakansson LK , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Video Codec - Possible to use. Thread-Index: Ac2uAdvfNfH0YMcdSYGJWOnt/4GLHP//5RsA///UtlA= Date: Fri, 19 Oct 2012 15:08:37 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0130AC2F@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF0130A96F@MCHP04MSX.global-ad.net> <50816228.4040605@ericsson.com> In-Reply-To: <50816228.4040605@ericsson.com> 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 Subject: Re: [rtcweb] Video Codec - Possible to use. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 15:08:41 -0000 On: 19 October 2012 15:23 Stefan Hakansson LK wrote: > On 10/19/2012 03:58 PM, Hutton, Andrew wrote: >=20 > > > > Also I think there are SDP implications relating to this. How would > > the browser and/or application be able to build the correct SDP to > > offer additional codecs? >=20 > To me this is a "must". Regardless of what codecs are made MTI now, > they > are likely to not be state-of-art in a few years time. That is not really the issue. Of course the browser can add support for new= codec's in years to come the question is whether the browser implementatio= n will be able to make use of codec's provided by the underlying platform o= r plugin. >=20 > I had the impression this was one of the main advantages with using > SDP: > it offers a well established way to negotiate what codec(s) to use > between end-points. >=20 SDP of course is flexible on this but will the browsers SDP implementation = be able to handle this? > Br, > Stefan >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From andrew.hutton@siemens-enterprise.com Fri Oct 19 08:20:52 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DAC21F849B for ; Fri, 19 Oct 2012 08:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCA9jZeiKITw for ; Fri, 19 Oct 2012 08:20:51 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0358421F847B for ; Fri, 19 Oct 2012 08:20:51 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 41B4A1EB8499; Fri, 19 Oct 2012 17:20:50 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.76]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Fri, 19 Oct 2012 17:20:49 +0200 From: "Hutton, Andrew" To: Eric Rescorla Thread-Topic: [rtcweb] Video Codec - Possible to use. Thread-Index: Ac2uAdvfNfH0YMcdSYGJWOnt/4GLHP//7vMA///bPHA= Date: Fri, 19 Oct 2012 15:20:49 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0130AC84@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF0130A96F@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec - Possible to use. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 15:20:52 -0000 On 19 October 2012 15:58 Eric Rescorla wrote: >=20 > I don't really understand the question. >=20 > Obviously, it should be possible for WebRTC implementations (e.g., > browsers) > to derive codecs from the underlying platform (just as some browsers > get > their libc or their crypto libraries from the underlying platform). > Similarly, > it should be possible for browsers to allow pluggable additional > codecs. > In both cases these seem like features browser implementors might > choose to provide at their discretion and which wouldn't be visible to > Web content. >=20 > Did you have something else in mind? Sorry if it is a silly question I am not so familiar with the mechanism her= e. What concerns me is that I hear it stated that using additional codec's fro= m the underlying platform is possible but can someone tell me how the corre= ct SDP would be generated? Would the browser have the information to build = the SDP for codec's it did not natively support or would the application ne= ed to craft the SDP and then if the application did it would the browser be= able to do the right thing when the app calls setLocalDescription() etc. = =20 Andy >=20 > -Ekr >=20 >=20 > On Fri, Oct 19, 2012 at 6:58 AM, Hutton, Andrew > wrote: > > Hi, > > > > The question of whether it will be possible for a webrtc application > to make us of video codec's (or audio codec) which are not implemented > in the browser itself has been raised before but I don't think there > has been a clear answer. > > > > Some clarity on this might help some of us to come to a conclusion on > where we stand in the MTI debate. > > > > I looked through the archives and found some statements that indicate > this should be possible but I not sure we have a definitive statement > on this. For example: > > > > On 06 September 2012 00:29 Randall Gellens > >> > >> One of the goals of rtcweb is to encourage greater use of native > >> codecs, and greater access to such codecs by applications such as > >> those running in browsers. These are worthy goals, since native > >> codecs often have better performance within the environment. > >> (Examples include AMR and EVRC on handsets.) These codecs also can > >> be supported out-of-the-box, no separate downloads, no signed forms. > >> > > > > Is this really a goal we have agreement on? There does not seem to > specific requirements in the requirements draft. > > > > Also I think there are SDP implications relating to this. How would > the browser and/or application be able to build the correct SDP to > offer additional codecs? > > > > Regards > > Andy > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb From ekr@rtfm.com Fri Oct 19 08:29:40 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD5A21F8743 for ; Fri, 19 Oct 2012 08:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.804 X-Spam-Level: X-Spam-Status: No, score=-102.804 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nY6GHNjJBva for ; Fri, 19 Oct 2012 08:29:39 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8139821F85F7 for ; Fri, 19 Oct 2012 08:29:39 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so669824obq.31 for ; Fri, 19 Oct 2012 08:29:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=4Kgm3yziptNGuSUduYa7wf46luWJRx33dpwHsbND1Aw=; b=NczrOI8f0cfb6prWERDZxb+i3N+yjxzX7KlDurCzOdLmLpMElcRQNgEFXDT9VSmIjY 18rXCYjgbI+LpzuRX5iyx5ltMsRLscUzRMR632VInY7cpSsupo1x/9RORIOnTs/rIBn9 /TxQIfer+0x3abJ0qAmTtN14Gmd4sXqjLKqHX0lzupVpSmcepyS3QNoSOIYSHyceXq87 qjo/vKuHvJfw8isKohFUDE7xUzhipZUoyzP/LI9x3RHV7inf+eXZO/CTkfM4XBVv+/NP +1QQ568EsK759wx2c4Ln0yAsHj7/5lgi7I3ckOny2qFQVVl0L1NdNlyL4ZfsdTxBTZtZ CJOg== Received: by 10.182.240.45 with SMTP id vx13mr726140obc.21.1350660579003; Fri, 19 Oct 2012 08:29:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.17.165 with HTTP; Fri, 19 Oct 2012 08:28:58 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0130AC84@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF0130A96F@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF0130AC84@MCHP04MSX.global-ad.net> From: Eric Rescorla Date: Fri, 19 Oct 2012 08:28:58 -0700 Message-ID: To: "Hutton, Andrew" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQluMA/5pNdwpbVA/+YnHePT/zZPLKlZ1rlx/95ZUTsXplYikaG2A6M02rOktFWNmceZp8WU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec - Possible to use. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 15:29:40 -0000 On Fri, Oct 19, 2012 at 8:20 AM, Hutton, Andrew wrote: > On 19 October 2012 15:58 Eric Rescorla wrote: >> >> I don't really understand the question. >> >> Obviously, it should be possible for WebRTC implementations (e.g., >> browsers) >> to derive codecs from the underlying platform (just as some browsers >> get >> their libc or their crypto libraries from the underlying platform). >> Similarly, >> it should be possible for browsers to allow pluggable additional >> codecs. >> In both cases these seem like features browser implementors might >> choose to provide at their discretion and which wouldn't be visible to >> Web content. >> >> Did you have something else in mind? > > Sorry if it is a silly question I am not so familiar with the mechanism h= ere. > > What concerns me is that I hear it stated that using additional codec's f= rom the underlying platform is possible but can someone tell me how the cor= rect SDP would be generated? Would the browser have the information to buil= d the SDP for codec's it did not natively support or would the application = need to craft the SDP and then if the application did it would the browser = be able to do the right thing when the app calls setLocalDescription() etc. So, obviously it depends on *exactly* what one means by the codec being available on the underlying platform. There seem to be at least two cases: 1. This is some feature provided by the OS or platform vendor. In this case presumably it comes with documentation and the browser implementor reads the documentation and the associated RFCS and generates the right SDP. In this case, the situation is not much different from that when the codec implementation is part of the browser. (Note that in many cases these codecs come from third party libraries in any case). 2. The browser supports some kind of plugin scheme which allows people to download their own codecs and install them. This would require the browser vendor to implement some interface for each codec to get a crack at the SDP and is therefore a lot more work. Which case are you concerned about? -Ekr From andrew.hutton@siemens-enterprise.com Fri Oct 19 08:49:41 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D5621F874B for ; Fri, 19 Oct 2012 08:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gp7GaE+brUUB for ; Fri, 19 Oct 2012 08:49:41 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 2521921F8744 for ; Fri, 19 Oct 2012 08:49:41 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 3312D23F04CC; Fri, 19 Oct 2012 17:49:40 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.76]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Fri, 19 Oct 2012 17:49:39 +0200 From: "Hutton, Andrew" To: Eric Rescorla Thread-Topic: [rtcweb] Video Codec - Possible to use. Thread-Index: Ac2uAdvfNfH0YMcdSYGJWOnt/4GLHP//7vMA///bPHCAAC18AP//28Ig Date: Fri, 19 Oct 2012 15:49:39 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0130ADDB@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF0130A96F@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF0130AC84@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video Codec - Possible to use. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 15:49:41 -0000 On 19 October 2012 16:29 Eric Rescorla wrote: > To: Hutton, Andrew > So, obviously it depends on *exactly* what one means by the codec being > available on the underlying platform. There seem to be at least two > cases: >=20 > 1. This is some feature provided by the OS or platform vendor. In this > case presumably it comes with documentation and the browser implementor > reads the documentation and the associated RFCS and generates the > right SDP. In this case, the situation is not much different from that > when > the codec implementation is part of the browser. (Note that in many > cases > these codecs come from third party libraries in any case). >=20 > 2. The browser supports some kind of plugin scheme which allows > people to download their own codecs and install them. This would > require > the browser vendor to implement some interface for each codec to > get a crack at the SDP and is therefore a lot more work. >=20 > Which case are you concerned about? Both and thanks your answer really helps my understanding and it seems it i= s really up to the browser vendors and nothing the IETF or W3C can do to in= fluence this. So would I be correct in thinking that at least for the immediate future we= brtc applications will be limited to the codec(s) that the browsers nativel= y support or do browser vendors intend to at least implement option 1 above= for at least some commonly used video codec's? Andy From martin.thomson@gmail.com Fri Oct 19 09:26:29 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F0B21F83EF for ; Fri, 19 Oct 2012 09:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chHrP6YQUyI2 for ; Fri, 19 Oct 2012 09:26:25 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0E121F8741 for ; Fri, 19 Oct 2012 09:26:22 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so398254wey.31 for ; Fri, 19 Oct 2012 09:26: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=/v+1BloNK/a3Yk9EPldAJsohZx7/mh+hxEou8vKsM+k=; b=lElRftkHt7Uaerk0dWSRaIjNCVlb8YkQo5eCnYMHeO0TYAzWcQJb2WxvmQynFbOqAp 4oClKkzIi+XBfEGJtJ/t38LRWPugVRKUVZckxQdg1Ve2cC81sPHrbzQeMB+WY+cVl2TD zDTCENxP39z7pjEazepmXHe7+hzzzOSXfA8Da/6gQ0u3LZY1+aWw7uZwVNGYImuDEd07 rRTvk5OU6NKTQ20uoN2e7f0b0NqQO2fJ7Db+CpaNiFdPiqnNBpvuu48oS5v8HjU4U0tN is+dOwgodAIO8eZpdM835RSC8be/1tT+Py1eV3RWfB9PBZnyOLEh1yooFw1DaTq2oWeA J36Q== MIME-Version: 1.0 Received: by 10.216.199.166 with SMTP id x38mr1151682wen.75.1350663979792; Fri, 19 Oct 2012 09:26:19 -0700 (PDT) Received: by 10.180.92.39 with HTTP; Fri, 19 Oct 2012 09:26:18 -0700 (PDT) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0130A402@MCHP04MSX.global-ad.net> References: <201210182110.q9ILAq4K4836140@shell01.TheWorld.com> <5080F1E9.2050509@alvestrand.no> <5080F509.5020102@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF0130A402@MCHP04MSX.global-ad.net> Date: Fri, 19 Oct 2012 09:26:18 -0700 Message-ID: From: Martin Thomson To: "Hutton, Andrew" Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 16:26:29 -0000 On 19 October 2012 04:55, Hutton, Andrew wrote: > On 19 October 2012 07:37 Stefan Hakansson LK wrote: >> [...] What if Bob's browser could >> decode >> both audio tracks but has resources to handle only one of the video >> tracks, should it be able to tell so (perhaps with the result that two >> audio and one video track was added)? Or should the update of the >> session just fail? > > The update to the session should not just fail. Normally in this case the answer would simple reject the one video stream and not the whole offer. A more interesting case is where Alice decides to (attempt to) switch codecs. That decision might even be based on some prior knowledge of Bob's ability to understand codecs. Maybe Bob originally offers A and B, but when Alice decides to upgrade from A to B, that is not a mode that Bob supports any more. The session should continue with A. An answer that rejected the stream would cause an interruption to the session. > [...] I am also thinking it would be nice if the API provided some way of cancelling an offer and reverting to the original state but if this is putting too much state back in the browser we would need a clearly documented mechanism. Nice or necessary? There is already a great deal of state in the browser. I am actually interested in a small modification to the API for this case, for outstanding offers there are actually three pieces of SDP in play: original local description (could be offer or answer), original remote description (answer or offer) and the new outstanding offer (which is only ever a local description, the action can be immediate on the answering side). We currently have a means to get two of these: the remote description and (I assume) the local description that was most recently set. We do not have a way to get the original local description. From harald@alvestrand.no Fri Oct 19 09:43:01 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C5F21F8849 for ; Fri, 19 Oct 2012 09:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.341 X-Spam-Level: X-Spam-Status: No, score=-110.341 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9THtHHlVnFJ for ; Fri, 19 Oct 2012 09:42:45 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6014621F875A for ; Fri, 19 Oct 2012 09:42:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 634BC39E106; Fri, 19 Oct 2012 18:42:42 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VswtWTNATWBP; Fri, 19 Oct 2012 18:42:39 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id D80F439E020; Fri, 19 Oct 2012 18:42:39 +0200 (CEST) Message-ID: <508182FF.1070107@alvestrand.no> Date: Fri, 19 Oct 2012 18:42:39 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Matthew Kaufman References: <20121015163131.3756.11599.idtracker@ietfa.amsl.com>, <507C3C0E.7060006@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090502090805090009000805" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-alvestrand-rtcweb-vp8-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 16:43:01 -0000 This is a multi-part message in MIME format. --------------090502090805090009000805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/19/2012 06:06 PM, Matthew Kaufman wrote: > I see nothing in this draft which has changed the landscape as it > existed when these blog postings were made: > > http://blogs.msdn.com/b/ie/archive/2010/05/03/follow-up-on-html5-video-in-ie9.aspx May 3, 2010 > > http://blogs.windows.com/windows/b/bloggingwindows/archive/2010/05/19/another-follow-up-on-html5-video-in-ie9.aspx Likely May 19, 2010, although the article does not say so. Since WebM was open-sourced around May 20, 2010, which postdates these articles, I guess there isn't much that you would consider to have changed the landscape. > > I think that we should only seriously consider MTI codecs which have > been developed and improved within the context of an existing > standards body, for the multitude of technical and non-technical > benefits that process provides for those who ship the codecs in their > products. > > I will note, for instance, that the Opus audio codec is a > substantially better general-purpose Internet codec than SILK as a > result of following this process. If the video-codec BOF is a success, such a codec, which is also possible to practice without onerous, secret and/or expensive permission agreements, may exist 2 years from now. At the moment, if we want open, good and developed in cooperation with a standards body, it seems that we only get 2 out of 3. At most. > > Matthew Kaufman --------------090502090805090009000805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/19/2012 06:06 PM, Matthew Kaufman wrote:
I see nothing in this draft which has changed the landscape as it existed when these blog postings were made:

http://blogs.msdn.com/b/ie/archive/2010/05/03/follow-up-on-html5-video-in-ie9.aspx
May 3, 2010
Likely May 19, 2010, although the article does not say so.

Since WebM was open-sourced around May 20, 2010, which postdates these articles, I guess there isn't much that you would consider to have changed the landscape.


I think that we should only seriously consider MTI codecs which have been developed and improved within the context of an existing standards body, for the multitude of technical and non-technical benefits that process provides for those who ship the codecs in their products.

I will note, for instance, that the Opus audio codec is a substantially better general-purpose Internet codec than SILK as a result of following this process.
If the video-codec BOF is a success, such a codec, which is also possible to practice without onerous, secret and/or expensive permission agreements,  may exist 2 years from now.

At the moment, if we want open, good and developed in cooperation with a standards body, it seems that we only get 2 out of 3. At most.

Matthew Kaufman

--------------090502090805090009000805-- From roman@telurix.com Fri Oct 19 09:51:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E9D21F8AA2 for ; Fri, 19 Oct 2012 09:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPAvNdrUwS+n for ; Fri, 19 Oct 2012 09:51:54 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C4E3321F8A27 for ; Fri, 19 Oct 2012 09:51:53 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so593465pbb.31 for ; Fri, 19 Oct 2012 09:51:53 -0700 (PDT) X-Google-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:x-gm-message-state; bh=6udOCDB2Zr/EB6yc941onu9c6As7tUGvJVNKIcFG+aI=; b=dgPFrobo4p/0CfCRbtIPb6DhBjqU5+VAEdZsPTzkvLYTRTSBgBUykXg1gryhLNR8NB aH0JvxXUaKTWQfmaaPNilpe/bNsP0SwWrwaPNyOPyWHXzHMzvpYcTzvl/zQU8fvWSsvw sAd5s+vQSwm7TGbqWfl56Xu3jFtR/++px9PRjDY7q70WHftfWVWlHLF8YkbsEbZqvoPO dRquwUCtjjLcEb7b/WMitDGDadtyC7QfWkX9uyGXd+I7Hnu/8LnoehGegkrSKJPTuc/W K1DQ3DYr/vzmuKd4md081924gCEqRHPrO1D5Sfes4plyggOteErpMGNkWR2Pc/g0Osm5 0NSw== Received: by 10.68.192.97 with SMTP id hf1mr7384704pbc.106.1350665513142; Fri, 19 Oct 2012 09:51:53 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by mx.google.com with ESMTPS id pf4sm634379pbc.38.2012.10.19.09.51.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Oct 2012 09:51:52 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so525131pad.31 for ; Fri, 19 Oct 2012 09:51:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.74.6 with SMTP id p6mr5431881pav.40.1350665512164; Fri, 19 Oct 2012 09:51:52 -0700 (PDT) Received: by 10.68.42.8 with HTTP; Fri, 19 Oct 2012 09:51:52 -0700 (PDT) In-Reply-To: References: <201210182110.q9ILAq4K4836140@shell01.TheWorld.com> <5080F1E9.2050509@alvestrand.no> <5080F509.5020102@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF0130A402@MCHP04MSX.global-ad.net> Date: Fri, 19 Oct 2012 12:51:52 -0400 Message-ID: From: Roman Shpount To: Martin Thomson Content-Type: multipart/alternative; boundary=f46d042f9318101b4404cc6c52b2 X-Gm-Message-State: ALoCoQlVJmcXUyd8sNqeZC7LuSCwamY66q+xrvt0C+y2SgO2Qu2CtIZIrJHg6WhN+G/gE9AeIWFi Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 16:51:55 -0000 --f46d042f9318101b4404cc6c52b2 Content-Type: text/plain; charset=ISO-8859-1 One other common case for offer roll back are O/A collisions. Both sides are trying to make changes to SDP at the same time, offers cross over on the wire, so, at least one side needs to rollback the offer and process the offer received. The only way I can see it implemented is to generate a hold response SDP based on the generated offer, send it to the setRemoteDescription, and then process the offer from the remote side. Mind you, this does not map well to SIP collusion handling where both offers needs to be reverted, and this will most likely generate an audio disruption even in case of only one offer being rolled back by putting on hold. _____________ Roman Shpount --f46d042f9318101b4404cc6c52b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One other common case for offer roll back are O/A=A0collisions. Both sides = are trying to make changes to SDP at the same time, offers cross over on th= e wire, so, at least one side needs to rollback the offer and process the o= ffer received. The only way I can see it implemented is to generate a hold = response SDP based on the generated offer, send it to the setRemoteDescript= ion, and then process the offer from the remote side. Mind you, this does n= ot map well to SIP=A0collusion handling where both offers needs to be rever= ted, and this will most likely generate an audio disruption even in case of= only one offer being rolled back by putting on hold.=A0
_____________
Roman Shpount

--f46d042f9318101b4404cc6c52b2-- From worley@shell01.TheWorld.com Fri Oct 19 10:16:12 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F5621F884B for ; Fri, 19 Oct 2012 10:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.926 X-Spam-Level: X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f21aaUcQcofJ for ; Fri, 19 Oct 2012 10:16:11 -0700 (PDT) Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by ietfa.amsl.com (Postfix) with ESMTP id E321721F87AA for ; Fri, 19 Oct 2012 10:16:10 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id q9JHFAmD016490 for ; Fri, 19 Oct 2012 13:15:12 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9JHFAbi4544354 for ; Fri, 19 Oct 2012 13:15:10 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9JHF95I4900050; Fri, 19 Oct 2012 13:15:09 -0400 (EDT) Date: Fri, 19 Oct 2012 13:15:09 -0400 (EDT) Message-Id: <201210191715.q9JHF95I4900050@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: rtcweb@ietf.org In-reply-to: <5080F509.5020102@ericsson.com> (stefan.lk.hakansson@ericsson.com) Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 17:16:12 -0000 [re-sent with the correct From address] > From: Stefan Hakansson LK > > One discussion I think we've not had yet is the granularity the API > could report "can't use this SDP blob" on. Say that a new offer (in on > ongoing sessions) was received indicating the addition of two audio and > two video tracks (from Alice to Bob). What if Bob's browser could decode > both audio tracks but has resources to handle only one of the video > tracks, should it be able to tell so (perhaps with the result that two > audio and one video track was added)? Or should the update of the > session just fail? Within the use case of a WebRTC server/SIP gateway, whenever the WebRTC client requests an update of SDP, the SIP far end UA can reject the update. (In regard to current practice, most of the time a UA will accept the part of the SDP that it can and make the rest inactive, but some transcoding SIP B2BUAs will fix a codec early in the dialog and refuse any SDP changes after that. In addition, some UAs do not support UPDATE at all.) The SIP gateway needs to be able to report this failure to the WebRTC client API in a usable way, and the reporting has to be asynchronous to the SDP update request. By the rules of SIP, the session state reverts to the previous session state, but it would be a reasonable architecture if the gateway was required to execute additional WebRTC actions to achieve that effect. (However, the WebRTC client must be forbidden from rejecting those actions!) In theory, the reestablishment of the previous SDP state could require renegotiating ICE (and SRTP keys?), but in practice, that would require excessive overhead, I think. Ideally, this does not require the code in the JSEP application to know specifically that the remote end is a SIP gateway, because we don't want the WebRTC client applications to have to be specially coded to support SIP gateways (or any other particular type of WebRTC server). Given that these things need to be supported, it is easy for the SIP gateway to interwork with a WebRTC architecture that allows SDP updates in states where the SIP signaling does not: If the SIP gateway receives a WebRTC SDP update in a state where an update is not permitted in SIP, it can instead send an update rejection to the WebRTC client. This allows the WebRTC offer/answer structure to be more flexible than the SIP offer/answer structure without hindering interworking (other than that sometimes WebRTC SDP updates fail). Dale From worley@shell01.TheWorld.com Fri Oct 19 10:26:11 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92FA21F8794 for ; Fri, 19 Oct 2012 10:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6XPxGtww+TO for ; Fri, 19 Oct 2012 10:26:11 -0700 (PDT) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id B69F821F8793 for ; Fri, 19 Oct 2012 10:26:10 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id q9JHOl2a001963 for ; Fri, 19 Oct 2012 13:24:49 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9JHOkm84882648 for ; Fri, 19 Oct 2012 13:24:47 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9JHOkZ84878846; Fri, 19 Oct 2012 13:24:46 -0400 (EDT) Date: Fri, 19 Oct 2012 13:24:46 -0400 (EDT) Message-Id: <201210191724.q9JHOkZ84878846@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: rtcweb@ietf.org In-reply-to: <9F33F40F6F2CD847824537F3C4E37DDF0130ADDB@MCHP04MSX.global-ad.net> (andrew.hutton@siemens-enterprise.com) Subject: Re: [rtcweb] Video Codec - Possible to use. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 17:26:12 -0000 Clearly, the API that the application uses must have some feature that allows the application to determine the codecs that are provided by the platform on which the application executes. This information must be provided in a format that plugs into the SDP, that is, the field value in the a=rtpmap line. Exactly how the API determines this information is unspecified, but of course, it is coordinated with the mechanism by which the incoming RTP is sent to the codec and ultimately displayed. And there should be a "mandatory to implement" video codec to ensure interoperation. The tricky question is which one should it be? It should be believed to be universally royalty-free. Certainly it should not require a negotiated licensing agreement, as that would suppress development by non-equipment-vendors. It does *not* have to be state of the art. It can't be too difficult to find *one* codec with these properties. Dale From martin.thomson@gmail.com Fri Oct 19 10:36:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E71D21F8777 for ; Fri, 19 Oct 2012 10:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.846 X-Spam-Level: X-Spam-Status: No, score=-3.846 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCEAr7wJ7YzK for ; Fri, 19 Oct 2012 10:36:31 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id ABEF321F876B for ; Fri, 19 Oct 2012 10:36:30 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so428208wib.13 for ; Fri, 19 Oct 2012 10:36:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f544vqLeA6aohpR80TVEOdcjqDBNyLIU0OyF2Plyohk=; b=git6xp7Q63OP4EXbWlpartOkoXDe/F4ODUQgCAf2qg53MeM+hIlzsbOIN2gkNOr543 d0KBI4ur85nEsk4vAQ1kYOA5mj2zWlo2pakHVx17q1q73vCKv8H1zVoNTKa/WJEaUcEj FQd559srbwcqv7zLXyZik7U3/ehnYyFIcSJVOMuLZvuuzQeVGQ5psxVasoh/Txs/psDJ wKtA/uEcfXv9wdeyCEvEpQ50sSZs43CHVojb05DwLhpMb8NBH/rJTKsJTCHmoRaLUQtK T9ST2lQISCPgouPRRD196/KNXf2Lm3x0xXCiXc/GAqNuP84LEB1MczbtwEW/5+T4+wgA SSwA== MIME-Version: 1.0 Received: by 10.180.19.71 with SMTP id c7mr20538825wie.2.1350668189637; Fri, 19 Oct 2012 10:36:29 -0700 (PDT) Received: by 10.180.92.39 with HTTP; Fri, 19 Oct 2012 10:36:29 -0700 (PDT) In-Reply-To: <201210191724.q9JHOkZ84878846@shell01.TheWorld.com> References: <9F33F40F6F2CD847824537F3C4E37DDF0130ADDB@MCHP04MSX.global-ad.net> <201210191724.q9JHOkZ84878846@shell01.TheWorld.com> Date: Fri, 19 Oct 2012 10:36:29 -0700 Message-ID: From: Martin Thomson To: "Dale R. Worley" Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Video Codec - Possible to use. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 17:36:31 -0000 On 19 October 2012 10:24, Dale R. Worley wrote: > It can't be too difficult to find *one* codec with these properties. RFC 2435 was not considered adequate for the described use cases. From fluffy@cisco.com Fri Oct 19 11:59:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC1221F87E0 for ; Fri, 19 Oct 2012 11:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.51 X-Spam-Level: X-Spam-Status: No, score=-110.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmlbR63fQTsa for ; Fri, 19 Oct 2012 11:59:51 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1765821F87AE for ; Fri, 19 Oct 2012 11:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1109; q=dns/txt; s=iport; t=1350673191; x=1351882791; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=8p25TVpXv4FFWGU7+MrAol/2qgy+QMz7eHmbOuWTve4=; b=k6bOv4Ic7ImRSe92QU5hYtu2PiI6nDXt83DbTyj13zdfRMo0eTfW8aiF mxr2YYAoIGeot4AMk8D2uq5AwapKVNzTRueMlZxW9dlqSvfDo5G+5+JZx T7Wcog/itcNoPZypMQGJlmTitEncGUAPKaQyFH/jBKHmoaRm1fZOVUoA8 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAE+igVCtJXG+/2dsb2JhbABFwHKBCIIiAQQSASc/EgEqFEInBA4NGodinBSgIJFpYAOkPIFrgm+CGA X-IronPort-AV: E=Sophos;i="4.80,615,1344211200"; d="scan'208";a="133537886" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 19 Oct 2012 18:59:50 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9JIxogm002988 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Oct 2012 18:59:50 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Fri, 19 Oct 2012 13:59:50 -0500 From: "Cullen Jennings (fluffy)" To: "rtcweb@ietf.org" Thread-Topic: Draft agenda for RTCWeb session 2 at IETF85 Thread-Index: AQHNrivq8oeI28mUY0KtpB99zlJ4jw== Date: Fri, 19 Oct 2012 18:59:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--21.465500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <4C1EDE7E7D3A484FB6D46D62679A32C9@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rtcweb] Draft agenda for RTCWeb session 2 at IETF85 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 18:59:51 -0000 We have two WebRTC session at the next IETF. We have not worked out the age= nda for the first session yet but our current plan is to dedicate the secon= d session to the MTI video codec question.=20 The draft agenda for this season is: Admin issues (5 min) IPR at the IETF ( 10 min ) - this is a reminder of IETF rules and guidelines around IPR Presentations ( 80 min ) - a 20 minute presentation from each of the following drafts=20 draft-alvestrand-rtcweb-vp8-00 draft-burman-rtcweb-h264-proposal-00 draft-dbenham-webrtc-videomti-00 draft-marjou-rtcweb-video-codec-00 - If the authors of drafts recommending the same codec can consult with each other to avoid overlap, or even merge presentations, the recovered time would be given to the general discussion. General discussion ( 30 min ) - general time for everyone to speak at the mic to express information impo= rtant for the decision Call the question of which mandatory to implement video codec to select ( = 5 min ) Next steps ( 20 min ) Cullen, Magnus, and Ted From pkyzivat@alum.mit.edu Fri Oct 19 17:06:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCAB21F8865 for ; Fri, 19 Oct 2012 17:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.38 X-Spam-Level: X-Spam-Status: No, score=-0.38 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3HSMvRs2Qyv for ; Fri, 19 Oct 2012 17:06:33 -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 8659E21F885D for ; Fri, 19 Oct 2012 17:06:33 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta02.westchester.pa.mail.comcast.net with comcast id DBn01k0010xGWP851C6d1U; Sat, 20 Oct 2012 00:06:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id DC5Z1k0083ZTu2S3YC5ZQ1; Sat, 20 Oct 2012 00:05:33 +0000 Message-ID: <5081EB07.8000703@alum.mit.edu> Date: Fri, 19 Oct 2012 20:06:31 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <201210182110.q9ILAq4K4836140@shell01.TheWorld.com> <5080F1E9.2050509@alvestrand.no> <5080F509.5020102@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF0130A402@MCHP04MSX.global-ad.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Oct 2012 00:06:34 -0000 On 10/19/12 12:26 PM, Martin Thomson wrote: > On 19 October 2012 04:55, Hutton, Andrew > wrote: >> On 19 October 2012 07:37 Stefan Hakansson LK wrote: >>> [...] What if Bob's browser could >>> decode >>> both audio tracks but has resources to handle only one of the video >>> tracks, should it be able to tell so (perhaps with the result that two >>> audio and one video track was added)? Or should the update of the >>> session just fail? >> >> The update to the session should not just fail. Normally in this case the answer would simple reject the one video stream and not the whole offer. > > A more interesting case is where Alice decides to (attempt to) switch > codecs. That decision might even be based on some prior knowledge of > Bob's ability to understand codecs. Maybe Bob originally offers A and > B, but when Alice decides to upgrade from A to B, that is not a mode > that Bob supports any more. The session should continue with A. > > An answer that rejected the stream would cause an interruption to the session. Well, actually it would interrupt the media stream (rtp session). I agree there are cases where rejecting the offer would make more sense. That is certainly an option in sip. Deciding whether it is better to reject the media stream, or reject the offer can be tricky. A more important aspect of this scenario is how it is managed on the offering side. When Alice makes the attempt, does she assume success and immediately put the offered SDP into operation? (And then undo it if the offer fails.) Or does the old local/remote SDP remain in effect until the answer is received? SIP says that you must be prepared to receive according to the new offer as soon as it is sent. And yet the stuff you are receiving will still be in accord to the old o/a until the new offer is received by the answerer. And the offerer should still be sending according to the old stuff until it receives the answer. Hence there is a time period when you need to support *both*. If you switch too soon you may receive old stuff you can't deal with. And if you switch too soon and the offer is rejected then you will have to switch back, and there will be more disruption. This is pretty ugly, and unless you can actually support both old and new concurrently (which many cannot) then you are forced to choose among bad choices for how to implement. But webrtc can't ignore this. It must acknowledge this and provide some mechanisms to deal with it. Thanks, Paul >> [...] I am also thinking it would be nice if the API provided some way of cancelling an offer and reverting to the original state but if this is putting too much state back in the browser we would need a clearly documented mechanism. > > Nice or necessary? There is already a great deal of state in the browser. > > I am actually interested in a small modification to the API for this > case, for outstanding offers there are actually three pieces of SDP in > play: original local description (could be offer or answer), original > remote description (answer or offer) and the new outstanding offer > (which is only ever a local description, the action can be immediate > on the answering side). We currently have a means to get two of > these: the remote description and (I assume) the local description > that was most recently set. We do not have a way to get the original > local description. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From bernard_aboba@hotmail.com Sat Oct 20 01:12:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39AC21F860D for ; Sat, 20 Oct 2012 01:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.105 X-Spam-Level: X-Spam-Status: No, score=-102.105 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wdx5lFgSMokD for ; Sat, 20 Oct 2012 01:12:42 -0700 (PDT) Received: from blu0-omc3-s13.blu0.hotmail.com (blu0-omc3-s13.blu0.hotmail.com [65.55.116.88]) by ietfa.amsl.com (Postfix) with ESMTP id CE4A221F890F for ; Sat, 20 Oct 2012 01:12:41 -0700 (PDT) Received: from BLU002-W62 ([65.55.116.74]) by blu0-omc3-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 20 Oct 2012 01:12:37 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_b4d23681-3a5b-481e-ad88-fae6a78171e3_" X-Originating-IP: [24.16.96.166] From: Bernard Aboba To: "rtcweb@ietf.org" Date: Sat, 20 Oct 2012 01:12:37 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 20 Oct 2012 08:12:37.0881 (UTC) FILETIME=[AAE2F690:01CDAE9A] Subject: [rtcweb] RTCWEB Session 2: A plea for brevity X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Oct 2012 08:12:42 -0000 --_b4d23681-3a5b-481e-ad88-fae6a78171e3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I respectfully submit that the allocating the entire 150 minute session to = the video codec MTI isssue is not the best use of the WG's time. =20 Do we really have to allocate 20 minutes to *each* draft? Since 3 of =0A= the presentations are favoring H.264 and only one is pushing VP8=2C the =0A= fairness of this approach is questionable=2C and since brevity is the soul= =0A= of wit (and argument)=2C I believe that each side could probably do the = =0A= job in 20 minutes max=2C including example videos. =20 If we spend=2C 40 minutes on presentations=2C 30 minutes on discussion and = 20 minutes on the combination of consensus and next steps=2C then that woul= d leave an hour for other important issues=2C such as the way forward on SD= P.=20 > From: fluffy@cisco.com > To: rtcweb@ietf.org > Date: Fri=2C 19 Oct 2012 18:59:50 +0000 > Subject: [rtcweb] Draft agenda for RTCWeb session 2 at IETF85 >=20 >=20 > We have two WebRTC session at the next IETF. We have not worked out the a= genda for the first session yet but our current plan is to dedicate the sec= ond session to the MTI video codec question.=20 >=20 > The draft agenda for this season is: >=20 > Admin issues (5 min) >=20 > IPR at the IETF ( 10 min ) > - this is a reminder of IETF rules and guidelines around IPR >=20 > Presentations ( 80 min ) > - a 20 minute presentation from each of the following drafts=20 > draft-alvestrand-rtcweb-vp8-00 > draft-burman-rtcweb-h264-proposal-00 > draft-dbenham-webrtc-videomti-00 > draft-marjou-rtcweb-video-codec-00 > - If the authors of drafts recommending the same codec can consult with > each other to avoid overlap=2C or even merge presentations=2C the > recovered time would be given to the general discussion. >=20 >=20 > General discussion ( 30 min ) > - general time for everyone to speak at the mic to express information im= portant for the decision >=20 >=20 > Call the question of which mandatory to implement video codec to select = ( 5 min ) >=20 >=20 > Next steps ( 20 min ) >=20 >=20 > Cullen=2C Magnus=2C and Ted >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --_b4d23681-3a5b-481e-ad88-fae6a78171e3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I respectfully submit that the a= llocating the entire 150 minute session to the video codec MTI isssue is no= t the best use of the WG's time. =3B =3B

Do we really = =3B have to allocate 20 minutes to *each* draft? =3B Since 3 of =0A= the presentations are favoring H.264 and only one is pushing VP8=2C the =0A= fairness of this approach is questionable=2C and since brevity is the soul= =0A= of wit (and argument)=2C I believe that each side could probably do the = =0A= job in 20 minutes max=2C including example videos. =3B =3B

= If we spend=2C 40 minutes on presentations=2C 30 minutes on discussion and = 20 minutes on the combination of consensus and next steps=2C then that woul= d leave an hour for other important issues=2C such as the way forward on SD= P.


>=3B From: fluf= fy@cisco.com
>=3B To: rtcweb@ietf.org
>=3B Date: Fri=2C 19 Oct 20= 12 18:59:50 +0000
>=3B Subject: [rtcweb] Draft agenda for RTCWeb sessi= on 2 at IETF85
>=3B
>=3B
>=3B We have two WebRTC session a= t the next IETF. We have not worked out the agenda for the first session ye= t but our current plan is to dedicate the second session to the MTI video c= odec question.
>=3B
>=3B The draft agenda for this season is:>=3B
>=3B Admin issues (5 min)
>=3B
>=3B IPR at the IE= TF ( 10 min )
>=3B - this is a reminder of IETF rules and guidelines a= round IPR
>=3B
>=3B Presentations ( 80 min )
>=3B - a 20 mi= nute presentation from each of the following drafts
>=3B draft-a= lvestrand-rtcweb-vp8-00
>=3B draft-burman-rtcweb-h264-proposal-00=
>=3B draft-dbenham-webrtc-videomti-00
>=3B draft-marjo= u-rtcweb-video-codec-00
>=3B - If the authors of drafts recommending t= he same codec can consult with
>=3B each other to avoid overlap=2C or = even merge presentations=2C the
>=3B recovered time would be given to = the general discussion.
>=3B
>=3B
>=3B General discussion = ( 30 min )
>=3B - general time for everyone to speak at the mic to ex= press information important for the decision
>=3B
>=3B
>= =3B Call the question of which mandatory to implement video codec to select= ( 5 min )
>=3B
>=3B
>=3B Next steps ( 20 min )
>=3B=
>=3B
>=3B Cullen=2C Magnus=2C and Ted <=3BRTCWeb Chairs>= =3B
>=3B
>=3B
>=3B
>=3B
>=3B _________________= ______________________________
>=3B rtcweb mailing list
>=3B rtcw= eb@ietf.org
>=3B https://www.ietf.org/mailman/listinfo/rtcweb
= --_b4d23681-3a5b-481e-ad88-fae6a78171e3_-- From harald@alvestrand.no Sat Oct 20 02:54:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB5721F859C for ; Sat, 20 Oct 2012 02:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.374 X-Spam-Level: X-Spam-Status: No, score=-110.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vmWKDTn1Q-E for ; Sat, 20 Oct 2012 02:54:32 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA3421F8593 for ; Sat, 20 Oct 2012 02:54:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EC7A439E1C2; Sat, 20 Oct 2012 11:54:29 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFy2SnMDp5S4; Sat, 20 Oct 2012 11:54:28 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id DDF4539E03A; Sat, 20 Oct 2012 11:54:28 +0200 (CEST) Message-ID: <508274D4.6040303@alvestrand.no> Date: Sat, 20 Oct 2012 11:54:28 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Matthew Kaufman References: <201210182110.q9ILAq4K4836140@shell01.TheWorld.com> <5080F1E9.2050509@alvestrand.no>, In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Oct 2012 09:54:33 -0000 On 10/19/2012 04:26 PM, Matthew Kaufman wrote: > Iaki Baz Castillo [ibc@aliax.net]: >> SIP and XMPP are signaling protocols using SDP and fit very well into >> the state machine defined in RFC 3264. In WebRTC we DON'T have a >> (network) signaling protocol and, thus, it's the JavaScript >> responsability to respect or not RFC 3264 rules, but those rules >> cannot be mandated at the media stack level. >> >> So honestly I don't fully understand what we are discussing in this >> thread. Regards. Inaki is not alone. The text in the JSEP draft could definitely bear improving. But I have problems parsing the definition of "compliant" here: > What I am hoping to discuss is whether the JSEP API (which repeatedly claims to be exposing an RFC3264 SDP O/A compliant API surface*) has or has not "relaxed" RFC3264. I think it is pretty clear that it has (in that it does not in fact enforce any of "MUST NOT" called out in RFC3264 at the API level), in that I would expect a "compliant" API to be one that permits an RFC 3264 protocol machine to be built on top of it, which doesn't make the sentence above logical > and so now that we don't have an API that complies with SDP O/A .... a premise I don't believe. > *any* API that doesn't comply with SDP O/A should be equally acceptable. .... but this conclusion is still completely bizarre to me. RFC 3264 compliance (for whatever definition of compliance) is just one aspect of the considerations of what main direction of API to choose. Anyone who wasn't part of the WEBRTC discussions is free to consult the archives of the recent discussion for the other reasons put forward. "Equally acceptable" is a very strange phrase to use in this discussion (which, anyway, is in the wrong forum). From john@jlc.net Sat Oct 20 06:48:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A80921F8551 for ; Sat, 20 Oct 2012 06:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.441 X-Spam-Level: X-Spam-Status: No, score=-106.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhOG69r3Pjlq for ; Sat, 20 Oct 2012 06:48:34 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id ABA0F21F8538 for ; Sat, 20 Oct 2012 06:48:34 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 1B36433C24; Sat, 20 Oct 2012 09:48:34 -0400 (EDT) Date: Sat, 20 Oct 2012 09:48:34 -0400 From: John Leslie To: Bernard Aboba Message-ID: <20121020134833.GE44606@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB Session 2: A plea for brevity X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Oct 2012 13:48:35 -0000 Bernard Aboba wrote: >... > Do we really have to allocate 20 minutes to *each* draft?... +1 (Disclaimer: I won't be there, but I will be listening.) -- John Leslie From fluffy@iii.ca Sat Oct 20 07:16:03 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F4321F84B2 for ; Sat, 20 Oct 2012 07:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rjh+wKCJlRX0 for ; Sat, 20 Oct 2012 07:16:02 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 92E9F21F84A2 for ; Sat, 20 Oct 2012 07:16:02 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 24A1322E253; Sat, 20 Oct 2012 10:15:51 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Cullen Jennings In-Reply-To: <20121020134833.GE44606@verdi> Date: Sat, 20 Oct 2012 08:15:50 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <28739B70-EC86-4C86-87BD-64A3F8C9D060@iii.ca> References: <20121020134833.GE44606@verdi> To: John Leslie , Bernard Aboba X-Mailer: Apple Mail (2.1499) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB Session 2: A plea for brevity X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Oct 2012 14:16:03 -0000 On Oct 20, 2012, at 7:48 AM, John Leslie wrote: > Bernard Aboba wrote: >> ... >> Do we really have to allocate 20 minutes to *each* draft?... >=20 > +1 The agenda is draft and I'm sure I and the other chairs will take the = feedback we get into account as we refine this closer to the meeting. = The MTI video codec is a pretty big questions we are asking and my = observation about getting consensus is that people need to have been = given the time to make their key argument or it is very hard to get to = consensus. I realize that some people believe, or even hope, that we = will not get to consensus on this topic so it is all a waste of time but = the WG has made it clear it does want to get to have a MTI video codec.=20= So consider the situation we are in. One of the drafts says when making = measurements on quality they found A was better than B while the another = draft says B was better than A. Several people have asked me how this = could happen two different groups ended up with opposite measurements = and they want to understand more about how this could have happened and = which is correct.=20 Let me ask you guys a question, how many people do you think will be in = the microphone line up when theses two are discussed? You have both seen = plenty of controversial topics discussed at other ietf meetings. What = would you recommend to people making slides for a slot like this - how = many slides do you think they can reasonably get through in a time slot = like this? What would your best guess be of how long we need to make = these slots such that the chairs don't have to cut off the mic lineup?=20= I know you could take these as vaguely cynical rhetorical questions but = I don't mean them that way. I'm straight up asking you how much time you = think we need such that authors of the drafts can make their key = argument and people that have questions or disagreements that they think = are important for the WG to understand can make ask their question. Cullen From harald@alvestrand.no Sat Oct 20 07:21:49 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2893D21F8470 for ; Sat, 20 Oct 2012 07:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.398 X-Spam-Level: X-Spam-Status: No, score=-110.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbgP71POptob for ; Sat, 20 Oct 2012 07:21:48 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3C06821F8445 for ; Sat, 20 Oct 2012 07:21:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EAF3239E1C2 for ; Sat, 20 Oct 2012 16:21:45 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQjEx0IjUxfC for ; Sat, 20 Oct 2012 16:21:45 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 24DBD39E03A for ; Sat, 20 Oct 2012 16:21:45 +0200 (CEST) Message-ID: <5082B379.5030908@alvestrand.no> Date: Sat, 20 Oct 2012 16:21:45 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070807050708020209030707" Subject: Re: [rtcweb] RTCWEB Session 2: A plea for brevity X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Oct 2012 14:21:49 -0000 This is a multi-part message in MIME format. --------------070807050708020209030707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/20/2012 10:12 AM, Bernard Aboba wrote: > I respectfully submit that the allocating the entire 150 minute > session to the video codec MTI isssue is not the best use of the WG's > time. > > Do we really have to allocate 20 minutes to *each* draft? Since 3 of > the presentations are favoring H.264 and only one is pushing VP8, the > fairness of this approach is questionable, and since brevity is the > soul of wit (and argument), I believe that each side could probably do > the job in 20 minutes max, including example videos. > > If we spend, 40 minutes on presentations, 30 minutes on discussion and > 20 minutes on the combination of consensus and next steps, then that > would leave an hour for other important issues, such as the way > forward on SDP. To my mind, the discussion so far has matured to the point where the presentations' salient points could be made in two sentences: - Technical quality: Close enough that it doesn't matter. - IPR conditions: Different enough that it matters. Different people have made different qualitative evaluation of "which one is best". I have not yet heard anyone say "if X is N% better on measurement Y, I will support that one". Given what lawyers say when I ask them if I can say anything about legal topics (including opinions about other people's licensing terms), it'll be hard to have a meaningful discussion on the point that matters. This is a problem. I don't know how to resolve it. But I'd rather be discussing SDP than having 150 minutes of discussion on the stuff that doesn't matter because we can't come to grips with the stuff that matters. --------------070807050708020209030707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/20/2012 10:12 AM, Bernard Aboba wrote:
I respectfully submit that the allocating the entire 150 minute session to the video codec MTI isssue is not the best use of the WG's time.  

Do we really  have to allocate 20 minutes to *each* draft?  Since 3 of the presentations are favoring H.264 and only one is pushing VP8, the fairness of this approach is questionable, and since brevity is the soul of wit (and argument), I believe that each side could probably do the job in 20 minutes max, including example videos.  

If we spend, 40 minutes on presentations, 30 minutes on discussion and 20 minutes on the combination of consensus and next steps, then that would leave an hour for other important issues, such as the way forward on SDP.

To my mind, the discussion so far has matured to the point where the presentations' salient points could be made in two sentences:

- Technical quality: Close enough that it doesn't matter.
- IPR conditions: Different enough that it matters.

Different people have made different qualitative evaluation of "which one is best". I have not yet heard anyone say "if X is N% better on measurement Y, I will support that one".

Given what lawyers say when I ask them if I can say anything about legal topics (including opinions about other people's licensing terms), it'll be hard to have a meaningful discussion on the point that matters.

This is a problem. I don't know how to resolve it. But I'd rather be discussing SDP than having 150 minutes of discussion on the stuff that doesn't matter because we can't come to grips with the stuff that matters.

--------------070807050708020209030707-- From bernard_aboba@hotmail.com Sat Oct 20 09:12:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11FBA21F8699 for ; Sat, 20 Oct 2012 09:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.92 X-Spam-Level: X-Spam-Status: No, score=-100.92 tagged_above=-999 required=5 tests=[AWL=-0.735, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnBpc2ZklVuh for ; Sat, 20 Oct 2012 09:12:46 -0700 (PDT) Received: from blu0-omc3-s18.blu0.hotmail.com (blu0-omc3-s18.blu0.hotmail.com [65.55.116.93]) by ietfa.amsl.com (Postfix) with ESMTP id 59E6121F8698 for ; Sat, 20 Oct 2012 09:12:46 -0700 (PDT) Received: from BLU169-DS2 ([65.55.116.72]) by blu0-omc3-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 20 Oct 2012 09:12:45 -0700 X-Originating-IP: [24.16.96.166] X-EIP: [SBsOOuxiL776NouialYY7Pe6s96/WHCR] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: "'Cullen Jennings'" References: <20121020134833.GE44606@verdi> <28739B70-EC86-4C86-87BD-64A3F8C9D060@iii.ca> In-Reply-To: <28739B70-EC86-4C86-87BD-64A3F8C9D060@iii.ca> Date: Sat, 20 Oct 2012 09:13:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK9TaGyylKG2dw5ecTUCOnLzDVNrQFbqzgFAa7tI04CjpuLHZW2UbwA Content-Language: en-us X-OriginalArrivalTime: 20 Oct 2012 16:12:45.0862 (UTC) FILETIME=[BDC80460:01CDAEDD] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB Session 2: A plea for brevity X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Oct 2012 16:12:47 -0000 Cullen Jennings said: "One of the drafts says when making measurements on quality they found A was better than B while the another draft says B was better than A. Several people have asked me how this could happen two different groups ended up with opposite measurements and they want to understand more about how this could have happened and which is correct.... Let me ask you guys a question, how many people do you think will be in the microphone line up when these two are discussed?"" [BA] Assuming those at the mic would be asking clarifying questions, why do we need to wait until IETF 85 to begin that discussion? If each side were to start a thread on the list, at least some of the clarifying questions could be gotten out of the way beforehand. Who knows, the result could be akin to letting a child stay up late on Saturday night to watch TV - the little devil might be too tired to cause trouble at church on Sunday :) From bernard_aboba@hotmail.com Sat Oct 20 09:42:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F23821F8784 for ; Sat, 20 Oct 2012 09:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.096 X-Spam-Level: X-Spam-Status: No, score=-102.096 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cX2YSYFvZ0gS for ; Sat, 20 Oct 2012 09:42:45 -0700 (PDT) Received: from blu0-omc3-s17.blu0.hotmail.com (blu0-omc3-s17.blu0.hotmail.com [65.55.116.92]) by ietfa.amsl.com (Postfix) with ESMTP id DB4EC21F87D9 for ; Sat, 20 Oct 2012 09:42:43 -0700 (PDT) Received: from BLU002-W76 ([65.55.116.74]) by blu0-omc3-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 20 Oct 2012 09:41:45 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_7faf1d31-2729-4812-af8e-ac8c695663eb_" X-Originating-IP: [24.16.96.166] From: Bernard Aboba To: "rtcweb@ietf.org" Date: Sat, 20 Oct 2012 09:41:45 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 20 Oct 2012 16:41:45.0602 (UTC) FILETIME=[CABF4620:01CDAEE1] Subject: [rtcweb] Mobile tests in draft-dbenham-webrtc-videomti X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Oct 2012 16:42:46 -0000 --_7faf1d31-2729-4812-af8e-ac8c695663eb_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Looking at the videos from Section 4=2C using the same software on both sid= es might help tease out implementation effects. My understanding is that B= ria (at least on the iPad) supports both H.264 and VP8=2C and it would appe= ar that Linphone also supports both. Would it be possible to compare a Bri= a/Linphone conversation with H.264 to one using VP8? >From Section 4: Captures of Mobile Tests=3B=0A= =0A= FaceTime using H.264 on an iPhone to linphone on a fast desktop PC.=0A= http://dl.dropbox.com/u/17089001/video-samples/facetime.mov=0A= =0A= Bria using VP8 on iPhone to linphone on a fast desktop PC. http://=0A= dl.dropbox.com/u/17089001/video-samples/iphone-vp8-vs-iphone-264.mov=0A= =0A= Bria using VP8 on Galaxy Nexus to linphone on a fast desktop PC.=0A= http://dl.dropbox.com/u/17089001/video-samples/galaxy-nexus.mov=0A= =0A= Shown side-by-side=2C Bria using VP8 on iPhone (left) and FaceTime with= =0A= H.264/AVC on iPhone (right)=2C going to linphone and FaceTime. http://= =0A= dl.dropbox.com/u/17089001/video-samples/iphone-vp8-vs-iphone-264.mov=0A= =0A= Captures of Desktop-only Tests=3B=0A= =0A= FaceTime H.264/AVC from a fast notebook computer to fast desktop. htt=0A= p://dl.dropbox.com/u/17089001/video-samples/facetime-264-desktop.mov=0A= =0A= -or- http://dl.dropbox.com/u/17089001/video-samples/=0A= facetime-264-desktop.webm=0A= =0A= Chrome with VP8 from same fast notebook computer to same fast=0A= desktop.=0A= http://dl.dropbox.com/u/17089001/video-samples/chrome-vp8-desktop.mov=0A= =0A= -or- http://dl.dropbox.com/u/17089001/video-samples/=0A= chrome-vp8-desktop.webm=0A= =0A= Two fast notebook computers - one running Chrome and the other=0A= running Fictive - both sending to the same desktop computer shown=0A= side by side. http://dl.dropbox.com/u/17089001/video-samples/=0A= chrome_and_factime_desktop.mov>=0A= =0A= -or- http://dl.dropbox.com/u/17089001/video-samples/=0A= chrome_and_factime_desktop.webm = --_7faf1d31-2729-4812-af8e-ac8c695663eb_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Looking at the videos from Secti= on 4=2C using the same software on both sides might help tease out implemen= tation effects. =3B My understanding is that Bria (at least on the iPad= ) supports both H.264 and VP8=2C and it would appear that Linphone also sup= ports both. =3B Would it be possible to compare a Bria/Linphone convers= ation with H.264 to one using VP8?

From Section 4:

Captu=
res of Mobile Tests=3B=0A=
=0A=
   FaceTime using H.264 on an iPhone to linphone on a fast desktop PC.=0A=
   http://dl.dropbox.com/u/17089001/video-samples/facetime.mov=0A=
=0A=
   Bria using VP8 on iPhone to linphone on a fast desktop PC. http://=0A=
   dl.dropbox.com/u/17089001/video-samples/iphone-vp8-vs-iphone-264.mov=0A=
=0A=
   Bria using VP8 on Galaxy Nexus to linphone on a fast desktop PC.=0A=
   http://dl.dropbox.com/u/17089001/video-samples/galaxy-nexus.mov=0A=
=0A=
   Shown side-by-side=2C Bria using VP8 on iPhone (left) and FaceTime with=
=0A=
   H.264/AVC on iPhone (right)=2C going to linphone and FaceTime. http://=
=0A=
   dl.dropbox.com/u/17089001/video-samples/iphone-vp8-vs-iphone-264.mov=0A=
=0A=
   Captures of Desktop-only Tests=3B=0A=
=0A=
   FaceTime H.264/AVC from a fast notebook computer to fast desktop. htt=0A=
   p://dl.dropbox.com/u/17089001/video-samples/facetime-264-desktop.mov=0A=
=0A=
   -or- http://dl.dropbox.com/u/17089001/video-samples/=0A=
   facetime-264-desktop.webm=0A=
=0A=
   Chrome with VP8 from same fast notebook computer to same fast=0A=
   desktop.=0A=
   http://dl.dropbox.com/u/17089001/video-samples/chrome-vp8-desktop.mov=0A=
=0A=
   -or- http://dl.dropbox.com/u/17089001/video-samples/=0A=
   chrome-vp8-desktop.webm=0A=
=0A=
   Two fast notebook computers - one running Chrome and the other=0A=
   running Fictive - both sending to the same desktop computer shown=0A=
   side by side. http://dl.dropbox.com/u/17089001/video-samples/=0A=
   chrome_and_factime_desktop.mov>=3B=0A=
=0A=
   -or- http://dl.dropbox.com/u/17089001/video-samples/=0A=
   chrome_and_factime_desktop.webm

= --_7faf1d31-2729-4812-af8e-ac8c695663eb_-- From matthew@matthew.at Sat Oct 20 10:10:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFF621F85F9 for ; Sat, 20 Oct 2012 10:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.059 X-Spam-Level: X-Spam-Status: No, score=0.059 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgjD0M2yr85r for ; Sat, 20 Oct 2012 10:10:09 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05AC821F873F for ; Sat, 20 Oct 2012 10:10:07 -0700 (PDT) Received: from [10.10.155.229] (unknown [10.10.155.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 48CF6148069 for ; Sat, 20 Oct 2012 10:10:03 -0700 (PDT) Message-ID: <5082DAEB.6000604@matthew.at> Date: Sat, 20 Oct 2012 10:10:03 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] testing from personal account X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Oct 2012 17:10:10 -0000 Please excuse the test message, but several emails I sent to the list from my work account over the last couple of days appear to have been dropped and not delivered to the list. Matthew Kaufman From matthew@matthew.at Sat Oct 20 10:21:54 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE6021F87CB for ; Sat, 20 Oct 2012 10:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.685 X-Spam-Level: X-Spam-Status: No, score=-0.685 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1A4wbI+TaOFD for ; Sat, 20 Oct 2012 10:21:53 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id A513921F879D for ; Sat, 20 Oct 2012 10:21:53 -0700 (PDT) Received: from [10.10.155.229] (unknown [10.10.155.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 7BC9D148096 for ; Sat, 20 Oct 2012 10:21:51 -0700 (PDT) Message-ID: <5082DDAF.7080102@matthew.at> Date: Sat, 20 Oct 2012 10:21:51 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary="------------020704050602070205060608" Subject: [rtcweb] (resend) RE: Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Oct 2012 17:21:54 -0000 This is a multi-part message in MIME format. --------------020704050602070205060608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit (Resending from my personal account as the list server dropped a bunch of messages and I will be resending from my personal account a few that I think are still particularly relevant) Harald Alvestrand [harald@alvestrand.no]: > > Because making an interface that makes following an existing practice > easy (but does not enforce all the constraints of that practice) is > better than making an interface that makes following that practice > very complex? If this myth were correct, it would be a good argument. In practice, the JSEP interface (which claims to loosely follow an existing practice) is *more difficult* to use when interoperating with endpoints that actually follow that practice than the API we proposed does. In our testing, the amount of Javascript required to unpack the pile of SDP that is emitted by an existing implementation of JSEP (the Google Chrome beta), pick it apart into what you actually need to interop with a real gateway endpoint, exhaustively test what SDP can then be put back in to setLocalDescription and setRemoteDescription (as there is no specification saying what SDP is and is not allowed here, and no error reporting to speak of), and then the signaling on top of that all adds up to more than twice as much Javascript as it takes to use our proposed direct-manipulation API, create SDP that is compatible with the far end you are interoperating with, and start media flowing. If the existing API actually had a description of what SDP is and is not acceptable, and specified an error reporting mechanism that was actually helpful for developers, then it would *still* take 2x the Javascript to call any endpoint other than one of your own because of the need to manipulate the SDP and the need to implement a state machine in Javascript while the browser is also keeping a bunch of state internally. I encourage anyone who cares about interoperability to replicate our experiment... build an application using the Chrome beta that calls a gateway speaking SIP for signaling and ICE-lite for consent verification and see how "easy" it is or isn't. Matthew Kaufman --------------020704050602070205060608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit (Resending from my personal account as the list server dropped a bunch of messages and I will be resending from my personal account a few that I think are still particularly relevant)

Harald Alvestrand [harald@alvestrand.no]:

> 

> Because making an interface that makes following an existing practice

> easy (but does not enforce all the constraints of that practice) is

> better than making an interface that makes following that practice

> very complex?

 

If this myth were correct, it would be a good argument. In practice, the JSEP interface (which claims to loosely follow an existing practice) is *more difficult* to use when interoperating with endpoints that actually follow that practice than the API we proposed does.

 

In our testing, the amount of Javascript required to unpack the pile of SDP that is emitted by an existing implementation of JSEP (the Google Chrome beta), pick it apart into what you actually need to interop with a real gateway endpoint, exhaustively test what SDP can then be put back in to setLocalDescription and setRemoteDescription (as there is no specification saying what SDP is and is not allowed here, and no error reporting to speak of), and then the signaling on top of that all adds up to more than twice as much Javascript as it takes to use our proposed direct-manipulation API, create SDP that is compatible with the far end you are interoperating with, and start media flowing.

 

If the existing API actually had a description of what SDP is and is not acceptable, and specified an error reporting mechanism that was actually helpful for developers, then it would *still* take 2x the Javascript to call any endpoint other than one of your own because of the need to manipulate the SDP and the need to implement a state machine in Javascript while the browser is also keeping a bunch of state internally.

 

I encourage anyone who cares about interoperability to replicate our experiment... build an application using the Chrome beta that calls a gateway speaking SIP for signaling and ICE-lite for consent verification and see how "easy" it is or isn't.

 

Matthew Kaufman


--------------020704050602070205060608-- From matthew@matthew.at Sat Oct 20 10:23:21 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A38321F8789 for ; Sat, 20 Oct 2012 10:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8Jnzfo+qPof for ; Sat, 20 Oct 2012 10:23:20 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE6A21F88CC for ; Sat, 20 Oct 2012 10:23:20 -0700 (PDT) Received: from [10.10.155.229] (unknown [10.10.155.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 53826148096 for ; Sat, 20 Oct 2012 10:23:20 -0700 (PDT) Message-ID: <5082DE08.5040007@matthew.at> Date: Sat, 20 Oct 2012 10:23:20 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary="------------020306080000080309040306" Subject: [rtcweb] (resend) RE: Draft agenda for RTCWeb session 2 at IETF85 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Oct 2012 17:23:21 -0000 This is a multi-part message in MIME format. --------------020306080000080309040306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Can we just save a bunch of time and have a show of hands at the beginning for: A) People who WILL NOT implement H.264 in their product and cannot be swayed by any presentation B) People who WILL NOT implement VP8 in their product and cannot be swayed by any presentation C) People who are still undecided enough that they want to hear the presentations It is quite possible that once we get that out of the way, the rest of the presentations will be irrelevant and we can get back to discussing important things like who is going to write down the particulars for the "SDP profile" we're using as an API surface. Matthew Kaufman ________________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Cullen Jennings (fluffy) [fluffy@cisco.com] Sent: Friday, October 19, 2012 11:59 AM To: rtcweb@ietf.org Subject: [rtcweb] Draft agenda for RTCWeb session 2 at IETF85 We have two WebRTC session at the next IETF. We have not worked out the agenda for the first session yet but our current plan is to dedicate the second session to the MTI video codec question. The draft agenda for this season is: Admin issues (5 min) IPR at the IETF ( 10 min ) - this is a reminder of IETF rules and guidelines around IPR Presentations ( 80 min ) - a 20 minute presentation from each of the following drafts draft-alvestrand-rtcweb-vp8-00 draft-burman-rtcweb-h264-proposal-00 draft-dbenham-webrtc-videomti-00 draft-marjou-rtcweb-video-codec-00 - If the authors of drafts recommending the same codec can consult with each other to avoid overlap, or even merge presentations, the recovered time would be given to the general discussion. General discussion (30 min ) - general time for everyone to speak at the mic to express information important for the decision Call the question of which mandatory to implement video codec to select( 5 min ) Next steps ( 20 min ) Cullen, Magnus, and Ted _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --------------020306080000080309040306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Can we just save a bunch of time and have a show of hands at the beginning for:

A) People who WILL NOT implement H.264 in their product and cannot be swayed by any presentation

B) People who WILL NOT implement VP8 in their product and cannot be swayed by any presentation

C) People who are still undecided enough that they want to hear the presentations

 

It is quite possible that once we get that out of the way, the rest of the presentations will be irrelevant and we can get back to discussing important things like who is going to write down the particulars for the "SDP profile" we're using as an API surface.

 

Matthew Kaufman

 

________________________________________

From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Cullen Jennings (fluffy) [fluffy@cisco.com]

Sent: Friday, October 19, 2012 11:59 AM

To: rtcweb@ietf.org

Subject: [rtcweb] Draft agenda for RTCWeb session 2 at IETF85

 

We have two WebRTC session at the next IETF. We have not worked out the agenda for the first session yet but our current plan is to dedicate the second session to the MTI video codec question.

 

The draft agenda for this season is:

 

Admin issues (5 min)

 

IPR at the IETF ( 10 min )

- this is a reminder of IETF rules and guidelines around IPR

 

Presentations ( 80 min )

- a 20 minute presentation from each of the following drafts

     draft-alvestrand-rtcweb-vp8-00

     draft-burman-rtcweb-h264-proposal-00

     draft-dbenham-webrtc-videomti-00

     draft-marjou-rtcweb-video-codec-00

- If the authors of drafts recommending the same codec can consult with each other to avoid overlap, or even merge presentations, the recovered time would be given to the general discussion.

 

 

General discussion (  30 min )

- general time for everyone to speak at the mic to express information important for the decision

 

 

Call the question of which mandatory to implement video codec to select  ( 5 min )

 

 

Next steps ( 20 min )

 

 

Cullen, Magnus, and Ted <RTCWeb Chairs>

 

 

 

 

_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

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

 

--------------020306080000080309040306-- From matthew@matthew.at Sat Oct 20 10:24:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6B921F8858 for ; Sat, 20 Oct 2012 10:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.057 X-Spam-Level: X-Spam-Status: No, score=-1.057 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xo0Ft13A3EPm for ; Sat, 20 Oct 2012 10:24:49 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B7621F8840 for ; Sat, 20 Oct 2012 10:24:49 -0700 (PDT) Received: from [10.10.155.229] (unknown [10.10.155.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id ABDBD148096 for ; Sat, 20 Oct 2012 10:24:49 -0700 (PDT) Message-ID: <5082DE61.8020706@matthew.at> Date: Sat, 20 Oct 2012 10:24:49 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary="------------070401010400090304000505" Subject: [rtcweb] (resend) RE: Fwd: New Version Notification for draft-alvestrand-rtcweb-vp8-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Oct 2012 17:24:50 -0000 This is a multi-part message in MIME format. --------------070401010400090304000505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [Note: Harald's reply to this message which quoted part of it did make it to the list, but my original did not] I see nothing in this draft which has changed the landscape as it existed when these blog postings were made: http://blogs.msdn.com/b/ie/archive/2010/05/03/follow-up-on-html5-video-in-ie9.aspx http://blogs.windows.com/windows/b/bloggingwindows/archive/2010/05/19/another-follow-up-on-html5-video-in-ie9.aspx I think that we should only seriously consider MTI codecs which have been developed and improved within the context of an existing standards body, for the multitude of technical and non-technical benefits that process provides for those who ship the codecs in their products. I will note, for instance, that the Opus audio codec is a substantially better general-purpose Internet codec than SILK as a result of following this process. Matthew Kaufman --------------070401010400090304000505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

[Note: Harald's reply to this message which quoted part of it did make it to the list, but my original did not]


I see nothing in this draft which has changed the landscape as it existed when these blog postings were made:

http://blogs.msdn.com/b/ie/archive/2010/05/03/follow-up-on-html5-video-in-ie9.aspx

 

http://blogs.windows.com/windows/b/bloggingwindows/archive/2010/05/19/another-follow-up-on-html5-video-in-ie9.aspx

 

I think that we should only seriously consider MTI codecs which have been developed and improved within the context of an existing standards body, for the multitude of technical and non-technical benefits that process provides for those who ship the codecs in their products.

 

I will note, for instance, that the Opus audio codec is a substantially better general-purpose Internet codec than SILK as a result of following this process.

 

Matthew Kaufman

--------------070401010400090304000505-- From matthew@matthew.at Sat Oct 20 10:26:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF0D21F8840 for ; Sat, 20 Oct 2012 10:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItSAZK5cM0Zi for ; Sat, 20 Oct 2012 10:26:06 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id E598021F8837 for ; Sat, 20 Oct 2012 10:26:05 -0700 (PDT) Received: from [10.10.155.229] (unknown [10.10.155.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id DA5AE148096 for ; Sat, 20 Oct 2012 10:26:05 -0700 (PDT) Message-ID: <5082DEAD.9030206@matthew.at> Date: Sat, 20 Oct 2012 10:26:05 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary="------------070503060208060506010102" Subject: [rtcweb] (resend) RE: Fwd: New Version Notification for draft-alvestrand-rtcweb-vp8-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Oct 2012 17:26:06 -0000 This is a multi-part message in MIME format. --------------070503060208060506010102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Harald Alvestrand [harald@alvestrand.no]*:* >At the moment, if we want open, good and developed in cooperation with a standards body, it seems that we only get 2 out of 3. At most. For video, H.264 is available in open source implementations and the specification is available to read by all, the quality is more than good enough, and it was developed in cooperation with a recognized standards body. I think you're looking for a word other than "open" to explain what you might not like about it... but the alternative you've proposed meets even fewer of these, and I would claim that the last is more important than the missing one you're thinking of. Matthew Kaufman --------------070503060208060506010102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Harald Alvestrand [harald@alvestrand.no]:

>At the moment, if we want open, good and developed in cooperation with a standards body, it seems that we only get 2 out of 3. At most.

 

For video, H.264 is available in open source implementations and the specification is available to read by all, the quality is more than good enough, and it was developed in cooperation with a recognized standards body.

 

I think you're looking for a word other than "open" to explain what you might not like about it... but the alternative you've proposed meets even fewer of these, and I would claim that the last is more important than the missing one you're thinking of.

 

Matthew Kaufman

--------------070503060208060506010102-- From harald@alvestrand.no Sat Oct 20 15:30:26 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB9221F869A for ; Sat, 20 Oct 2012 15:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.418 X-Spam-Level: X-Spam-Status: No, score=-110.418 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oi9qbZ4tmLDT for ; Sat, 20 Oct 2012 15:30:25 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0343521F86E5 for ; Sat, 20 Oct 2012 15:30:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6971239E149 for ; Sun, 21 Oct 2012 00:30:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wph5b6DIUcHP for ; Sun, 21 Oct 2012 00:30:20 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 15E3939E03A for ; Sun, 21 Oct 2012 00:30:20 +0200 (CEST) Message-ID: <508325F9.8010107@alvestrand.no> Date: Sun, 21 Oct 2012 00:30:17 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5082DDAF.7080102@matthew.at> In-Reply-To: <5082DDAF.7080102@matthew.at> Content-Type: multipart/alternative; boundary="------------040607010000040105070206" Subject: [rtcweb] SDP testing (Re: (resend) RE: Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting)) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Oct 2012 22:30:26 -0000 This is a multi-part message in MIME format. --------------040607010000040105070206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit (Chrome developer hat on) Thanks for the info - can you point to the bugs you filed on these issues with our implementation? I'll try to see that they're followed up. It would be helpful if you specified which endpoint you interoperated with, but the most important thing is to show what the SDP was and where it was wrong for interoperability. Frankly, the code in Chrome is a completely new SDP parser/generator, and definitely needs testing. Harald On 10/20/2012 07:21 PM, Matthew Kaufman wrote: > (Resending from my personal account as the list server dropped a bunch > of messages and I will be resending from my personal account a few > that I think are still particularly relevant) > > Harald Alvestrand [harald@alvestrand.no]: > > > > > > Because making an interface that makes following an existing practice > > > easy (but does not enforce all the constraints of that practice) is > > > better than making an interface that makes following that practice > > > very complex? > > If this myth were correct, it would be a good argument. In practice, > the JSEP interface (which claims to loosely follow an existing > practice) is *more difficult* to use when interoperating with > endpoints that actually follow that practice than the API we proposed > does. > > In our testing, the amount of Javascript required to unpack the pile > of SDP that is emitted by an existing implementation of JSEP (the > Google Chrome beta), pick it apart into what you actually need to > interop with a real gateway endpoint, exhaustively test what SDP can > then be put back in to setLocalDescription and setRemoteDescription > (as there is no specification saying what SDP is and is not allowed > here, and no error reporting to speak of), and then the signaling on > top of that all adds up to more than twice as much Javascript as it > takes to use our proposed direct-manipulation API, create SDP that is > compatible with the far end you are interoperating with, and start > media flowing. > > If the existing API actually had a description of what SDP is and is > not acceptable, and specified an error reporting mechanism that was > actually helpful for developers, then it would *still* take 2x the > Javascript to call any endpoint other than one of your own because of > the need to manipulate the SDP and the need to implement a state > machine in Javascript while the browser is also keeping a bunch of > state internally. > > I encourage anyone who cares about interoperability to replicate our > experiment... build an application using the Chrome beta that calls a > gateway speaking SIP for signaling and ICE-lite for consent > verification and see how "easy" it is or isn't. > > Matthew Kaufman > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------040607010000040105070206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
(Chrome developer hat on)
Thanks for the info - can you point to the bugs you filed on these issues with our implementation? I'll try to see that they're followed up.

It would be helpful if you specified which endpoint you interoperated with, but the most important thing is to show what the SDP was and where it was wrong for interoperability.

Frankly, the code in Chrome is a completely new SDP parser/generator, and definitely needs testing.

          Harald

On 10/20/2012 07:21 PM, Matthew Kaufman wrote:
(Resending from my personal account as the list server dropped a bunch of messages and I will be resending from my personal account a few that I think are still particularly relevant)

Harald Alvestrand [harald@alvestrand.no]:

> 

> Because making an interface that makes following an existing practice

> easy (but does not enforce all the constraints of that practice) is

> better than making an interface that makes following that practice

> very complex?

 

If this myth were correct, it would be a good argument. In practice, the JSEP interface (which claims to loosely follow an existing practice) is *more difficult* to use when interoperating with endpoints that actually follow that practice than the API we proposed does.

 

In our testing, the amount of Javascript required to unpack the pile of SDP that is emitted by an existing implementation of JSEP (the Google Chrome beta), pick it apart into what you actually need to interop with a real gateway endpoint, exhaustively test what SDP can then be put back in to setLocalDescription and setRemoteDescription (as there is no specification saying what SDP is and is not allowed here, and no error reporting to speak of), and then the signaling on top of that all adds up to more than twice as much Javascript as it takes to use our proposed direct-manipulation API, create SDP that is compatible with the far end you are interoperating with, and start media flowing.

 

If the existing API actually had a description of what SDP is and is not acceptable, and specified an error reporting mechanism that was actually helpful for developers, then it would *still* take 2x the Javascript to call any endpoint other than one of your own because of the need to manipulate the SDP and the need to implement a state machine in Javascript while the browser is also keeping a bunch of state internally.

 

I encourage anyone who cares about interoperability to replicate our experiment... build an application using the Chrome beta that calls a gateway speaking SIP for signaling and ICE-lite for consent verification and see how "easy" it is or isn't.

 

Matthew Kaufman




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

--------------040607010000040105070206-- From bernard_aboba@hotmail.com Sat Oct 20 16:20:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F36D21F8880 for ; Sat, 20 Oct 2012 16:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.174 X-Spam-Level: X-Spam-Status: No, score=-102.174 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ml7bcjtxKebd for ; Sat, 20 Oct 2012 16:20:09 -0700 (PDT) Received: from blu0-omc1-s17.blu0.hotmail.com (blu0-omc1-s17.blu0.hotmail.com [65.55.116.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4EF21F879E for ; Sat, 20 Oct 2012 16:20:09 -0700 (PDT) Received: from BLU002-W136 ([65.55.116.9]) by blu0-omc1-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 20 Oct 2012 16:20:07 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_5c37d7da-8c82-493e-b61d-d57d62e81b8c_" X-Originating-IP: [72.11.69.66] From: Bernard Aboba To: Harald Alvestrand , "rtcweb@ietf.org" Date: Sat, 20 Oct 2012 16:20:07 -0700 Importance: Normal In-Reply-To: <508325F9.8010107@alvestrand.no> References: <5082DDAF.7080102@matthew.at>,<508325F9.8010107@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 20 Oct 2012 23:20:07.0437 (UTC) FILETIME=[7159DBD0:01CDAF19] Subject: Re: [rtcweb] SDP testing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Oct 2012 23:20:10 -0000 --_5c37d7da-8c82-493e-b61d-d57d62e81b8c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Harald said: "Thanks for the info - can you point to the bugs you filed on these=0A= issues with our implementation? I'll try to see that they're=0A= followed up." =0A= =20 [BA] To determine whether something is a "bug" or a "feature" it helps to h= ave a specification that states what is expected. Since we're primarily ta= lking about SDP usage within the API rather than what travels over the wire= (after all=2C signaling is out of scope in WebRTC)=2C http://tools.ietf.or= g/html/draft-nandakumar-rtcweb-sdp is only a baby step toward determining w= hether the SDP output by createOffer is conformant or whether input to setL= ocalDescription or setRemoteDescription should be acceptable or not=2C and = if not=2C what should happen.=20 For example=2C posting the SDP that is emitted by various createOffer() im= plementations might enhance the appreciation of the importance of the issue= =2C I am not sure how to evaluate the results without understanding whether= that output is expected to be valid SDP or not. For example=2C if trickle= ICE is used=2C then perhaps one should not expect createOffer to provide S= DP with valid addresses and ports filled in=3B instead that information is = expected to be filled in later. = --_5c37d7da-8c82-493e-b61d-d57d62e81b8c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Harald said:

"Thanks for the info - can you point to the bugs you= filed on these=0A= issues with our implementation? I'll try to see that they're=0A= followed up."
=0A=
[BA] To determine whether something is a "bug" or a "feature" it = helps to have a specification that states what is expected.  =3BSince w= e're primarily talking about SDP usage within the API rather than what trav= els over the wire (after all=2C signaling is out of scope in WebRTC)=2C&nbs= p=3Bhttp://tools.ietf.org/html/draft-nandakumar-rtcwe= b-sdp =3Bis only a baby step toward determining whether the SDP out= put by createOffer is conformant or whether input to setLocalDescription or= setRemoteDescription should be acceptable or not=2C and if not=2C what sho= uld happen. =3B

=
For example=2C  =3Bposting the SDP th= at is emitted by various createOffer() implementations might enhance the ap= preciation of the importance of the issue=2C I am not sure how to evaluate = the results without understanding whether that output is expected to be val= id SDP or not.  =3BFor example=2C if trickle ICE is used=2C then perhap= s one should not expect createOffer to provide SDP with valid addresses and= ports filled in=3B instead that information is expected to be filled in la= ter. =3B
= --_5c37d7da-8c82-493e-b61d-d57d62e81b8c_-- From matthew@matthew.at Sat Oct 20 22:12:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C38721F8965 for ; Sat, 20 Oct 2012 22:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pahzFcDGnWND for ; Sat, 20 Oct 2012 22:12:27 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5471421F8963 for ; Sat, 20 Oct 2012 22:12:27 -0700 (PDT) Received: from [10.10.155.229] (unknown [10.10.155.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id D3366148089 for ; Sat, 20 Oct 2012 22:12:24 -0700 (PDT) Message-ID: <50838436.6080203@matthew.at> Date: Sat, 20 Oct 2012 22:12:22 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5082DDAF.7080102@matthew.at>, <508325F9.8010107@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050305070105010405000708" Subject: Re: [rtcweb] SDP testing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Oct 2012 05:12:28 -0000 This is a multi-part message in MIME format. --------------050305070105010405000708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/20/2012 4:20 PM, Bernard Aboba wrote: > Harald said: > > "Thanks for the info - can you point to the bugs you filed on these > issues with our implementation? I'll try to see that they're followed up." > > [BA] To determine whether something is a "bug" or a "feature" it helps > to have a specification that states what is expected. Since we're > primarily talking about SDP usage within the API rather than what > travels over the wire (after all, signaling is out of scope in > WebRTC), http://tools.ietf.org/html/draft-nandakumar-rtcweb-sdp is > only a baby step toward determining whether the SDP output by > createOffer is conformant or whether input to setLocalDescription or > setRemoteDescription should be acceptable or not, and if not, what > should happen. > Precisely the problem. It isn't a "bug" with the Google Chrome beta. It is a "bug" with the current specification, which says "see SDP O/A RFC" rather than "this is what a browser must allow" or even "this is the type of error a browser must throw if the rules aren't followed". I'll pick some choice examples from some SDP that the latest Chrome beta just gave me from createOffer (without pasting the entire blob it disgorges): s=- Can I add "e=matthew@matthew.at" right after this? How about a "p=" line? a=group:BUNDLE audio video Can I remove this before passing it back to setLocal Description? a=ice-options:google-ice How about removing this? Or changing it to "a=ice-options:matthew-special-ice"? a=sendrecv Can I change it to sendonly? a=rtcp-mux Remove this? a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:66AIWBQ/R+UnMc4N/NP/b2hjEB6ydFMMCc8n3DMp Remove this? Change the key? Set up DTLS-SRTP instead? a=rtpmap:103 ISAC/16000 Change this to rtpmap: 110 ISAC/16000 because I prefer 110 as the codec ID? a=ssrc:1018881792 cname:B0VSPpORV75cCTIv Delete this? Change the ssrc ID because I don't like this one? or the cname? m=video 1 RTP/SAVPF 100 101 102 c=IN IP4 0.0.0.0 Change this to RTP/SAVP ? [Never mind that "IN IP4 0.0.0.0" is a strange thing to have coming from "createOffer"] NOWHERE in the JSEP specification can I find the answers to these questions. That makes working out what is allowed a browser-by-browser exhaustive search, which is unacceptable. Matthew Kaufman --------------050305070105010405000708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/20/2012 4:20 PM, Bernard Aboba wrote:
Harald said:

"Thanks for the info - can you point to the bugs you filed on these issues with our implementation? I'll try to see that they're followed up."

[BA] To determine whether something is a "bug" or a "feature" it helps to have a specification that states what is expected.  Since we're primarily talking about SDP usage within the API rather than what travels over the wire (after all, signaling is out of scope in WebRTC), http://tools.ietf.org/html/draft-nandakumar-rtcweb-sdp is only a baby step toward determining whether the SDP output by createOffer is conformant or whether input to setLocalDescription or setRemoteDescription should be acceptable or not, and if not, what should happen. 


Precisely the problem. It isn't a "bug" with the Google Chrome beta. It is a "bug" with the current specification, which says "see SDP O/A RFC" rather than "this is what a browser must allow" or even "this is the type of error a browser must throw if the rules aren't followed".

I'll pick some choice examples from some SDP that the latest Chrome beta just gave me from createOffer (without pasting the entire blob it disgorges):


s=- 

Can I add "e=matthew@matthew.at" right after this?

How about a "p=" line?

a=group:BUNDLE audio video

Can I remove this before passing it back to setLocal Description?

a=ice-options:google-ice

How about removing this? Or changing it to "a=ice-options:matthew-special-ice"?

a=sendrecv

Can I change it to sendonly?

a=rtcp-mux

Remove this?

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:66AIWBQ/R+UnMc4N/NP/b2hjEB6ydFMMCc8n3DMp

Remove this? Change the key? Set up DTLS-SRTP instead?

a=rtpmap:103 ISAC/16000

Change this to rtpmap: 110 ISAC/16000 because I prefer 110 as the codec ID?

a=ssrc:1018881792 cname:B0VSPpORV75cCTIv

Delete this? Change the ssrc ID because I don't like this one? or the cname?

m=video 1 RTP/SAVPF 100 101 102 c=IN IP4 0.0.0.0

Change this to RTP/SAVP ? [Never mind that "IN IP4 0.0.0.0" is a strange thing to have coming from "createOffer"]

NOWHERE in the JSEP specification can I find the answers to these questions. That makes working out what is allowed a browser-by-browser exhaustive search, which is unacceptable.

Matthew Kaufman
 --------------050305070105010405000708-- From harald@alvestrand.no Sat Oct 20 23:51:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC04C21F88D8 for ; Sat, 20 Oct 2012 23:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.435 X-Spam-Level: X-Spam-Status: No, score=-110.435 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SehcPqe7BMqg for ; Sat, 20 Oct 2012 23:51:22 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5BD21F88BD for ; Sat, 20 Oct 2012 23:51:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 50C0F39E13F; Sun, 21 Oct 2012 08:51:19 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iubJ9z9nqTxW; Sun, 21 Oct 2012 08:51:18 +0200 (CEST) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1F52439E056; Sun, 21 Oct 2012 08:51:18 +0200 (CEST) Message-ID: <50839B63.5090607@alvestrand.no> Date: Sun, 21 Oct 2012 08:51:15 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Bernard Aboba References: <5082DDAF.7080102@matthew.at>, <508325F9.8010107@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010505070800020706020604" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP testing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Oct 2012 06:51:23 -0000 This is a multi-part message in MIME format. --------------010505070800020706020604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/21/2012 01:20 AM, Bernard Aboba wrote: > Harald said: > > "Thanks for the info - can you point to the bugs you filed on these > issues with our implementation? I'll try to see that they're followed up." > > [BA] To determine whether something is a "bug" or a "feature" it helps > to have a specification that states what is expected. Since we're > primarily talking about SDP usage within the API rather than what > travels over the wire (after all, signaling is out of scope in > WebRTC), http://tools.ietf.org/html/draft-nandakumar-rtcweb-sdp is > only a baby step toward determining whether the SDP output by > createOffer is conformant or whether input to setLocalDescription or > setRemoteDescription should be acceptable or not, and if not, what > should happen. > > For example, posting the SDP that is emitted by various createOffer() > implementations might enhance the appreciation of the importance of > the issue, I am not sure how to evaluate the results without > understanding whether that output is expected to be valid SDP or not. > For example, if trickle ICE is used, then perhaps one should not > expect createOffer to provide SDP with valid addresses and ports > filled in; instead that information is expected to be filled in later. Actually all of the issues I've seen in real testing so far have fallen into two broad cateories: - Issues where the endpoints are known to be noninteroperable - for instance by requiring ICE, requiring SRTP, or using different video codecs. No amount of SDP munging will fix those. - Issues where the Google implementors have failed to understand some subtlety of SDP syntax, encountered an SDP extension that we didn't expect to see, or didn't get around to handling that part of the syntax yet - for instance when we were sending "s=" instead of "s= ". When we started out, I expected a host of issues of the type you envision - where people who are reading the SDP specs have serious differences of opinion about what should be the right outcome - but so far, I haven't seen that happening. Perhaps we haven't gotten to the hard parts yet, or perhaps the SDP specification, when used for the basic stuff that we're so far doing, is less troublesome than we thought? That's why I keep on pushing for bugs to be filed - I believe we can identify problem areas more easily by saying "when X tries to negotiate a connection with Y, A happens, but B should happen instead". Also, I learn much more from those discussions than a discussion phrased in general terms! Harald --------------010505070800020706020604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/21/2012 01:20 AM, Bernard Aboba wrote:
Harald said:

"Thanks for the info - can you point to the bugs you filed on these issues with our implementation? I'll try to see that they're followed up."

[BA] To determine whether something is a "bug" or a "feature" it helps to have a specification that states what is expected.  Since we're primarily talking about SDP usage within the API rather than what travels over the wire (after all, signaling is out of scope in WebRTC), http://tools.ietf.org/html/draft-nandakumar-rtcweb-sdp is only a baby step toward determining whether the SDP output by createOffer is conformant or whether input to setLocalDescription or setRemoteDescription should be acceptable or not, and if not, what should happen. 

For example,  posting the SDP that is emitted by various createOffer() implementations might enhance the appreciation of the importance of the issue, I am not sure how to evaluate the results without understanding whether that output is expected to be valid SDP or not.  For example, if trickle ICE is used, then perhaps one should not expect createOffer to provide SDP with valid addresses and ports filled in; instead that information is expected to be filled in later.
Actually all of the issues I've seen in real testing so far have fallen into two broad cateories:

- Issues where the endpoints are known to be noninteroperable - for instance by requiring ICE, requiring SRTP, or using different video codecs. No amount of SDP munging will fix those.
- Issues where the Google implementors have failed to understand some subtlety of SDP syntax, encountered an SDP extension that we didn't expect to see, or didn't get around to handling that part of the syntax yet - for instance when we were sending "s=" instead of "s= ".

When we started out, I expected a host of issues of the type you envision - where people who are reading the SDP specs have serious differences of opinion about what should be the right outcome - but so far, I haven't seen that happening.

Perhaps we haven't gotten to the hard parts yet, or perhaps the SDP specification, when used for the basic stuff that we're so far doing, is less troublesome than we thought?

That's why I keep on pushing for bugs to be filed - I believe we can identify problem areas more easily by saying "when X tries to negotiate a connection with Y, A happens, but B should happen instead".
Also, I learn much more from those discussions than a discussion phrased in general terms!

                Harald



--------------010505070800020706020604-- From stefan.lk.hakansson@ericsson.com Sun Oct 21 07:44:19 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1192221F8433 for ; Sun, 21 Oct 2012 07:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXfZYdS+RiI4 for ; Sun, 21 Oct 2012 07:44:18 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id C058A21F8445 for ; Sun, 21 Oct 2012 07:44:17 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-6e-50840a3e3245 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id FC.F6.17130.E3A04805; Sun, 21 Oct 2012 16:44:15 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Sun, 21 Oct 2012 16:44:13 +0200 Message-ID: <50840A3D.7060500@ericsson.com> Date: Sun, 21 Oct 2012 16:44:13 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5082DE08.5040007@matthew.at> In-Reply-To: <5082DE08.5040007@matthew.at> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvra49V0uAwduJnBZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY9O9bYwFn8Uqzp27wtrAuFKoi5GTQ0LAROLV3cVMELaYxIV7 69m6GLk4hAROMUpM6mhlhnCWM0rcWreKEaSKV0Bb4ur2j0AdHBwsAqoSj3uVQcJsAjYSa7un gA0SFQiTWL5zMxNEuaDEyZlPWEBsEQFhia2vesHiwgJ+EvtPLmMGsYUENCW2vrnADmJzCmhJ LPjXDlbDLGArcWHOdRYIW15i+9s5UPW6Eu9e32OdwCgwC8mKWUhaZiFpWcDIvIpRODcxMye9 3FwvtSgzubg4P0+vOHUTIzD8Dm75bbCDcdN9sUOM0hwsSuK8eqr7/YUE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUwWh7+nHjZw79tReoDkUcXkjPXP2R32XqqIGYmR9eymfG6asZmoVo1s74L uYrnvGdZmLhmbmK7wtve3LK5n14/yg66FOHVXlXu0lfxIu/O27cexlFPn9RcsToi8GH9tu5D Wx5+cn8dt6RSLn2K+2VL+6UXVhWazz5fI+T4NLl8zVHNqtQ1jGlLlFiKMxINtZiLihMBSsSC Sw0CAAA= Subject: Re: [rtcweb] (resend) RE: Draft agenda for RTCWeb session 2 at IETF85 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Oct 2012 14:44:19 -0000 On 10/20/2012 07:23 PM, Matthew Kaufman wrote: > Can we just save a bunch of time and have a show of hands at the > beginning for: > > A) People who WILL NOT implement H.264 in their product and cannot be > swayed by any presentation > > B) People who WILL NOT implement VP8 in their product and cannot be > swayed by any presentation > > C) People who are still undecided enough that they want to hear the > presentations I think something like this makes sense. We could alternative do a show of hand for preference of either alternative, if it seems we're far away from any (rough) consensus then we could move on to discuss if we should abandon an MTI video codec, or select an alternative decision process. And hopefully save a lot of time for SDP discussion. > > It is quite possible that once we get that out of the way, the rest of > the presentations will be irrelevant and we can get back to discussing > important things like who is going to write down the particulars for the > "SDP profile" we're using as an API surface. > > Matthew Kaufman > > ________________________________________ > > From: rtcweb-bounces@ietf.org > [rtcweb-bounces@ietf.org] on behalf of Cullen Jennings (fluffy) > [fluffy@cisco.com] > > Sent: Friday, October 19, 2012 11:59 AM > > To: rtcweb@ietf.org > > Subject: [rtcweb] Draft agenda for RTCWeb session 2 at IETF85 > > We have two WebRTC session at the next IETF. We have not worked out the > agenda for the first session yet but our current plan is to dedicate the > second session to the MTI video codec question. > > The draft agenda for this season is: > > Admin issues (5 min) > > IPR at the IETF ( 10 min ) > > - this is a reminder of IETF rules and guidelines around IPR > > Presentations ( 80 min ) > > - a 20 minute presentation from each of the following drafts > > draft-alvestrand-rtcweb-vp8-00 > > draft-burman-rtcweb-h264-proposal-00 > > draft-dbenham-webrtc-videomti-00 > > draft-marjou-rtcweb-video-codec-00 > > - If the authors of drafts recommending the same codec can consult with > each other to avoid overlap, or even merge presentations, the recovered > time would be given to the general discussion. > > General discussion (30 min ) > > - general time for everyone to speak at the mic to express information > important for the decision > > Call the question of which mandatory to implement video codec to select( > 5 min ) > > Next steps ( 20 min ) > > Cullen, Magnus, and Ted > > _______________________________________________ > > 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 bernard_aboba@hotmail.com Sun Oct 21 08:10:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300A821F889B for ; Sun, 21 Oct 2012 08:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.116 X-Spam-Level: X-Spam-Status: No, score=-102.116 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQJbF12+p-cI for ; Sun, 21 Oct 2012 08:10:22 -0700 (PDT) Received: from blu0-omc1-s6.blu0.hotmail.com (blu0-omc1-s6.blu0.hotmail.com [65.55.116.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7E121F8894 for ; Sun, 21 Oct 2012 08:10:22 -0700 (PDT) Received: from BLU002-W125 ([65.55.116.7]) by blu0-omc1-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 21 Oct 2012 08:10:22 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_310b2119-0692-45a8-b133-06d8fe2963a1_" X-Originating-IP: [24.16.96.166] From: Bernard Aboba To: Harald Alvestrand Date: Sun, 21 Oct 2012 08:10:21 -0700 Importance: Normal In-Reply-To: <50839B63.5090607@alvestrand.no> References: <5082DDAF.7080102@matthew.at>,<508325F9.8010107@alvestrand.no> , <50839B63.5090607@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 21 Oct 2012 15:10:22.0105 (UTC) FILETIME=[30BDC890:01CDAF9E] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP testing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Oct 2012 15:10:23 -0000 --_310b2119-0692-45a8-b133-06d8fe2963a1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Harald said:=20 "When we started out=2C I expected a host of issues of the type you=0A= envision - where people who are reading the SDP specs have serious=0A= differences of opinion about what should be the right outcome - but=0A= so far=2C I haven't seen that happening." [BA] Defining what SDP specs are relevant is not difficult. draft-nandakum= ar-rtcweb-sdp enumerates the relevant specifications to a good degree of ac= curacy (I agree with 90+ percent of what is in the draft). If all we had = to do was quibble about which SDP references are MUST/SHOULD/MAY within tha= t document=2C then with sufficient WG attention=2C the probability of conve= rgence would be high. However=2C this would not cover: * Expectations for SDP parser resilience. Experience indicates that this w= as not sufficiently well described in RFC 3264 and 4566. For example=2C my= understanding is that Chrome stops parsing in some cases when it hits SDP = it does not understand. While this approach is quite common in SDP impleme= ntations (and may not violate 3264/4566 so as to be classifiable as a "bug"= )=2C expectations for resilience could be better defined. =20 * Error handling. What happens when the parser detects an error and how do= we know what it objected to? Is an exception or error callback fired? Do= es this provide an indication of what SDP lines caused the error? Is there = a way to retrieve the SDP that the browser decided to act upon (which may b= e different from what was input)?=20 * Guidance with respect to API usage=2C both general and specific=2C such a= s the questions Mathew mentioned.=20 Overall=2C these questions relate more to the API than to existing or in-pr= ogress SDP specifications within IETF=2C which raises the question of where= they would be best addressed.=20 = --_310b2119-0692-45a8-b133-06d8fe2963a1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Harald said:

"When we st= arted out=2C I expected a host of issues of the type you=0A= envision - where people who are reading the SDP specs have serious=0A= differences of opinion about what should be the right outcome - but=0A= so far=2C I haven't seen that happening."

[BA] Defining what SDP= specs are relevant is not difficult. =3B draft-nandakumar-rtcweb-sdp e= numerates the relevant specifications to a good degree of accuracy (I agree= with 90+ percent of what is in the draft). =3B =3B If all we had t= o do was quibble about which SDP references are MUST/SHOULD/MAY within that= document=2C then with sufficient WG attention=2C the probability of conver= gence would be high. =3B However=2C this would not cover:

* Expe= ctations for SDP parser resilience. =3B Experience indicates that this = was not sufficiently well described in RFC 3264 and 4566. =3B For examp= le=2C my understanding is that Chrome stops parsing in some cases when it h= its SDP it does not understand. =3B While this approach is quite common= in SDP implementations (and may not violate 3264/4566 so as to be classifi= able as a "bug")=2C expectations for resilience could be better defined.&nb= sp=3B
* Error handling. =3B What happens when the parser detects an= error and how do we know what it objected to? =3B Is an exception or e= rror callback fired? =3B Does this provide an indication of what SDP li= nes caused the error? Is there a way to retrieve the SDP that the browser d= ecided to act upon (which may be different from what was input)?
* Guid= ance with respect to API usage=2C both general and specific=2C such as the = questions Mathew mentioned.

Overall=2C these questions relate more = to the API than to existing or in-progress SDP specifications within IETF= =2C which raises the question of where they would be best addressed.
= --_310b2119-0692-45a8-b133-06d8fe2963a1_-- From ron@debian.org Sun Oct 21 12:57:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D1521F8A2F for ; Sun, 21 Oct 2012 12:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.008 X-Spam-Level: X-Spam-Status: No, score=-0.008 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_20=-0.74, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dp+01U9RhRfd for ; Sun, 21 Oct 2012 12:57:56 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id AACDD21F8908 for ; Sun, 21 Oct 2012 12:57:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJFShFB20idQ/2dsb2JhbABEwQ+BCYIgAQEFOhwhEgsYLhQYDTcbh2i6NItfhm8DjgaHagGQOYMC Received: from ppp118-210-39-80.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([118.210.39.80]) by ipmail07.adl2.internode.on.net with ESMTP; 22 Oct 2012 06:27:53 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id E5EBE4F8F3 for ; Mon, 22 Oct 2012 06:27:51 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id s-kL92KEQZw2 for ; Mon, 22 Oct 2012 06:27:50 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 36DB84F902; Mon, 22 Oct 2012 06:27:50 +1030 (CST) Date: Mon, 22 Oct 2012 06:27:50 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20121021195750.GQ6812@audi.shelbyville.oz> References: <5082DEAD.9030206@matthew.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5082DEAD.9030206@matthew.at> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] (resend) RE: Fwd: New Version Notification for draft-alvestrand-rtcweb-vp8-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Oct 2012 19:57:56 -0000 Hi Matthew, On Sat, Oct 20, 2012 at 10:26:05AM -0700, Matthew Kaufman wrote: > Harald Alvestrand [harald@alvestrand.no]*:* > > >At the moment, if we want open, good and developed in cooperation > >with a standards body, it seems that we only > get 2 out of 3. At most. > > For video, H.264 is available in open source implementations and the > specification is available to read by all, the quality is more than > good enough, and it was developed in cooperation with a recognized > standards body. > > I think you're looking for a word other than "open" to explain what > you might not like about it... but the alternative you've proposed > meets even fewer of these, and I would claim that the last is more > important than the missing one you're thinking of. I'm not sure which dictionary you're taking your definition of "open" from here, but I can't seem to find one that constrains it to just the closed sophisticated meanings that you seem to want to dilute it to. Do you have a reference or suggested alternative word that you'd like to share with us? "Requires me to apply for a licence, without which I have no rights" is pretty much the poster child for the exact opposite of open ... "Can peep through the window at what I'm missing without one" is not an acceptable or even approximate substitute by any measure. It seems pretty clear to me that Open and Good, as judged by this group, are the only two actual relevant constraints here. The third is about as arbitrary as saying "eligible codecs must have a V in their name" in its current effect on limiting the scope of our choices. Having the imprimatur of a closed shop organisation is quite irrelevant to meeting the real demands of developers and end users. Suggesting it is somehow essential seems like the sort of conceit that led people to gather around a more open organisation to look for alternative solutions in the first place. Yes, it would have been wonderful if RFC 6386 had been Standards Track instead of Informational, and if we'd had a working group to oversee that several years ago. But that doesn't make it any less of an existing technology, or any less worthy of consideration for its applicability to the goals of this group. We should judge it on technical merits, not its political endorsements. An inability to deploy something, except at the whim of a private group of stake-holders, is a pretty insurmountable technical barrier. That some other standards body might endorse or even encourage that practice probably only discounts the value of their approval to us even further. If the owners of H.264 aren't prepared to remove that barrier to at least the same extent that the owners of VP8 have, then I don't know why we are wasting our time still pretending H.264 is even an option here. If they are serious about being a viable candidate, then they know what they need to do and have had plenty of time to do it. Just redefining the word "open" isn't the solution we're looking for. Openly, Ron From ron@debian.org Sun Oct 21 14:01:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5642021F88E8 for ; Sun, 21 Oct 2012 14:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.082 X-Spam-Level: X-Spam-Status: No, score=-0.082 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_05=-1.11, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIyJvfCggNsG for ; Sun, 21 Oct 2012 14:01:50 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 8447D21F87B1 for ; Sun, 21 Oct 2012 14:01:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOthhFB20idQ/2dsb2JhbABDwQ+BCYIgAQEEATocKAsLGC4UGA2INQW6I4tfg0yDIwOOBodqAZA5gwI Received: from ppp118-210-39-80.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([118.210.39.80]) by ipmail07.adl2.internode.on.net with ESMTP; 22 Oct 2012 07:31:49 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 4C7564F8F3 for ; Mon, 22 Oct 2012 07:31:48 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jIPxSnpJo+WB for ; Mon, 22 Oct 2012 07:31:47 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id A191A4F902; Mon, 22 Oct 2012 07:31:47 +1030 (CST) Date: Mon, 22 Oct 2012 07:31:47 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20121021210147.GR6812@audi.shelbyville.oz> References: <5082DE08.5040007@matthew.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5082DE08.5040007@matthew.at> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] (resend) RE: Draft agenda for RTCWeb session 2 at IETF85 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Oct 2012 21:01:51 -0000 On Sat, Oct 20, 2012 at 10:23:20AM -0700, Matthew Kaufman wrote: > Can we just save a bunch of time and have a show of hands at the > beginning for: > > A) People who WILL NOT implement H.264 in their product and cannot > be swayed by any presentation Are there actually people saying they *will not* implement H.264? I can't say that I've seen that here. The problem being repeatedly voiced is that under its current licencing regime they simply *CANNOT* implement and/or distribute it with their products. > B) People who WILL NOT implement VP8 in their product and cannot be > swayed by any presentation That constraint does not apply to VP8, so turning this into a tug of war between the WILL NOTs and the CANNOTs, doesn't seem to really address the actual problem we have before us. > C) People who are still undecided enough that they want to hear the > presentations Unless the presentations are going to announce new perpetual RF licencing conditions for H.264, I don't really see what new facts might be presented that can change the reality of: "People invested in H.264 licences or owning its IPR prefer H.264 and the exclusivity and revenue streams it brings them." "People who don't qualify for H.264 licences will be screwed unless we pick VP8 as the baseline - and will need to either fork RTCWeb, or adopt or create an alternative to it." This isn't a coin toss between choices of equivalent merit. Framing the question as one of Wills completely ignores the salient technical point of which choice would give RTCWeb relevance to the broadest range of possible developers, adopters and users. I don't want to see discussion of people's real concerns suppressed, so I think I agree that it would be a great idea for people to begin their presentations here and now, with the aim of distilling that to some final brief summations by the time of the meeting. So far as I can see this is a technical no-brainer. But not because I have any deep set preference for one or the other, or an inability to be swayed. Simply because H.264 would be *impossible* for many users to deploy. That's very different to VP8 being undesirable to deploy by people who have a competing interest in other codecs. Reducing that to a question of WILLs is a gross oversimplification that isn't really very helpful to making a Good decision here or to showing the careful reasoning behind it. Simply, Ron From fluffy@iii.ca Sun Oct 21 16:21:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDC721F8A44 for ; Sun, 21 Oct 2012 16:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4gyXTv43-lH for ; Sun, 21 Oct 2012 16:21:54 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id CD0C321F8A42 for ; Sun, 21 Oct 2012 16:21:54 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 39FA022DD6D; Sun, 21 Oct 2012 19:21:48 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Cullen Jennings In-Reply-To: <50840A3D.7060500@ericsson.com> Date: Sun, 21 Oct 2012 17:21:46 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5082DE08.5040007@matthew.at> <50840A3D.7060500@ericsson.com> To: Stefan Hakansson LK X-Mailer: Apple Mail (2.1499) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] (resend) RE: Draft agenda for RTCWeb session 2 at IETF85 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Oct 2012 23:21:55 -0000 On Oct 21, 2012, at 8:44 AM, Stefan Hakansson LK = wrote: > On 10/20/2012 07:23 PM, Matthew Kaufman wrote: >> Can we just save a bunch of time and have a show of hands at the >> beginning for: >>=20 >> A) People who WILL NOT implement H.264 in their product and cannot be >> swayed by any presentation >>=20 >> B) People who WILL NOT implement VP8 in their product and cannot be >> swayed by any presentation >>=20 >> C) People who are still undecided enough that they want to hear the >> presentations >=20 > I think something like this makes sense. We could alternative do a = show of hand for preference of either alternative, if it seems we're far = away from any (rough) consensus then we could move on to discuss if we = should abandon an MTI video codec, or select an alternative decision = process. I'd like to point out that rough show of hands was done at a previous = meeting and it seemed like getting to agreement on a MTI video codec was = possible.=20 On the question proposed, I don't think this is the right question. The = right questions would be of the people that want present information one = way or the other, how many of them think nothing they say will change = the opinions of anyone in the room. If they feel this way, I'm sure the = presentations will be short and no one will line up at the mic to = discuss it. My best guess is that the will be people at the front of the = room, and at the mic, that feel they have something to say on the topic.=20= Keep in mind this approach was discussed at the last meeting an there = seemed to an awful lot of people that felt this was important. We have = spent an incredible amount of WG meeting time trying to get to the point = were we can make have a meeting where we try and come to consensus on = this. From fluffy@cisco.com Sun Oct 21 16:28:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5F021F8A45 for ; Sun, 21 Oct 2012 16:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.382 X-Spam-Level: X-Spam-Status: No, score=-110.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMFVJVjd0Y9I for ; Sun, 21 Oct 2012 16:28:33 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4DB21F8A44 for ; Sun, 21 Oct 2012 16:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1452; q=dns/txt; s=iport; t=1350862113; x=1352071713; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=y1bR2Eol8a8agYJzJ4fG9oUQ1EKxttSYbodRiZlBF8U=; b=URc/ry5aaWvno/4c5UDeFt6iURYlZHTRFwQWjgt6UP878AIo5AURO4hN gJJTMpMQXxWRN6Cnc2x6ngUKySux1hSO9ihl7no9btYkX52wdNLxXSVdt oyz7XbtQ6IkH3B2MQv6AfCK0PAXv/QmRM0pR18OEJ30yR2KpDVjAt2OkG 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAImDhFCtJV2a/2dsb2JhbABDrw6SA4EIgiABAQEDARIBZgULAgEIIiQyJQIEDgUIGodQAwkGmxCfBYp2aYYPYAOUHYx9gyWBa4Jvghg X-IronPort-AV: E=Sophos;i="4.80,627,1344211200"; d="scan'208";a="133892467" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 21 Oct 2012 23:28:33 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9LNSWCW019434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 21 Oct 2012 23:28:32 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Sun, 21 Oct 2012 18:28:32 -0500 From: "Cullen Jennings (fluffy)" To: Bernard Aboba Thread-Topic: [rtcweb] RTCWEB Session 2: A plea for brevity Thread-Index: AQHNr+PIqlV7VLpnaUqCoRmbYDfopg== Date: Sun, 21 Oct 2012 23:28:32 +0000 Message-ID: References: <20121020134833.GE44606@verdi> <28739B70-EC86-4C86-87BD-64A3F8C9D060@iii.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19292.004 x-tm-as-result: No--35.788700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <8298B12376368946B2BEE671D91C45BD@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [rtcweb] RTCWEB Session 2: A plea for brevity X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Oct 2012 23:28:34 -0000 On Oct 20, 2012, at 10:13 AM, Bernard Aboba wro= te: > Cullen Jennings said: >=20 > "One of the drafts says when making measurements on quality they found A = was > better than B while the another draft says B was better than A. Several > people have asked me how this could happen two different groups ended up > with opposite measurements and they want to understand more about how thi= s > could have happened and which is correct.... Let me ask you guys a questi= on, > how many people do you think will be in the microphone line up when these > two are discussed?"" >=20 > [BA] Assuming those at the mic would be asking clarifying questions, why = do > we need to wait until IETF 85 to begin that discussion? If each side we= re > to start a thread on the list, at least some of the clarifying questions > could be gotten out of the way beforehand. Who knows, the result could b= e > akin to letting a child stay up late on Saturday night to watch TV - the > little devil might be too tired to cause trouble at church on Sunday :) >=20 +1 for starting list conversation before the meeting =85 It will be a bit c= runched as many people are still working on -01 drafts till monday, then ha= ve a few days to read drafts and travel to Europe for W3C meeting then go s= traight from W3C meeting to IETF. I really hope there can be some good list= discussion ahead of time.=20 =20 From fluffy@iii.ca Sun Oct 21 16:42:09 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E126E21F88F1 for ; Sun, 21 Oct 2012 16:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ijtq4eTwUaM for ; Sun, 21 Oct 2012 16:42:09 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1A65B21F8AC7 for ; Sun, 21 Oct 2012 16:42:09 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E898722DD6D; Sun, 21 Oct 2012 19:42:01 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Cullen Jennings In-Reply-To: Date: Sun, 21 Oct 2012 17:41:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <88E820A7-103D-420D-AB7E-836EED12B548@iii.ca> References: <5082DDAF.7080102@matthew.at>, <508325F9.8010107@alvestrand.no> , <50839B63.5090607@alvestrand.no> To: Bernard Aboba X-Mailer: Apple Mail (2.1499) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP testing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Oct 2012 23:42:10 -0000 On Oct 21, 2012, at 9:10 AM, Bernard Aboba = wrote: > Harald said:=20 >=20 > "When we started out, I expected a host of issues of the type you = envision - where people who are reading the SDP specs have serious = differences of opinion about what should be the right outcome - but so = far, I haven't seen that happening." >=20 > [BA] Defining what SDP specs are relevant is not difficult. = draft-nandakumar-rtcweb-sdp enumerates the relevant specifications to a = good degree of accuracy (I agree with 90+ percent of what is in the = draft). If all we had to do was quibble about which SDP references are = MUST/SHOULD/MAY within that document, then with sufficient WG attention, = the probability of convergence would be high. However, this would not = cover: >=20 > * Expectations for SDP parser resilience. Experience indicates that = this was not sufficiently well described in RFC 3264 and 4566. For = example, my understanding is that Chrome stops parsing in some cases = when it hits SDP it does not understand. While this approach is quite = common in SDP implementations (and may not violate 3264/4566 so as to be = classifiable as a "bug"), expectations for resilience could be better = defined. =20 We could put some implementer notes in one of the drafts to try and help = cover some of the common things developers need to deal with. That would = be helpful for many things that use SDP. Having some example SDP that = included "bogus future extensions" that a parse should successfully = ignore might help people test their SDP implementations. Note that = unlike the IETF, the W3C tends to have have a conformance test suite to = deal with things like this so in some weird way, the W3C might end up = improving the interoperability of the SDP.=20 > * Error handling. What happens when the parser detects an error and = how do we know what it objected to? Is an exception or error callback = fired? Does this provide an indication of what SDP lines caused the = error? Is there a way to retrieve the SDP that the browser decided to = act upon (which may be different from what was input)?=20 I think the combination of the JSEP and WebRTC spec need to get very = clear on all the issues you raised. I'd like to see error handling a = major part of the discussion at the W3C meeting as we have not really = tacked that yet in the spec. Last time I looked, no one had replied to = Anant's proposal.=20 > * Guidance with respect to API usage, both general and specific, such = as the questions Mathew mentioned.=20 The issue of what can be changed that Mathew raised has been discussed = as an open issue and we know that we need to nail that down in the = specification. It seemed like one of the things that could be left till = a bit later in the process when we had more information about what the = use cases were and what to put. The one use case that has been raised = very clearly is people want to be able to remove a particular codec for = various reasons. I suspect that lots of people will argue to make sure = that type of change of SDP is supported. I'm not sure what use case = drive the rest but 100% agree this is a topic we need to put some time = into. Right now, it does not seem to be holding up implications which = are still trying to nail down all the basic stuff along with ICE, DTLS, = etc.=20 >=20 > Overall, these questions relate more to the API than to existing or = in-progress SDP specifications within IETF, which raises the question of = where they would be best addressed.=20 I suspect most of them are in the WebRTC spec and some of them in ietf = drafts but either way, I agree all the points you raised need to be = specified.=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From john@jlc.net Sun Oct 21 20:04:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FD821F8A93 for ; Sun, 21 Oct 2012 20:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.445 X-Spam-Level: X-Spam-Status: No, score=-106.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id af4nDVzejGCh for ; Sun, 21 Oct 2012 20:04:30 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCFC21F8908 for ; Sun, 21 Oct 2012 20:04:30 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 9583233C20; Sun, 21 Oct 2012 23:04:30 -0400 (EDT) Date: Sun, 21 Oct 2012 23:04:30 -0400 From: John Leslie To: Cullen Jennings Message-ID: <20121022030430.GC27557@verdi> References: <20121020134833.GE44606@verdi> <28739B70-EC86-4C86-87BD-64A3F8C9D060@iii.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28739B70-EC86-4C86-87BD-64A3F8C9D060@iii.ca> User-Agent: Mutt/1.4.1i Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB Session 2: A plea for brevity X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 03:04:31 -0000 Cullen Jennings wrote: > > The MTI video codec is a pretty big questions we are asking and my > observation about getting consensus is that people need to have been > given the time to make their key argument or it is very hard to get > to consensus. Some arguments are endless... :^( > I realize that some people believe, or even hope, that we will not > get to consensus on this topic "or even hope" wasn't necessary! > so it is all a waste of time but the WG has made it clear it does > want to get to have a MTI video codec. Absent agreement on _which_ video codec will be MTI, that's a dead end. > So consider the situation we are in. One of the drafts says when > making measurements on quality they found A was better than B while > the another draft says B was better than A. Welcome to research-land! > Several people have asked me how this could happen two different groups > ended up with opposite measurements and they want to understand more > about how this could have happened and which is correct. Not I... > Let me ask you guys a question, how many people do you think will be > in the microphone line up when these two are discussed? Say four (more than once apiece, of course)... > You have both seen plenty of controversial topics discussed at other > ietf meetings. What would you recommend to people making slides for > a slot like this - how many slides do you think they can reasonably > get through in a time slot like this? Depends on the slides! > What would your best guess be of how long we need to make these slots > such that the chairs don't have to cut off the mic lineup? 45 minutes. (Myself, I'd rather you cut the line at 10 minutes.) > I know you could take these as vaguely cynical rhetorical questions > but I don't mean them that way. I'm straight up asking you how much > time you think we need such that authors of the drafts can make their > key argument and people that have questions or disagreements that > they think are important for the WG to understand can make ask their > question. Zero minutes, IMHO: these questions should be on the list. Some large companies with deep pockets have every reason to prefer the H.264 licensing paragigm. Some small organizations doing open-source have every reason to prefer the AV8 paradigm. The actual decisions will be made by folks won't be in the room. Those decisions won't be driven by which codec is better: they'll be driven by what _risks_ are taken by implementing one or the other. I'd like to air a mostly-serious way-out. Both H.264 and AV8 deserve a SHOULD implement. Some implementors _will_ chicken out due to the risks, waiting to see what the market demands. Mandatory-to-Implement isn't about which codec is best _today_ -- it's about a lowest-common-denominator for years to come. We could perfectly well designate as Mandatory-to-Implement something so brain-dead that nobody could be bothered to sue for patent infringement. H.261 comes to mind -- more than 20 years old, can be implemented in 20-year-old software. Prove that you used 20-year-old software line- for-line, and no patent troll will want to let it get to court. The tussle between H.264 and AV8 deserves to play out in the marketplace, not in an IETF meeting-room. I don't believe any IETF RFC _can_ settle this issue. YMMV, of course... -- John Leslie From matthew@matthew.at Sun Oct 21 20:50:15 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CEB21F87B1 for ; Sun, 21 Oct 2012 20:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.174 X-Spam-Level: X-Spam-Status: No, score=-1.174 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiN+BgGKPWrq for ; Sun, 21 Oct 2012 20:50:14 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F8221F8634 for ; Sun, 21 Oct 2012 20:50:12 -0700 (PDT) Received: from [10.10.155.2] (unknown [10.10.155.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 2A1A6148094 for ; Sun, 21 Oct 2012 20:50:11 -0700 (PDT) Message-ID: <5084C273.4070706@matthew.at> Date: Sun, 21 Oct 2012 20:50:11 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5082DE08.5040007@matthew.at> <20121021210147.GR6812@audi.shelbyville.oz> In-Reply-To: <20121021210147.GR6812@audi.shelbyville.oz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] (resend) RE: Draft agenda for RTCWeb session 2 at IETF85 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 03:50:15 -0000 On 10/21/2012 2:01 PM, Ron wrote: > Unless the presentations are going to announce new perpetual RF > licencing conditions for H.264, I don't really see what new facts > might be presented that can change the reality of: > > "People invested in H.264 licences or owning its IPR prefer H.264 > and the exclusivity and revenue streams it brings them." > > "People who don't qualify for H.264 licences will be screwed unless > we pick VP8 as the baseline - and will need to either fork RTCWeb, > or adopt or create an alternative to it." If only it were this simple. My employer spends more on H.264 licensing than it receives in return, and it isn't about "exclusivity" or "revenue streams" ( http://blogs.msdn.com/b/ie/archive/2010/05/03/follow-up-on-html5-video-in-ie9.aspx ) John Leslie said: "The actual decisions will be made by folks [who] won't be in the room. Those decisions won't be driven by which codec is better: they'll be driven by what _risks_ are taken by implementing one or the other." And this is a much more accurate way of saying it... and why, for anyone in the room actually on the "implementation" side, there's not much point in continuing to debate the potential merits unless the landscape is *significantly* changed from its current state (for example, RF licenses for H.264 or total indemnification provided by VP8's owner.) Matthew Kaufman From matthew@matthew.at Sun Oct 21 20:59:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750C721F8A41 for ; Sun, 21 Oct 2012 20:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.206 X-Spam-Level: X-Spam-Status: No, score=-1.206 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbIy6U09AL7j for ; Sun, 21 Oct 2012 20:59:06 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1E321F8955 for ; Sun, 21 Oct 2012 20:59:06 -0700 (PDT) Received: from [10.10.155.2] (unknown [10.10.155.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 0581D148093 for ; Sun, 21 Oct 2012 20:59:06 -0700 (PDT) Message-ID: <5084C489.2050306@matthew.at> Date: Sun, 21 Oct 2012 20:59:05 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5082DDAF.7080102@matthew.at>, <508325F9.8010107@alvestrand.no> , <50839B63.5090607@alvestrand.no> <88E820A7-103D-420D-AB7E-836EED12B548@iii.ca> In-Reply-To: <88E820A7-103D-420D-AB7E-836EED12B548@iii.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] SDP testing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 03:59:06 -0000 On 10/21/2012 4:41 PM, Cullen Jennings wrote: > > The issue of what can be changed that Mathew raised has been discussed as an open issue and we know that we need to nail that down in the specification. It seemed like one of the things that could be left till a bit later in the process when we had more information about what the use cases were and what to put. The one use case that has been raised very clearly is people want to be able to remove a particular codec for various reasons. I suspect that lots of people will argue to make sure that type of change of SDP is supported. I'm not sure what use case drive the rest but 100% agree this is a topic we need to put some time into. Right now, it does not seem to be holding up implications which are still trying to nail down all the basic stuff along with ICE, DTLS, etc. > The API surface exposed in the browser must be *completely* specified. While I am glad that you "100% agree this is a topic we need to put some time into," I also know that in the years since SDP O/A was first proposed a concrete set of interoperability specifications has yet to materialize, and so it seems unlikely that this WG or the W3C WG will manage to fully document what changes to the SDP emitted by createOffer and the SDP accepted by setLocalDescription and setRemoteDescription are permitted without a *significant* effort. I will note that the JSEP draft says that calling createOffer is optional, and so it must be possible to, with only access to the specification and the referenced specifications, generate a blob of SDP which is accepted by setLocalDescription in *every* browser implementation. We are nowhere near that point. All of this is of course easily avoided by choosing an API surface which is not an underspecified blob of SDP. Matthew Kaufman From elagerway@gmail.com Mon Oct 22 08:39:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFB921F8C11 for ; Mon, 22 Oct 2012 08:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.394 X-Spam-Level: X-Spam-Status: No, score=-1.394 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMBvG54djrLv for ; Mon, 22 Oct 2012 08:39:24 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C4D3A21F84DD for ; Mon, 22 Oct 2012 08:39:15 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so2037306lbo.31 for ; Mon, 22 Oct 2012 08:39:14 -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 :x-google-sender-auth:message-id:subject:from:to:content-type; bh=p+KmBAF/jDvn8efBrSUU1H4w4O5pI9bVxtE8HJErD0E=; b=RFuHk8nfWQo4OAaTHH7HXT5rbCzW9NLHHlnIttrCPfGDjvIDDWBGo39nKhtCE6ATe7 MdSesDea1Et0qPfeI2eCDYvYYr2IzT18xvai0Jz4K2fNrHPG7MIVL7TUYeAAfpCbn7im llJWQcsXDv/69yPHCCNlzi0rZ8Gf6V3E6vEKfua+Z2WnSGzjrOoJJs/yK8TacRuXDBlG uxfjJyH1RwY+LxacODkgOZH+vL6OWJvodYEXAcrav1c5DJ9wcsuV6AtzJ6h9zcsEmkg3 36B6wnN7epqMc7ewWvBI+CnVu6oXV5jOjkXdd2wTsgTjiTcFnB5vdx4iYzonMQ72xV0Y Nc7A== MIME-Version: 1.0 Received: by 10.152.106.212 with SMTP id gw20mr8599765lab.8.1350920354651; Mon, 22 Oct 2012 08:39:14 -0700 (PDT) Sender: elagerway@gmail.com Received: by 10.114.68.82 with HTTP; Mon, 22 Oct 2012 08:39:14 -0700 (PDT) In-Reply-To: <20121017192046.GO6812@audi.shelbyville.oz> References: <507D4302.9050108@ericsson.com> <20121017192046.GO6812@audi.shelbyville.oz> Date: Mon, 22 Oct 2012 08:39:14 -0700 X-Google-Sender-Auth: Fw-cTozYBbo0LDlV6PcKUE6D_MA Message-ID: From: Erik Lagerway To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=f46d0420a695dbdfd304cca7a735 Subject: Re: [rtcweb] Summary of Video Codec contributions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 15:39:25 -0000 --f46d0420a695dbdfd304cca7a735 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 17, 2012 at 12:20 PM, Ron wrote: > > Hi Erik, > > On Wed, Oct 17, 2012 at 01:56:55AM -0700, Erik Lagerway wrote: > > Thought it important to point out the fact that FREE-P8 (VP8) would > likely > > be the preferred codec implemented by independent developers. Royalties > and > > admin headaches create a barrier to entry. Independent dev shops equate > to > > a great deal of innovation and some of these have been responsible for > > dictating the standard in market with hundreds of millions of users. Yes, > > there is plenty of interoperability with 264 today but that doesn't mean > it > > will be that way tomorrow. > > Very true. Though for developers who don't click-track and count users > of their software it is more than just preferred. An RF solution is > actually the only viable way for this standard to be accessible to them. > > Any standard that immediately excludes a large portion of potential > developers and adopters can only ever be of niche value and is certain > to be replaced before long by an alternative that doesn't have that > constraint as a fundamental flaw preventing its broadest use. > > If the whole point of this group was to avoid further fracturing of > the developer efforts in this space, then solving this problem now > would be much preferable to forcing another group to develop another > competing standard that does address that issue. It would be a sad > waste of the invested time of the people here if we didn't recognise > this necessity. > > I think the points you make above are very relevant here. > > > > Can't we do both, as we have done for Audio MTI? > > Well, the M in MTI stands for Mandatory. So mandating both would be > mandating the barriers to entry that you so clearly identified above? > > Mandating an RF video codec, and permitting any other to be negotiated > as an extension would be more like what we decided was best for audio. > Yes, I see your point and agree. > > > > > > RTCweb / WebRTC is supposed to be the next big thing, why hamper > > innovation like this? > > Indeed we should not, and I for one certainly hope consensus is > that we will not. > Seems to me that if we want to see the indie webrtc developers flourish, we need to implement a RF codec = VP8. Unless of course the MPEG LA decides to grant a RF license on 264/AVC before the WG votes on the MTI? Which does not seem likely given the time frame. That plus the fact this 264/AVC non royalty codec concept was tabled in the past and went nowhere, it seems. I would like to see us foster grassroots innovation by making this tech accessible to all developers, which essentially means zero royalty and admin overhead. > > > Stay sharp! > Ron > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d0420a695dbdfd304cca7a735 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 17, 2012 at 12:20 PM, Ron <ron@debian= .org> wrote:

Hi Erik,

On Wed, Oct 17, 2012 at 01:56:55AM -0700, Erik Lagerway wrote:
> Thought it important to point out the fact that FREE-P8 (VP8) would li= kely
> be the preferred codec implemented by independent developers. Royaltie= s and
> admin headaches create a barrier to entry. Independent dev shops equat= e to
> a great deal of innovation and some of these have been responsible for=
> dictating the standard in market with hundreds of millions of users. Y= es,
> there is plenty of interoperability with 264 today but that doesn'= t mean it
> will be that way tomorrow.

Very true. =A0Though for developers who don't click-track and cou= nt users
of their software it is more than just preferred. =A0An RF solution is
actually the only viable way for this standard to be accessible to them.
Any standard that immediately excludes a large portion of potential
developers and adopters can only ever be of niche value and is certain
to be replaced before long by an alternative that doesn't have that
constraint as a fundamental flaw preventing its broadest use.

If the whole point of this group was to avoid further fracturing of
the developer efforts in this space, then solving this problem now
would be much preferable to forcing another group to develop another
competing standard that does address that issue. =A0It would be a sad
waste of the invested time of the people here if we didn't recognise this necessity.

I think the points you make above are very relevant here.


> Can't we do both, as we have done for Audio MTI?

Well, the M in MTI stands for Mandatory. =A0So mandating both would b= e
mandating the barriers to entry that you so clearly identified above?

Mandating an RF video codec, and permitting any other to be negotiated
as an extension would be more like what we decided was best for audio.
<= /blockquote>

Yes, I see your point and agree.
=A0




> RTCweb / WebRTC is supposed to be the next big thing, why hamper
> innovation like this?

Indeed we should not, and I for one certainly hope consensus is
that we will not.

Seems to me that if we want to s= ee the indie webrtc developers flourish, we need to implement a RF codec =3D VP8.=A0 Unless of course the MPEG LA= =20 decides to grant a RF license on 264/AVC before the WG votes on the=20 MTI? Which does not seem likely given the time frame. That plus the fact th= is 264/AVC non royalty codec concept was tabled in the past and went nowher= e, it seems.

I would like to see us foster grassroots innovation by = making this tech accessible to all developers, which essentially means zero= royalty and admin overhead.
=A0


=A0Stay sharp!
=A0Ron


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

--f46d0420a695dbdfd304cca7a735-- From internet-drafts@ietf.org Mon Oct 22 09:27:19 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D1021F8519; Mon, 22 Oct 2012 09:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElioSnCkHVLz; Mon, 22 Oct 2012 09:27:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3477E21F8518; Mon, 22 Oct 2012 09:27:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022162719.7586.16379.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 09:27:19 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-arch-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:27:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : RTCWEB Security Architecture Author(s) : Eric Rescorla Filename : draft-ietf-rtcweb-security-arch-04.txt Pages : 37 Date : 2012-10-22 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 (e.g JavaScript). The major use cases for RTCWEB 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) RTCWEB communications are directly controlled by some 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. [I-D.ietf-rtcweb- security] defines the RTCWEB threat model. This document defines an architecture which provides security within that threat model. 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-security-arch-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ekr@rtfm.com Mon Oct 22 09:35:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F121721F8B46 for ; Mon, 22 Oct 2012 09:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.811 X-Spam-Level: X-Spam-Status: No, score=-102.811 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-qfcR88+pnh for ; Mon, 22 Oct 2012 09:35:20 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 08A1821F8B50 for ; Mon, 22 Oct 2012 09:35:19 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2025994lam.31 for ; Mon, 22 Oct 2012 09:35:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:content-type:x-gm-message-state; bh=wPAH2Dns99sUokDve80el+t58EiImJgrv3MWj26H0Fw=; b=lZx87hM204SfZpXfgmTyFbuYT3s9SUS/zYhX7re9zsqkHVDlsuuuClGEeXFMpSfhbI L4ZU72RJOmLlcFSdl/LjD6EKvUZNd/RsMibAe+XfNHFyM8nx8iD2wqItrmALuI9gw3ca wQB2almQnL1FAS3+KYCK/zc8LC4VDgCXm9ymMHz3XXQVuvd+2tGj+MyXUJCSz7MCCWaL 5HsKmfCyuN27okGCDS73ODSbd77hGcHtPfsNTuKncTlcdgAGZPpbBZvSgAeHFHjhPjiH 0Ld9EtHpC5uUzIoGgYgixsf+wdhppstsUQWffs4nABLUynE05YGdSjH+mS418tSoHyJG B3ag== Received: by 10.152.103.243 with SMTP id fz19mr8747865lab.27.1350923713637; Mon, 22 Oct 2012 09:35:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.25.39 with HTTP; Mon, 22 Oct 2012 09:34:33 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <20121022162719.7586.16379.idtracker@ietfa.amsl.com> References: <20121022162719.7586.16379.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Mon, 22 Oct 2012 09:34:33 -0700 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmL9C6MMDJFfEqeDFUG2BzoeGOo5eITwO90pf1+QsDthcu9jvw/iZl6GiSwCVPgVEUjbyOc Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-security-arch-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:35:21 -0000 Please ignore this version. I had a version control hiccup. Will post the correct version in a few minutes after I unscrew things. -Ekr On Mon, Oct 22, 2012 at 9:27 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. > > Title : RTCWEB Security Architecture > Author(s) : Eric Rescorla > Filename : draft-ietf-rtcweb-security-arch-04.txt > Pages : 37 > Date : 2012-10-22 > > 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 (e.g > JavaScript). The major use cases for RTCWEB 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) RTCWEB communications are directly controlled by some 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. [I-D.ietf-rtcweb- > security] defines the RTCWEB threat model. This document defines an > architecture which provides security within that threat model. > > > 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-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-security-arch-04 > > > 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 internet-drafts@ietf.org Mon Oct 22 10:13:19 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A1811E80E3; Mon, 22 Oct 2012 10:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWU2uFBoR7JH; Mon, 22 Oct 2012 10:13:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEF71F0C51; Mon, 22 Oct 2012 10:13:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022171312.14616.82575.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 10:13:12 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-arch-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:13:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : RTCWEB Security Architecture Author(s) : Eric Rescorla Filename : draft-ietf-rtcweb-security-arch-05.txt Pages : 38 Date : 2012-10-22 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 (e.g JavaScript). The major use cases for RTCWEB 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) RTCWEB communications are directly controlled by some 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. [I-D.ietf-rtcweb- security] defines the RTCWEB threat model. This document defines an architecture which provides security within that threat model. 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-security-arch-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 22 14:32:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D5721F892E; Mon, 22 Oct 2012 14:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.407 X-Spam-Level: X-Spam-Status: No, score=-102.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kry6uXyMC0n4; Mon, 22 Oct 2012 14:32:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B431D21F8949; Mon, 22 Oct 2012 14:32:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022213241.15898.74886.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 14:32:41 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 21:32:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : Web Real-Time Communication (WebRTC): Media Transport an= d Use of RTP Author(s) : Colin Perkins Magnus Westerlund Joerg Ott Filename : draft-ietf-rtcweb-rtp-usage-05.txt Pages : 61 Date : 2012-10-22 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 22 16:15:21 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A773D21F8451; Mon, 22 Oct 2012 16:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3i3NsGPacnl; Mon, 22 Oct 2012 16:15:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB6011E80AD; Mon, 22 Oct 2012 16:15:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022231520.4883.45004.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 16:15:20 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 23:15:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : RTCWeb Datagram Connection Author(s) : Randell Jesup Salvatore Loreto Michael Tuexen Filename : draft-ietf-rtcweb-data-channel-02.txt Pages : 12 Date : 2012-10-22 Abstract: The Web Real-Time Communication (WebRTC) working group is charged to provide protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document describes 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 Browser 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-data-channel-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 22 16:52:43 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C48211E8125; Mon, 22 Oct 2012 16:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BT1vDNru0Mos; Mon, 22 Oct 2012 16:52:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC9711E812A; Mon, 22 Oct 2012 16:52:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022235242.5550.10800.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 16:52:42 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 23:52:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : Javascript Session Establishment Protocol Author(s) : Justin Uberti Cullen Jennings Filename : draft-ietf-rtcweb-jsep-02.txt Pages : 33 Date : 2012-10-22 Abstract: This document proposes a mechanism for allowing a Javascript application to fully control the signaling plane of a multimedia session, and discusses how this would work with 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-jsep-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ron@debian.org Mon Oct 22 18:18:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D2B1F0C5F for ; Mon, 22 Oct 2012 18:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMS+5XrGRxDF for ; Mon, 22 Oct 2012 18:18:22 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 0682B1F0429 for ; Mon, 22 Oct 2012 18:18:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAAHvhVB5LQX1/2dsb2JhbABEvhuDQoEJgiABAQQBDiwcDxkLCxguFBgNiDUFrAqQWItYhm8DjgaHagGQOYMC Received: from ppp121-45-5-245.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([121.45.5.245]) by ipmail05.adl6.internode.on.net with ESMTP; 23 Oct 2012 11:48:19 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id BBA364F8F3 for ; Tue, 23 Oct 2012 09:18:57 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FxOYULuI+c4g for ; Tue, 23 Oct 2012 09:18:57 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 170BF4F902; Tue, 23 Oct 2012 09:18:57 +1030 (CST) Date: Tue, 23 Oct 2012 09:18:57 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20121022224857.GU6812@audi.shelbyville.oz> References: <5082DE08.5040007@matthew.at> <20121021210147.GR6812@audi.shelbyville.oz> <5084C273.4070706@matthew.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5084C273.4070706@matthew.at> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] (resend) RE: Draft agenda for RTCWeb session 2 at IETF85 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 01:18:23 -0000 On Sun, Oct 21, 2012 at 08:50:11PM -0700, Matthew Kaufman wrote: > On 10/21/2012 2:01 PM, Ron wrote: > >Unless the presentations are going to announce new perpetual RF > >licencing conditions for H.264, I don't really see what new facts > >might be presented that can change the reality of: > > > >"People invested in H.264 licences or owning its IPR prefer H.264 > > and the exclusivity and revenue streams it brings them." > > > >"People who don't qualify for H.264 licences will be screwed unless > > we pick VP8 as the baseline - and will need to either fork RTCWeb, > > or adopt or create an alternative to it." > > If only it were this simple. My employer spends more on H.264 > licensing than it receives in return, and it isn't about > "exclusivity" or "revenue streams" It is fairly normal to need to pay for exclusivity :) It certainly means that I could not ship a Free RTCWeb implementation with H.264 as MTI to the same volume of users that your employer might. If the cost of simply tracking all those users didn't bankrupt me all by itself, then the licence fees certainly would try to finish the job. That sounds like exclusivity to me. If not a little Deja Vu of the good old days of the First Browser Wars ... > John Leslie said: > > "The actual decisions will > be made by folks [who] won't be in the room. > > Those decisions won't be driven by which codec is better: they'll > be driven by what _risks_ are taken by implementing one or the other." > > And this is a much more accurate way of saying it... and why, for > anyone in the room actually on the "implementation" side, there's > not much point in continuing to debate the potential merits unless > the landscape is *significantly* changed from its current state (for > example, RF licenses for H.264 or total indemnification provided by > VP8's owner.) I don't really understand this repeated insistence that VP8 is somehow more risky unless it comes with Total Indemnification? H.264 certainly doesn't come with total indemnification, and MPEG-LA is very clear that absolutely nothing which they licence comes with even token indemnification from them or anyone else - or even with a licence from all the people you might actually need a licence from. This requirement is totally unprecedented, and such offers are near to totally non-existent in the real world. The landscape would most certainly be changed if we woke up to find it covered in unicorns, but I don't think anybody would take that seriously as a technical prerequisite for some candidate technology. The reality today is that H.264 is currently being prosecuted in the courts over infringement claims -- while the only apparent threat to VP8 is a mythical pool, that hasn't actually been formed, that hasn't actually issued any licencing demands, and that the people who wanted to form it have refused to say anything about for over a year, since they last mumbled "yeah, some people responded. really they did." H.264 being released under an RF licence would indeed be a game-changer, though even if that happened, on the evidence at hand today it is still clearly the more patently risky (no pun intended) of the two unless you happen to be one of its IPR holders (and even then, so it would seem). If the current lawsuit against H.264 had instead been prosecuted against a user of VP8, the prosecuting party would have lost their licence to use VP8. No such protection exists for me if I use H.264. So the balance of both risk and protection would already seem tilted in favour of VP8 too. If anyone should be required to provide a total indemnity, then surely H.264 is in more evident and urgent need of such a thing, given the risk to it is already *known* to not be hypothetical. What am I missing that means VP8 should need to jump over an even higher bar for acceptance in this respect? So far as I can see it already has, hasn't it? Cheers, Ron From bernard_aboba@hotmail.com Mon Oct 22 19:33:32 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722ED1F0C86 for ; Mon, 22 Oct 2012 19:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.259 X-Spam-Level: X-Spam-Status: No, score=-102.259 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tarSohxyrc1U for ; Mon, 22 Oct 2012 19:33:32 -0700 (PDT) Received: from blu0-omc4-s34.blu0.hotmail.com (blu0-omc4-s34.blu0.hotmail.com [65.55.111.173]) by ietfa.amsl.com (Postfix) with ESMTP id D66D921F84C5 for ; Mon, 22 Oct 2012 19:33:31 -0700 (PDT) Received: from BLU002-W44 ([65.55.111.137]) by blu0-omc4-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Oct 2012 19:33:30 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_1f65d363-6809-4b73-beaf-11e0a248ed8f_" X-Originating-IP: [72.11.69.66] From: Bernard Aboba To: Ron , "rtcweb@ietf.org" Date: Mon, 22 Oct 2012 19:33:29 -0700 Importance: Normal In-Reply-To: <20121022224857.GU6812@audi.shelbyville.oz> References: <5082DE08.5040007@matthew.at>, <20121021210147.GR6812@audi.shelbyville.oz>, <5084C273.4070706@matthew.at>, <20121022224857.GU6812@audi.shelbyville.oz> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Oct 2012 02:33:30.0156 (UTC) FILETIME=[C9EFC6C0:01CDB0C6] Subject: Re: [rtcweb] (resend) RE: Draft agenda for RTCWeb session 2 at IETF85 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 02:33:32 -0000 --_1f65d363-6809-4b73-beaf-11e0a248ed8f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ron said:=20 > If the cost of simply tracking all those users didn't bankrupt me all > by itself=2C then the licence fees certainly would try to finish the job. [BA] Pardon me if I'm obtuse=2C but I'd like to better understand the situ= ation that is resulting in your being concerned about having to pay license= fees and track users.=20 Are you developing HTML5 applications? f so=2C are you envisaging that as = an HTML5 developer writing a WebRTC application for a browser that supports= H.264 you would need to pay licensing fees?=20 Are you working for a browser vendor? If so=2C are you envisaging that you= would need to pay licensing fees based on the number of users of your brow= ser?=20 Are you a developer of applications looking to interoperate with WebRTC? I= f so=2C are you calling APIs that enable you to use the H.264 implementatio= n in the OS platform=2C or accessing the hardware encode/decode functionali= ty (available on most SoC platforms)? If so=2C do you believe that you nee= d to pay license fees?=20 Or do you primarily develop on platforms without H.264 support in the OS=2C= and on hardware with no H.264 encode/decode support? =20 = --_1f65d363-6809-4b73-beaf-11e0a248ed8f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ron said:
>=3B If the= cost of simply tracking all those users didn't bankrupt me all
>=3B b= y itself=2C then the licence fees certainly would try to finish the job.
[BA] =3B Pardon me if I'm obtuse=2C but I'd like to better underst= and the situation that is resulting in your being concerned about having to= pay license fees and track users.

Are you developing HTML5 applica= tions? =3B f so=2C are you envisaging that as an HTML5 developer writin= g a WebRTC application for a browser that supports H.264 you would need to = pay licensing fees?

Are you working for a browser vendor? =3B I= f so=2C are you envisaging that you would need to pay licensing fees based = on the number of users of your browser?

Are you a developer of appl= ications looking to interoperate with WebRTC? =3B If so=2C are you call= ing APIs that enable you to use the H.264 implementation in the OS platform= =2C or accessing the hardware encode/decode functionality (available on mos= t SoC platforms)? =3B If so=2C do you believe that you need to pay lice= nse fees?

Or do you primarily develop on platforms without H.264 su= pport in the OS=2C and on hardware with no H.264 encode/decode support?&nbs= p=3B


= --_1f65d363-6809-4b73-beaf-11e0a248ed8f_-- From trac+rtcweb@trac.tools.ietf.org Mon Oct 22 15:36:31 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6DE11E808D for ; Mon, 22 Oct 2012 15:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sd+wa4WIuYZ9 for ; Mon, 22 Oct 2012 15:36:30 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id E619D11E80AD for ; Mon, 22 Oct 2012 15:36:28 -0700 (PDT) Received: from localhost ([127.0.0.1]:52941 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TQQbW-00057U-F6; Tue, 23 Oct 2012 00:36:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: jmvalin@jmvalin.ca, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Mon, 22 Oct 2012 22:36:14 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/1 Message-ID: <066.ee8d274029b0215df9ff464ea44b5fe7@trac.tools.ietf.org> X-Trac-Ticket-ID: 1 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jmvalin@jmvalin.ca, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Tue, 23 Oct 2012 01:27:04 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] #1: RFC 4734 citation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 22:36:31 -0000 #1: RFC 4734 citation Section 3 states: WebRTC clients are REQUIRED to implement the following audio codecs. o Opus [RFC6716], with any ptime value up to 120 ms o G.711 PCMA and PCMU with one channel, a rate of 8000 Hz and a ptime of 20 - see section 4.5.14 of [RFC3551] o Telephone Event - [RFC4734] [BA] I believe the citation should be to "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals" [RFC4733], not to "Definition of Events for Modem, Fax, and Text Telephony Signals" [RFC4734]. If the desire is in fact to mandate support for RFC 4734, please explain why it is necessary for browsers to include support for digital encoding of modem and fax signals. -- --------------------------------+------------------------ Reporter: bernard_aboba@… | Owner: jmvalin@… Type: defect | Status: new Priority: critical | Milestone: milestone1 Component: audio | Version: 1.0 Severity: Active WG Document | Keywords: --------------------------------+------------------------ Ticket URL: rtcweb From trac+rtcweb@trac.tools.ietf.org Mon Oct 22 15:58:39 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23B521F8470 for ; Mon, 22 Oct 2012 15:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOWhSXdK7ygU for ; Mon, 22 Oct 2012 15:58:38 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 3B01D21F844C for ; Mon, 22 Oct 2012 15:58:37 -0700 (PDT) Received: from localhost ([127.0.0.1]:55142 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TQQwx-0003iW-Cw; Tue, 23 Oct 2012 00:58:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: csp@csperkins.org, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Mon, 22 Oct 2012 22:58:23 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/2 Message-ID: <066.81f7a0339f5b268a5112f46329622778@trac.tools.ietf.org> X-Trac-Ticket-ID: 2 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: csp@csperkins.org, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Tue, 23 Oct 2012 01:27:04 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] #2: Section 7.1 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 22:58:40 -0000 #2: Section 7.1 Section 7.1 states: The circuit breaker defines a conservative boundary condition for safe operation, chosen such that applications that trigger the circuit breaker will almost certainly be causing severe network congestion. [BA] While it is true that when circuit breakers are triggered it is likely that very severe network congestion is occurring along the path, severe network congestion (or even a congestive collapse) will not necessarily trigger the circuit breakers. For example, one of the circuit breakers is only triggered if *no* packets are received; even in a congestive collapse, *some* packets will get through. Therefore the lack of circuit breaker triggering does not imply that an application is behaving "conservatively" or safely. Recommend change to: "Circuit breakers are designed to enable applications to recognize and react to situations of extreme network congestion. However, since circuit breakers may not be triggered until congestion becomes extreme, circuit breakers are not a substitute for congestion control and applications implementing circuit breakers cannot be considered "conservative" or "safe"." -- --------------------------------+------------------------ Reporter: bernard_aboba@… | Owner: csp@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: rtp-usage | Version: 1.0 Severity: Active WG Document | Keywords: --------------------------------+------------------------ Ticket URL: rtcweb From randell-ietf@jesup.org Tue Oct 23 06:39:36 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8393B21F867A for ; Tue, 23 Oct 2012 06:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gw88jbr7tn+r for ; Tue, 23 Oct 2012 06:39:36 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 1516721F8672 for ; Tue, 23 Oct 2012 06:39:35 -0700 (PDT) Received: from pool-173-49-129-2.phlapa.fios.verizon.net ([173.49.129.2]:1976 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TQehi-0005F0-Tg for rtcweb@ietf.org; Tue, 23 Oct 2012 08:39:35 -0500 Message-ID: <50869D99.50602@jesup.org> Date: Tue, 23 Oct 2012 09:37:29 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <066.ee8d274029b0215df9ff464ea44b5fe7@trac.tools.ietf.org> In-Reply-To: <066.ee8d274029b0215df9ff464ea44b5fe7@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; 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 - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] #1: RFC 4734 citation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 13:39:36 -0000 On 10/22/2012 6:36 PM, rtcweb issue tracker wrote: > #1: RFC 4734 citation > > Section 3 states: > > WebRTC clients are REQUIRED to implement the following audio codecs. > > o Opus [RFC6716], with any ptime value up to 120 ms > > o G.711 PCMA and PCMU with one channel, a rate of 8000 Hz and a > ptime of 20 - see section 4.5.14 of [RFC3551] > > o Telephone Event - [RFC4734] > > [BA] I believe the citation should be to "RTP Payload for DTMF Digits, > Telephony Tones, and Telephony Signals" [RFC4733], not to "Definition of > Events for Modem, Fax, and Text Telephony Signals" [RFC4734]. > > If the desire is in fact to mandate support for RFC 4734, please explain > why it is necessary for browsers to include support for digital encoding > of modem and fax signals. > I'm certain the intent was RFC 4733. -- Randell Jesup randell-ietf@jesup.org From dbenham@cisco.com Tue Oct 23 16:33:26 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6CC11E8112 for ; Tue, 23 Oct 2012 16:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWD499mojm46 for ; Tue, 23 Oct 2012 16:33:25 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE4F11E80A4 for ; Tue, 23 Oct 2012 16:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2272; q=dns/txt; s=iport; t=1351035206; x=1352244806; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=rj5eQjUUHtWx+1e+PjrJZdhUP2l9CdGVnBQjatMqU70=; b=X6Ro7tlpapWpMspzOkr75TXzRlPCwu9U9eo+jTotxNfMBNwh8FzX4w52 xooILz3oU5R5gx00wUwhTsFnjyPRTDlOe1kbvqVwQwaNgf0mnCx9NX5qC 2+JVeOmV7n8p6Cr/ZQbOhlCwU09jVMGdQRI2HVbDweivg31ZEOnvLQXcB I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJkoh1CtJV2b/2dsb2JhbABEwX+BCIIgAQQSASdRASoUQiYBBAEaGodZCQubDo9cgXeOMZFeYAOkQIFrgm+CGA X-IronPort-AV: E=Sophos;i="4.80,637,1344211200"; d="scan'208";a="131685099" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 23 Oct 2012 23:33:25 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9NNXOfA003217 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 23:33:25 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.252]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 18:33:24 -0500 From: "David Benham (dbenham)" To: "bernard_aboba@hotmail.com" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Mobile tests in draft-dbenham-webrtc-videomti Thread-Index: Ac2xdsilQTkTdpfETieoCSI4lO+ZKw== Date: Tue, 23 Oct 2012 23:33:23 +0000 Message-ID: <0683D6CB32AC424D8AF52C0F660E5DC51509BBE9@xmb-aln-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.140.227] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--27.409800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rtcweb] Mobile tests in draft-dbenham-webrtc-videomti X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 23:33:26 -0000 Bria doesn't support VP8 on the desktop. But perhaps can relook at linpho= ne. Also just noticed a URL error for this Bria result (2nd on the list) ... Bria using VP8 on iPhone to linphone on a fast desktop PC.=20 http://dl.dropbox.com/u/17089001/video-samples/iphone-vp8.mov ---------------------------------------------- Looking at the videos from Section 4, using the same software on both sides= might help tease out implementation effects. My understanding is that Bri= a (at least on the iPad) supports both H.264 and VP8, and it would appear t= hat Linphone also supports both. Would it be possible to compare a Bria/Li= nphone conversation with H.264 to one using VP8? >From Section 4: Captures of Mobile Tests; FaceTime using H.264 on an iPhone to linphone on a fast desktop PC. http://dl.dropbox.com/u/17089001/video-samples/facetime.mov Bria using VP8 on iPhone to linphone on a fast desktop PC. http:// dl.dropbox.com/u/17089001/video-samples/iphone-vp8-vs-iphone-264.mov Bria using VP8 on Galaxy Nexus to linphone on a fast desktop PC. http://dl.dropbox.com/u/17089001/video-samples/galaxy-nexus.mov Shown side-by-side, Bria using VP8 on iPhone (left) and FaceTime with H.264/AVC on iPhone (right), going to linphone and FaceTime. http:// dl.dropbox.com/u/17089001/video-samples/iphone-vp8-vs-iphone-264.mov Captures of Desktop-only Tests; FaceTime H.264/AVC from a fast notebook computer to fast desktop. htt p://dl.dropbox.com/u/17089001/video-samples/facetime-264-desktop.mov -or- http://dl.dropbox.com/u/17089001/video-samples/ facetime-264-desktop.webm Chrome with VP8 from same fast notebook computer to same fast desktop. http://dl.dropbox.com/u/17089001/video-samples/chrome-vp8-desktop.mov -or- http://dl.dropbox.com/u/17089001/video-samples/ chrome-vp8-desktop.webm Two fast notebook computers - one running Chrome and the other running Fictive - both sending to the same desktop computer shown side by side. http://dl.dropbox.com/u/17089001/video-samples/ chrome_and_factime_desktop.mov> -or- http://dl.dropbox.com/u/17089001/video-samples/ chrome_and_factime_desktop.webm From ron@debian.org Tue Oct 23 22:42:46 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CC021F8C9A for ; Tue, 23 Oct 2012 22:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7O7f2JyvGik for ; Tue, 23 Oct 2012 22:42:44 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 5769421F8C99 for ; Tue, 23 Oct 2012 22:42:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANR+h1B5LSaF/2dsb2JhbABEwgWBCYIeAQEFOhwzCxguFBgNiDq7CItgAYZqA44Ih2oBkDmDAoFQ Received: from ppp121-45-38-133.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([121.45.38.133]) by ipmail06.adl2.internode.on.net with ESMTP; 24 Oct 2012 16:12:42 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 98E504F8F3 for ; Wed, 24 Oct 2012 16:12:40 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bJ7K7PP3UBZP for ; Wed, 24 Oct 2012 16:12:39 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id B55864F902; Wed, 24 Oct 2012 16:12:39 +1030 (CST) Date: Wed, 24 Oct 2012 16:12:39 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20121024054239.GZ6812@audi.shelbyville.oz> References: <5082DE08.5040007@matthew.at> <20121021210147.GR6812@audi.shelbyville.oz> <5084C273.4070706@matthew.at> <20121022224857.GU6812@audi.shelbyville.oz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] (resend) RE: Draft agenda for RTCWeb session 2 at IETF85 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 24 Oct 2012 05:42:46 -0000 Hi Bernard, On Mon, Oct 22, 2012 at 07:33:29PM -0700, Bernard Aboba wrote: > Ron said: > > If the cost of simply tracking all those users didn't bankrupt me all > > by itself, then the licence fees certainly would try to finish the job. > > [BA] Pardon me if I'm obtuse, but I'd like to better understand the > situation that is resulting in your being concerned about having to pay > license fees and track users. > > Are you developing HTML5 applications? f so, are you envisaging that as an > HTML5 developer writing a WebRTC application for a browser that supports > H.264 you would need to pay licensing fees? > > Are you working for a browser vendor? If so, are you envisaging that you > would need to pay licensing fees based on the number of users of your > browser? > > Are you a developer of applications looking to interoperate with WebRTC? If > so, are you calling APIs that enable you to use the H.264 implementation in > the OS platform, or accessing the hardware encode/decode functionality > (available on most SoC platforms)? If so, do you believe that you need to > pay license fees? > > Or do you primarily develop on platforms without H.264 support in the OS, and > on hardware with no H.264 encode/decode support? Yes, I see the distinction that you're aiming to point out there, but I hadn't got the impression that anybody here actually was confused by the difference between: "If a licenced implementation of H.264 is available, you can use it." and "RTCWeb can only be used on platforms with a licenced H.264 codec." The former does not require H.264 to be MTI. Like any other codec it can always be negotiated when support for it exists at both ends. The latter is a consequence of making H.264 MTI and would make this standard useless to anyone who did not buy a licence to it themselves or were not happy to restrict their userbase to platforms that had purchased one for them in advance, whether they wanted it or not. That doesn't seem like a good starting point for a standard that likes to describe SIP as "legacy technology", and aims to become a (if not The) ubiquitous communication technology for the future. I don't see what is confusing about the idea that the baseline spec should be RF, and open to as wide a field of users and developers as possible -- with the ability to negotiate the optional use of other (possibly royalty encumbered) technologies where some more constrained demand or deployment or rationale for those also exists. This would be consistent with the criteria applied for selection of the MTI audio codec. To return just briefly to the question of "risk" that was raised, one other advantage to making VP8 the choice of MTI codec which occurs to me is that since the known VP8 IPR comes with protective conditions for its users in the form of the "poison pill" clauses of its RF licence - then by making it MTI here, we'd also confer that protection more broadly to RTCWeb users, since anyone suing them for using VP8 would then also lose their own "licence" to implement the RTCWeb standard too. If RTCWeb is as successful at unifying communications as we all hope it will be, that would certainly be a strong disincentive to hostile action for anyone likely to actually hold patents on any relevant communication technology. That sounds like a much stronger form of protection to me than "MPEG-LA can licence you lots of, but not all of, the patents for H.264". Doesn't it? Acutely, Ron From lishitao@huawei.com Tue Oct 23 23:55:14 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689B121F8CF2 for ; Tue, 23 Oct 2012 23:55:14 -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=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYbzmYQrUsT5 for ; Tue, 23 Oct 2012 23:55:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF4721F8C9C for ; Tue, 23 Oct 2012 23:55:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMA01630; Wed, 24 Oct 2012 06:55:09 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 24 Oct 2012 07:54:16 +0100 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 24 Oct 2012 07:54:24 +0100 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.141]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Wed, 24 Oct 2012 14:54:20 +0800 From: Lishitao To: "Cullen Jennings (fluffy)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Agenda requests for Atlanta meeting Thread-Index: AQHNoK/OaXWxPI617EqOttEhNvOaiJeoxq0AgB9XU/A= Date: Wed, 24 Oct 2012 06:54:19 +0000 Message-ID: References: <506B0367.4000103@ericsson.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.73.75] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [rtcweb] Agenda requests for Atlanta meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 24 Oct 2012 06:55:14 -0000 Hi Cullen and all If time is permitted, I suggest in JSEP part we can discuss the Rehydration= scenario. I have an alternative approach in draft-li-rtcweb-ice-page-reload-02, which= suggests=20 to re-use the old connection to recovery the session. Also I see that in th= e JSEP-02, it also=20 indicate an open issue for the Rehydration scenario, so I think it is worth= to discuss it during=20 the meeting. I can provide some slides for it if needed.=20 Commends for my approach are also welcomed. Regards shitao > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Cullen Jennings (fluffy) > Sent: Thursday, October 04, 2012 11:44 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Agenda requests for Atlanta meeting >=20 >=20 > With my individual contributor hat on . >=20 > Justin and I would like to have some time for JSEP. I think there are a b= unch of > issues, particularly around the use of SDP and timing of various things t= hat > need discussion. >=20 > Thanks, Cullen >=20 >=20 >=20 > On Oct 2, 2012, at 9:08 AM, Magnus Westerlund > wrote: >=20 > > WG, > > > > We chairs like to have input into what you see should be on the Agenda > > for our two meeting slots in Atlanta. Both document editors/authors and > > participant are welcome to request or inform the WG or the chairs only > > about issues that needs to be discussed in the meeting. > > > > Two items we chairs believe should be on the agenda are: > > > > - Video codec selection > > - JSEP > > > > > > > > Cheers > > > > Magnus Westerlund > > > > ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVM > > ---------------------------------------------------------------------- > > 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 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From stewe@stewe.org Wed Oct 24 02:40:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722AC21F8A8C; Wed, 24 Oct 2012 02:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.028 X-Spam-Level: X-Spam-Status: No, score=-4.028 tagged_above=-999 required=5 tests=[AWL=-0.430, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2dBGQGmzD3Z; Wed, 24 Oct 2012 02:40:19 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id A084021F8A2F; Wed, 24 Oct 2012 02:40:19 -0700 (PDT) Received: from mail122-co1-R.bigfish.com (10.243.78.248) by CO1EHSOBE005.bigfish.com (10.243.66.68) with Microsoft SMTP Server id 14.1.225.23; Wed, 24 Oct 2012 09:40:19 +0000 Received: from mail122-co1 (localhost [127.0.0.1]) by mail122-co1-R.bigfish.com (Postfix) with ESMTP id 156075400BC; Wed, 24 Oct 2012 09:40:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT005.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: PS2(zzc85fh14ffIzz1202h1d1ah1d2ah1082kzz8275bhz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh34h1155h) Received-SPF: pass (mail122-co1: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT005.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail122-co1 (localhost.localdomain [127.0.0.1]) by mail122-co1 (MessageSwitch) id 1351071616952657_28723; Wed, 24 Oct 2012 09:40:16 +0000 (UTC) Received: from CO1EHSMHS022.bigfish.com (unknown [10.243.78.240]) by mail122-co1.bigfish.com (Postfix) with ESMTP id E3737BC0065; Wed, 24 Oct 2012 09:40:16 +0000 (UTC) Received: from BL2PRD0710HT005.namprd07.prod.outlook.com (157.56.240.133) by CO1EHSMHS022.bigfish.com (10.243.66.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 24 Oct 2012 09:40:14 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.12.69]) by BL2PRD0710HT005.namprd07.prod.outlook.com ([10.255.102.40]) with mapi id 14.16.0233.001; Wed, 24 Oct 2012 09:40:13 +0000 From: Stephan Wenger To: "video-codec@ietf.org" , "rtcweb@ietf.org" Thread-Topic: Incoming liaison statement from MPEG Thread-Index: AQHNscuQrKWwUbiVwUGukf/J2FnY8g== Date: Wed, 24 Oct 2012 09:40:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.5] Content-Type: multipart/mixed; boundary="_004_FDBFA77C7400C74F87BC297393B53E3525930387BL2PRD0710MB349_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: [rtcweb] Incoming liaison statement from MPEG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 24 Oct 2012 09:40:20 -0000 --_004_FDBFA77C7400C74F87BC297393B53E3525930387BL2PRD0710MB349_ Content-Type: multipart/alternative; boundary="_000_FDBFA77C7400C74F87BC297393B53E3525930387BL2PRD0710MB349_" --_000_FDBFA77C7400C74F87BC297393B53E3525930387BL2PRD0710MB349_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Please find attached an incoming liaison statement from MPEG. It's short, = and therefore attached. For those not familiar with MPEG's terminology: "A= VC" stands for "Advanced Video Codec" and is used in certain circles for wh= at other people know as H.264, and sometimes, depending on context, only fo= r the non-scalable and non-multiview profiles of H.264. (H.264 is the ITU = designation for the joint standard). MPEG-4 part 29, or WebVC is, as descr= ibed in the statement, what most people know as "constrained baseline H.264= ", i.e. H.264 baseline without the rarely used tools known as Arbitrary Sli= ce Order, Flexible Macroblock Order, and Redundant Slices. Also, in order to avoid possible confusion, let me emphasize that this liai= son statement comes from the standardization body known as MPEG (ISO/IEC JT= C1/SC29/WG11 ) and not from the licensing administrator known as MPEG-LA. Regards, Stephan --_000_FDBFA77C7400C74F87BC297393B53E3525930387BL2PRD0710MB349_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi all,
Please find attached an incoming liaison statement from MPEG.  It= 's short, and therefore attached.  For those not familiar with MPEG's = terminology: "AVC" stands for "Advanced Video Codec" an= d is used in certain circles for what other people know as H.264, and sometimes, depending on context, only for the non-scalable and non-mul= tiview profiles of H.264.  (H.264 is the ITU designation for the joint= standard).  MPEG-4 part 29, or WebVC is, as described in the statemen= t, what most people know as "constrained baseline H.264", i.e. H.264 baseline without the rarely used tools known as Ar= bitrary Slice Order, Flexible Macroblock Order, and Redundant Slices.
Also, in order to avoid possible confusion, let me emphasize that this= liaison statement comes from the standardization body known as MPEG (ISO/I= EC JTC1/SC29/WG11 ) and not from the licensing administrator known as MPEG-= LA.
Regards,
Stephan



--_000_FDBFA77C7400C74F87BC297393B53E3525930387BL2PRD0710MB349_-- --_004_FDBFA77C7400C74F87BC297393B53E3525930387BL2PRD0710MB349_ Content-Type: application/msword; name="29n130661.doc" Content-Description: 29n130661.doc Content-Disposition: attachment; filename="29n130661.doc"; size=58880; creation-date="Wed, 24 Oct 2012 09:40:12 GMT"; modification-date="Wed, 24 Oct 2012 09:40:12 GMT" Content-ID: <3FE3E000127FA74298C4AA785BDAB5A9@namprd07.prod.outlook.com> Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAbgAAAAAAAAAA EAAAcAAAAAEAAAD+////AAAAAG0AAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAJ2AJBAAA8FK/AAAAAAAAEAAAAAAABgAAyA0AAA4AYmpialZ3VncAAAAAAAAAAAAAAAAAAAAA AAARBBYAOB4AADQdAQA0HQEAugUAAAAAAAANAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAKQAAAAAAKAMAAAAAAAAoAwAAKAM AAAAAAAAoAwAAAAAAACgDAAAAAAAAKAMAAAAAAAAoAwAABQAAAAAAAAAAAAAALQMAAAAAAAAGBEA AAAAAAAYEQAAAAAAABgRAAA4AAAAUBEAACQAAAB0EQAAHAAAALQMAAAAAAAAm4MAAP4CAACcEQAA KAAAAMQRAAAAAAAAxBEAAAAAAADEEQAAAAAAAMQRAAAAAAAA5CYAAAAAAADkJgAAAAAAAOQmAAAA AAAAGoMAAAIAAAAcgwAAAAAAAByDAAAAAAAAHIMAAAAAAAAcgwAAAAAAAByDAAAAAAAAHIMAACQA AACZhgAAaAIAAAGJAABYAAAAQIMAABUAAAAAAAAAAAAAAAAAAAAAAAAAoAwAAAAAAAAzKAAAAAAA AAAAAAAAAAAAAAAAAAAAAADCJgAAIgAAAOQmAAAAAAAAMygAAAAAAAAzKAAAAAAAAECDAAAAAAAA AAAAAAAAAACgDAAAAAAAAKAMAAAAAAAAxBEAAAAAAAAAAAAAAAAAAMQRAAD+FAAAVYMAABYAAADP KgAAAAAAAM8qAAAAAAAAzyoAAAAAAAAzKAAAxAAAAKAMAAAAAAAAxBEAAAAAAACgDAAAAAAAAMQR AAAAAAAAGoMAAAAAAAAAAAAAAAAAAL8qAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAMygAAAAAAAAagwAAAAAAAAAAAAAAAAAAzyoAAAAAAADPKgAA EgMAAPRwAACQAgAAoAwAAAAAAACgDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhHcAAAAAAADEEQAAAAAAAJARAAAMAAAA0PykKdqw zQEAAAAAAAAAABgRAAAAAAAA9ygAAIgAAACEcwAAPgAAAAAAAAAAAAAAroIAAGwAAABrgwAAMAAA AJuDAAAAAAAAwnMAAMIDAABZiQAAAAAAAH8pAADKAAAAWYkAAHwAAACEdwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACE dwAASgkAAFmJAAAAAAAAAAAAAAAAAACgDAAAAAAAAM6AAADgAQAA5CYAADAAAAAUJwAAIgAAAK0q AAASAAAANicAABwAAABSJwAA4QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5CYA AAAAAADkJgAAAAAAAOQmAAAAAAAAQIMAAAAAAABAgwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAASSoAAGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOQmAAAA AAAA5CYAAAAAAADkJgAAAAAAAJuDAAAAAAAAMygAAAAAAAAzKAAAAAAAADMoAAAAAAAAMygAAAAA AAAAAAAAAAAAALQMAAAAAAAAtAwAAAAAAAC0DAAAZAQAABgRAAAAAAAAtAwAAAAAAAC0DAAAAAAA ALQMAAAAAAAAGBEAAAAAAAC0DAAAAAAAALQMAAAAAAAAtAwAAAAAAACgDAAAAAAAAKAMAAAAAAAA oAwAAAAAAACgDAAAAAAAAKAMAAAAAAAAoAwAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhJTlRF Uk5BVElPTkFMIE9SR0FOSVNBVElPTiBGT1IgU1RBTkRBUkRJU0FUSU9ODU9SR0FOSVNBVElPTiBJ TlRFUk5BVElPTkFMRSBERSBOT1JNQUxJU0FUSU9ODUlTTy9JRUMgSlRDIDEvU0MgMjkvV0cgMTEN Q09ESU5HIE9GIE1PVklORyBQSUNUVVJFUyBBTkQgQVVESU8NDQ1JU08vSUVDIEpUQyAxL1NDIDI5 L1dHIDExL04xMzE2Nw1TaGFuZ2hhaSwgQ2hpbmEsIE9jdG9iZXIgMjAxMiANDQ1Tb3VyY2UHQ29u dmVub3IHB1RpdGxlB0xpYWlzb24gU3RhdGVtZW50IHRvIElFVEYgUlRDV2ViIFdHIGFuZCBJRVRG IHZpZGVvLWNvZGVjIEJvRiBvbiB0aGUgcHJvZ3Jlc3Mgb2YgSVZDIGFuZCBXZWJWQwcHU3RhdHVz B0FwcHJvdmVkBwcNDU1QRUcgd291bGQgbGlrZSB0byBpbmZvcm0geW91IG9mIGl0cyBvbi1nb2lu ZyBlZmZvcnRzIHRvIGRldmVsb3AgYSBub24tcm95YWx0eSBiZWFyaW5nIHZpZGVvIGNvbXByZXNz aW9uIHN0YW5kYXJkLiBNUEVHIGN1cnJlbnRseSBoYXMgdHdvIHBhdGhzIHVuZGVyIGludmVzdGln YXRpb24gdG8gYWNoaWV2ZSB0aGlzIG9iamVjdGl2ZTsgV2ViVkMgYW5kIElWQy4gV2ViVkMgaXMg dGhlIHNhbWUgYXMgQVZDIENvbnN0cmFpbmVkIEJhc2VsaW5lIHByb2ZpbGUgYW5kIGlzIGtub3du IGFzIJNNUEVHLTQgcGFydCAyOZQuIFRoaXMgZG9jdW1lbnQgaGFzIGJlZW4gcHVibGlzaGVkIGFz IENvbW1pdHRlZSBEcmFmdCAoQ0QpIGFuZCBpcyBwdWJsaWNseSBhdmFpbGFibGUgZnJvbSATIEhZ UEVSTElOSyAiaHR0cDovL21wZWcuY2hpYXJpZ2xpb25lLm9yZy93b3JraW5nX2RvY3VtZW50cy9t cGVnLTA0L3BhcnQyOS9XVkMuemlwIiAUaHR0cDovL21wZWcuY2hpYXJpZ2xpb25lLm9yZy93b3Jr aW5nX2RvY3VtZW50cy9tcGVnLTA0L3BhcnQyOS9XVkMuemlwFS4gSVZDIGlzIGFuIG9uLWdvaW5n IGV4cGxvcmF0aW9uIGFjdGl2aXR5IHdoaWNoIGhhcyBzaG93biBwcm9taXNpbmcgcmVzdWx0cyBh bmQgaGFzIHJlc3VsdGVkIGluIHR3byByZXZpc2lvbnMgb2YgYSByZWZlcmVuY2UgbW9kZWwgYmVp bmcgZGVmaW5lZC4gVGhlc2UgZWZmb3J0cyBoYXZlIGJlZW4gYWN0aXZlbHkgcHVyc3VlZCBzaW5j ZSBNYXJjaCAyMDExIChzZWUgEyBIWVBFUkxJTksgImh0dHA6Ly9tcGVnLmNoaWFyaWdsaW9uZS5v cmcvbWVldGluZ3MvZGFlZ3UxMS9kYWVndV9wcmVzcy5odG0iIBRodHRwOi8vbXBlZy5jaGlhcmln bGlvbmUub3JnL21lZXRpbmdzL2RhZWd1MTEvZGFlZ3VfcHJlc3MuaHRtFSkuIA0NTVBFRyB3aXNo ZXMgdG8gZW1waGFzaXNlIHRoZSBpbXBvcnRhbmNlIG9mIGF2b2lkaW5nIG1hcmtldCBmcmFnbWVu dGF0aW9uIGluIHRoaXMgc3BhY2UgYW5kLCB0aGVyZWZvcmUsIHRoZSBzaWduaWZpY2FuY2Ugb2Yg YWxpZ25pbmcgb3VyIGVmZm9ydHMuIEFzIHN1Y2gsIHdlIHdvdWxkIHdlbGNvbWUgYW55IHBvdGVu dGlhbCBjb2xsYWJvcmF0aW9uIGluIHRoaXMgc3BhY2UuDQ0NAw0NBA0NAw0NBA0NDQ0AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAABCAAA MAgAAF0IAAB3CAAAmwgAAJwIAACdCAAAtwgAAL0IAAC+CAAA1ggAANoIAADbCAAA3QgAAN4IAADf CAAA7wgAAPAIAAD2CAAA6dfFs6Wflo+IfndwZ2BXSz41PgAAAAAAAAAQFWgLZqQAFmjBGdYAYUoc AAAYFWgLZqQAFmjBGdYANQiBQioBcGgAAAAAABYVaA0rlAAWaMEZ1gA1CIFcCIFhShwAABAWaMEZ 1gA1CIFcCIFhShwAAA0WaDZtPwA1CIFeSgIAEBZo+EF+ADUIgV5KAgBvKAEADRZo+EF+ADUIgV5K AgANFmj3AjkANQiBXkoCABMVaJ9BRgAWaDZtPwA1CIFDShwADRZo+S+UADUIgUNKHAANFmg2bT8A NQiBQ0ocABAVaJYurwAWaMEZ1gBhShwAAAoWaMEZ1gBhShwAABoVaJYurwAWaMEZ1gA1CIFDShwA XAiBYUocAAAiFWiHCm8AFmjBGdYANQiBQ0ocAFwIgWFKHABtSBAEc0gQBAAiFWgqZv4AFmjBGdYA NQiBQ0ocAFwIgWFKHABtSAwEc0gMBAAiFWgqZv4AFmj0V5EANQiBQ0ocAFwIgWFKHABtSAwEc0gM BAAsA2oAAAAAFmhbBPYANQiBQ0ocAFUIAVwIgWFKHABtSAAEbkgABHNICQR1CAETAAYAADAIAABd CAAAdwgAAJsIAACcCAAAnQgAAL4IAADdCAAA3ggAAN8IAADmCAAA7wgAAPAIAAD2CAAA9wAAAAAA AAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPIAAAAAAAAAAAAA AADyAAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAAN4AAAAAAAAAAAAAAADWAAAAAAAAAAAAAAAA1gAA AAAAAAAAAAAAAM0AAAAAAAAAAAAAAADNAAAAAAAAAAAAAAAAfgAAAAAAAAAAAAAAAM0AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAE4AAGtkAAAAABYkARckAUlmAQAAAAKWbAAHlEIACNYwAAKU/y8D9yQA AgAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAFPYBAAAVNgEX9gMAABrWCAAA AP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/NNYGAAEKA2wAYfYDAAB5dFwa qAAJAAAWJAFJZgEAAABnZMEZ1gAABwAAAyQCYSQCZ2TBGdYAAAcAAAMkAmEkAmdkNm0/AAALAAAD JAINxgUAAZAkAmEkAmdkNm0/AAAEAABnZMEZ1gAABwAAAyQBYSQBZ2TBGdYAAA4ABgAAug0AAMcN AAD9/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQEAAEBAvYIAAD+CAAA/wgA AAsJAAAZCQAAGgkAADMJAAA2CQAAUwkAAFQJAABlCQAAZgkAAGcJAABoCQAAewkAAIkJAACPCQAA kAkAAKgJAACpCQAACwoAACUKAAA8CgAAnAoAAKUKAACxCgAAxgoAAOEKAAD27+PazNrM2sCzrKGa jYN5b3lieVh5TnlOeU4AAAAAAAAAAAAAAAAAAAAAABIWaAYcOQBQSgMAbkgJBHRICQQAEhZovEF4 AFBKAwBuSAkEdEgJBAAYFWgeAmIAFmh5BgwAUEoDAG5ICQR0SAkEABIWaJ9SkwBQSgMAbkgJBHRI CQQAEhZoSxFYAFBKAwBuSAkEdEgJBAASFmj3AjkAUEoDAG5ICQR0SAkEABgVaAtmpAAWaEId0ABQ SgMAbkgJBHRICQQADBVoC2akABZoQh3QAAAVFWgLZqQAFmjBGdYAQioBcGgAAAAADBVoC2akABZo wRnWAAAYFWgLZqQAFmjBGdYANQiBQioBcGgAAAAAABcVaFwaqAAWaMEZ1gA1CIFuSBIEdEgSBBoV aKpGrwAWaE46zQA1CIFuSBIEbygBdEgSBAARFmiIDJIANQiBbkgSBHRIEgQXFWiqRq8AFmhOOs0A NQiBbkgSBHRIEgQMFmhcGqgANQiBbygBABEWaFwaqAA1CIFuSBIEdEgSBAAb9ggAAFQJAABVCQAA XAkAAGUJAABmCQAAZwkAAGgJAAD2AAAAAAAAAAAAAAAAqQAAAAAAAAAAAAAAAKAAAAAAAAAAAAAA AACgAAAAAAAAAAAAAAAAUwAAAAAAAAAAAAAAAEsAAAAAAAAAAAAAAABGAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABB4AZ2Q2bT8AAAcAADckADgkAGdkwRnWAABMAABrZLoAAAAWJAEXJAFJ ZgEAAAAClmwACNYwAAKU/y8D9yQAAgAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAA AAAAFPYBAAAVNgEX9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8A AAD/NNYGAAEKA2wAYfYDAAB5dFwaqAAJAAAWJAFJZgEAAABnZMEZ1gAATAAAa2RfAAAAFiQBFyQB SWYBAAAAApZsAAjWMAAClP8vA/ckAAIAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAA AAAAABT2AQAAFTYBF/YDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/ AAAA/zTWBgABCgNsAGH2AwAAeXRcGqgACQAAFiQBSWYBAAAAZ2SIDJIAAAfhCgAA5goAAOcKAADz CgAAOAsAADoLAAA7CwAAgAsAAIELAACCCwAAjQsAAI8LAACQCwAAlgsAAKsLAAADDAAAEQwAABMM AABIDAAATQwAAE4MAABSDAAAUwwAAJ4MAACfDAAA3AwAAN0MAADfDAAAcg0AAPPl287b5b/lsqie lJ6onoqelH3zfWzzbF1sU5QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhZoeiOSAFBKAwBuSAkEdEgJ BAAcFWh7f0wAFmh7f0wAMEoaAFBKAwBuSAkEdEgJBAAhA2oAAAAAFWh7f0wAFmh7f0wAUEoDAFUI AW5ICQR0SAkEGBVoe39MABZon1KTAFBKAwBuSAkEdEgJBAASFmi8QXgAUEoDAG5ICQR0SAkEABIW aJ9SkwBQSgMAbkgJBHRICQQAEhZoBhw5AFBKAwBuSAkEdEgJBAASFmhLEVgAUEoDAG5ICQR0SAkE ABgVaHt/TAAWaEsRWABQSgMAbkgJBHRICQQAHBVoYx94ABZofBdAADBKGgBQSgMAbkgJBHRICQQA GBVofBdAABZofBdAAFBKAwBuSAkEdEgJBAASFmh8F0AAUEoDAG5ICQR0SAkEABsDagAAAAAWaHwX QABQSgMAVQgBbkgJBHRICQQYFWh7f0wAFmh7f0wAUEoDAG5ICQR0SAkEHGgJAADhDAAA4gwAALgN AAC5DQAAug0AALwNAAC9DQAAvw0AAMANAADCDQAAww0AAMUNAADGDQAAxw0AAMgNAAD2AAAAAAAA AAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAA AOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAA AAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAA AAAAAOsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAA AAoAAAMkAzckADgkAGEkA2dkpn6MAAkAADckADgkAEgkAGdkHgJiAAAPcg0AAHMNAAC3DQAAuA0A ALkNAAC6DQAAuw0AAL0NAAC+DQAAwA0AAMENAADDDQAAxA0AAMcNAADIDQAA8+nSysK6trq2ura6 tsIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAYWaB9RIwAADwNqAAAAABZoH1EjAFUIAQ8WaHt/TABCKgFwaAAAAAAPFmhBJNwAQioB cGgAAAAALBVoXBqoABZon1KTAENKFABPSgQAUEoDAFFKBABeSgQAYUoUAG1ICQRzSAkEABIWaHoj kgBQSgMAbkgJBHRICQQAGBVoeiOSABZoeiOSAFBKAwBuSAkEdEgJBA42ACZQCQAxkGgBOnBXcOkA H7CDLiCwyEEhsIoFIrBuBCOQigUkkIoFJbAAABew0AIYsNACDJDQAgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF0AFiQBFyQBSWYBAAAAAZYA ACF2AAJoATXWBQABA5sDNdYFAQIDyCEjdgABmwMjdgECyCE6VgsAApZsAAeUQgAU9gEAABU2ATXW BQACAQAANNYGAAEFAAAAeXRcGqgAWQAWJAEXJAFJZgEAAAABlgAAIXYAAmgBNdYFAAEDmwM11gUB AgPIISN2AAGbAyN2AQLIITpWCwAClmwAFPYBAAAVNgE11gUAAgEAADTWBgABBQAAAHl0XBqoAFkA FiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQABA5sDNdYFAQIDyCEjdgABmwMjdgECyCE6VgsAApZs ABT2AQAAFTYBNdYFAAIBAAA01gYAAQUAAAB5dFwaqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACGAiUAEgABAJwADwAEAAAAAwAAAAAABAAI AAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAIAAAACAAAAAAAAAAwBgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAABA 8f8CAEAADBAAAI5uQgAAAAIAGWqWbgAAAgAAACAAQ0oYAFBKBQBfSAEEYUoYAG1ICQhuSAQIc0gJ CHRIBAhSAAFAAQACAFIADBQAAFEfIgAAAAUAi4n6UVcwIAAxAAAAFwABAAYkAQomAAtGAQATpPAA FKQ8AEAmAAAWADUIgUNKHABLSCAAXAiBXkoCAGFKIABSAAJAAQACAFIADBQAAHQipAAAAAUAi4n6 UVcwIAAyAAAAFwACAAYkAQomAQtGAQATpPAAFKQ8AEAmAQAVADUIgUNKGgBcCIFdCIFeSgIAYUoc AABKAANAAQACAEoADBQAAFEfIgAAAAUAi4n6UVcwIAAzAAAAFwADAAYkAQomAgtGAQATpPAAFKQ8 AEAmAgAOADUIgVwIgV5KAgBhShoASgAEQAEAAgBKAAwUAABRHyIAAAAFAIuJ+lFXMCAANAAAABcA BAAGJAEKJgMLRgEAE6TwABSkPABAJgMADQA1CIE2CIFcCIFhShwAAEwABUABAAIATAAMFAAAERIX AAAABQCLifpRVzAgADUAAAAUAAUACiYEC0YBABOk8AAUpDwAQCYEFAA1CIE2CIFDShoAXAiBXQiB YUoaAEYABkABAAIARgAMFAAAERIXAAAABQCLifpRVzAgADYAAAAUAAYACiYFC0YBABOk8AAUpDwA QCYFDgA1CIFDShYAXAiBYUoWADgAB0ABAAIAOAAMFAAAERIXAAAABQCLifpRVzAgADcAAAAUAAcA CiYGC0YBABOk8AAUpDwAQCYGAAA+AAhAAQACAD4ADBQAABESFwAAAAUAi4n6UVcwIAA4AAAAFAAI AAomBwtGAQATpPAAFKQ8AEAmBwYANgiBXQiBTAAJQAEAAgBMAAwUAAAREhcAAAAFAIuJ+lFXMCAA OQAAABQACQAKJggLRgEAE6TwABSkPABAJggUAENKFgBPSgIAUUoCAF5KAgBhShYAJABBAPL/oQAk AAwFAAAAAAAAAAAGALVrPYTVMKkw8zDIMAAAAABCAGlA8/+zAEIADAUAAAAAAAAAAAQAGWqWbm4w aIgAABwAF/YDAAA01gYAAQoDbAA01gYAAQUDAABh9gMAAAIACwAAACQAawD0/8EAJAAABQAAAAAA AAAABQDqMLkwyDBqMFcwAAACAAwAAAAAAGIAmgCzAPMAYgAMBAAAzxfBAAAABgBoiCAAKAA8aFBb KQAAADcAOlYPABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/ BAEAAAACAA8AAABkAP5PIQACAGQADAAAAEZyqgAAAAIAYQAyAAAAJQAQAAomAQtGAgANxggAAvQB 0AIAABJk8v4AABOkDgEUpPAAKiQBAB8AQ0oYAE9KAgBQSgMAUUoCAF0IgWFKGABuSBEEdEgRBABg AP5PMQACAGAADAAAAEZyqgAAAAIAYQAzAAAAJQARAAomAgtGAgANxggAAoACcAMAABJkBv8AABOk PAAUpPAAKiQBABwAQ0oWAE9KAgBQSgMAUUoCAGFKFgBuSBEEdEgRBGQA/k9BAAIAZAAMAAAARnKq AAAAAgBhADQAAAAiABIACiYDC0YCAA3GBQABcAMAEmQa/wAAE6Q8ABSk8AAqJAEjADYIgUNKFABP SgIAUEoDAFFKAgBeSgIAYUoUAG5IEQR0SBEEAGwA/k9RAAIAbAAMAAAARnKqAAAAAgBhADUAAAAo ABMABiQBCiYEC0YCAA3GCAACdARQBQAAEmQa/wAAE6Q8ABSk8AAqJAEmADYIgUNKFABPSgIAUEoD AFFKAgBdCIFeSgIAYUoUAG5IEQR0SBEEZgD+T2EAAgBmAAwAAABGcqoAAAACAGEANgAAACgAFAAG JAEKJgULRgIADcYIAAJ0BFAFAAASZBr/AAATpDwAFKTwACokASAAQ0oUAE9KAgBQSgMAUUoCAF5K AgBhShQAbkgRBHRIEQRsAP5PAQACAGwADAAAAEZyqgAAAAUAQQBOAE4ARQBYAAAAIgAVAAMkAQYk AQckAQomAAtGAgASZMr+AAAUpPgCQCYAYSQBJgA1CIFDShwAT0oCAFBKAwBRSgIAXAiBXkoCAGFK HABuSBEEdEgRBGAA/k9RAWIBYAAMAAAARnKqAAAAGwBTAHQAeQBsAGUAIABBAE4ATgBFAFgAIAAr ACAASwBlAHIAbgAgAGEAdAAgADEAOAAgAHAAdAAAAAwAFgADJAAUpPAAYSQABABLSCQAJAATAAEA AgAkAA0FAABQN5AAAAAEAO52IWsgADEAAAACABcAAAAsABQAAQACACwADQUAAFA3kAAAAAQA7nYh ayAAMgAAAAoAGAAPhPAAXoTwAAAALAAVAAEAAgAsAA0FAABQN5AAAAAEAO52IWsgADMAAAAKABkA D4TgAV6E4AEAADIAVUDy/6EBMgAMBAAA4F6RAAAABwDPMKQw0TD8MOow8zCvMAAADAA+KgFCKgJw aAAA/wAsABYAAQACACwADQUAANIvKwAAAAQA7nYhayAANAAAAAoAGwAPhNACXoTQAgAAYgD+TwEA wgFiAAwAAAAIMtsAAAAOAFQAYQBiAGwAZQAgAEMAbwBuAHQAZQBuAHQAcwAAAAsAHAAMJAEqJAEx JAAAIABPSgYAUEoHAFFKBgBeSggAX0hLBG1ICQRzSAkEdEj/AEgA/k/BAdIBSAAMAAAACDLbAAAA DQBUAGEAYgBsAGUAIABIAGUAYQBkAGkAbgBnAAAACAAdAAMkAWEkAQwANQiBNgiBXAiBXQiBPgBC QAEA4gE+AAwAHwA+Tz0AAAACACxnh2UAAAwAHgADJAMUpHgAYSQDFABQSgAAYUoUAG1IAABzSAAA dEgAADYA/k/y//EBNgAMAB4APk89AAAACwAgACgAh2VXWykAIAAoAIdlV1spADIAAAAIAENKGABQ SgAAQgBaQAEAAgJCAAwIIQBwa68AMAYEAPhmD19qMFcwAAACACAAHQBCKglQSgAAYUoVAG1IAABw aAAgYABzSAAAdEgAAABEAP5P8v8RAkQADAAgAHBrrwAwBgsAIAAoAIdlV1spACAAKACHZVdbKQAx AAAAFQBCKglDShgAUEoAAGFKFQBwaAAgYAAATAD+D/L/IQJMAAwDIwA2bT8AAAAKACAAKACHZVdb KQAgACgAh2VXWykAAAAgAENKEgBPSgIAUUoCAF5KAgBfSAEEbUgJCHNICQh0SAkEWgAdAAEAMgJa AAwBIgA2bT8AAAAFABqB6GyHZVdbF1IAABoAIwADJAMNxgUAAVQBABJk0AABABSkeABhJAMcAENK EgBPSgIAUEoDAFFKAgBeSgIAYUoUAHRICQQsACYA8v9BAiwADAEAADZtPwAAAAQAGoHobMJTZ3EA AAsAQ0oQAEVIBgBIKgAAAAAAAMgFAAAFAAAeAAAAAP////8AAAAAMAAAAF0AAAB3AAAAmwAAAJwA AACdAAAAvgAAAN0AAADeAAAA3wAAAOYAAADvAAAA8AAAAPYAAABUAQAAVQEAAFwBAABlAQAAZgEA AGcBAABoAQAA4QQAAOIEAAC4BQAAuQUAALoFAAC8BQAAvQUAAL8FAADABQAAwgUAAMMFAADFBQAA xgUAAMkFAADIkQAwAAAAAAAAAAABAAAAAwAAAAAAAAAAAIAByJEAMAAAAAAAAAAAAQAAAAMAAAAA AAAAAACAAciRADAAAAAAAAAAAAEAAAADAAAAAAAAAAAAgAHIkQAwAAAAAAAAAAABAAAAAwAAAAAA AAAAAIAByJEAMAAAAAAAAAAAAQAAAAMAAAAAAAAAAACAAciRADAAAAAAAAAAAAEAAAADAAAAAAAA AAAAgAHIkQAwAAAAAAAAAAABAAAAAwAAAAAAAAAAAIAByJEAMAAAAAAAAAAAAQAAAAMAAAAAAAAA AACAAciRADAAAAAAAAAAAAEAAAADAAAAAAAAAAAAgAHIkQAwAAAAAAAAAAABAAAAAwAAAAAAAAAA AIAByJEAMAAAAAAAAAAAAQAAAAMAAQAAAAAAAACgAciRADALAAAAAAAAAAIAAAAEAAEAAAAAAAAA oAHIkQAwAAAAAAAAAAACAAAAAQABAAAEAAAAAKAByJEAMA0AAAAAAAAAAgAAAAQAAQAAAAAAAACg AciRADANAAAAAAAAAAIAAAAEAAEAAAAAAAAAoAHIkQAwAAAAAAAAAAACAAAAAQABAAAEAAAAAKAB yJEAMA8AAAAAAAAAAgAAAAQAAQAAAAAAAACgAciRADAPAAAAAAAAAAIAAAAEAAEAAAAAAAAAoAHI kQAwAAAAAAAAAAACAAAAAQABAAAEAAAAAKAByJEAMAAAAAAAAAAAAQAAAAMAAAAAAAAAAACAAciR ADAAAAAAAAAAAAEAAAADAAAAAAAAAAAAgAHIkQAwAAAAAAAAAAABAAAAAwAAAAAAAAAAAIAByJEA MAAAAAAAAAAAAQAAAAMAAAAAAAAAAACAAciRADAAAAAAAAAAAAEAAAADAAAAAAAAAAAAgAHIkQAw AAAAAAAAAAACAAAAAQAAAAAAAAAAAIAByJEAMAAwAAAAAAAAAQAAAAAAAAAAAAAAAACAAcjRADAA MAAAAAAAAAEAAAADAAAAAAAAAAAA5QfIkQAwADAAAAAAAAABAAAAAAAAAAAAAAAAAJQHyNEAMAAw AAAAAAAAAQAAAAMAAAAAAAAAAADlB8iRADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAAlAfI0QAwADAA AAAAAAABAAAAAwAAAAAAAAAAAOUHyJEAMAAwAAAAAAAAAQAAAAAAAAAAAAAAAACUB8jRADAAMAAA AAAAAAEAAAADAAAAAAAAAAAA5QfIkQAwADAAAAAAAAABAAAAAAAAAAAAAAAAAJQHyJEAMAAwAAAA AAAAAQAAAAAAAAAAAAAAIBmUBwAAAAADAAAABgAAAAYAAAAJAAAADAAAAAwAAAAMAAAADAAAAAwA AAAMAAAADAAAAAwAAAAPAAAAAAYAAPYIAADhCgAAcg0AAMgNAAAHAAAACgAAAAwAAAAOAAAAAAYA APYIAABoCQAAyA0AAAgAAAALAAAADQAAAAAGAADHDQAACQAAAOYCAAA6AwAAgAMAAFIEAACeBAAA 3AQAAMgFAAATWBT/FYATWBT/FYQPAADwYAAAAAAABvAgAAAAAgwAAAMAAAADAAAAAgAAAAEAAAAE AAAAAgAAAAEAAABDAAvwGAAAAIEANyIBAIIAuiIAAIMANyIBAIQAuiIAAEAAHvEQAAAA//8AAAAA /wCAgIAA9wAAEAEPAALwSAAAACAACPAIAAAAAQAAAAAIAAAPAAPwMAAAAA8ABPAoAAAAAQAJ8BAA AAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAAAAAPAALwPBQAABAACPAIAAAAAgAAAAME AAAPAAPw2hMAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAABAAABQAA AA8ABPCiEwAAogQK8AgAAAADBAAAAAoAADMAC/BeEwAAgMMaAAAAgcMyEwAAvwMCAAIARAB0AHMA UwBoAGEAcABlAE4AYQBtAGUAAABFAFUAUgAxAEAAOABCAEMANAAyADIANwA1ADEANAA2AEMARwBE AEAANQA2ADMAOAA3AEMANgAxAEAANABFAEMAMAA7ADAARAAxAFoAOwAwAEQANwBHAFYAQABPAEYA XgBZAEgATwAsADAAIQAhAEIASQBIAE8AQABdAFYAMQAxADgAMQAwADYAMwAxADEAMQAxADEAMQAx ADEAMQAxADEAMwA1AEQAOQBHADAAMQA1AEQANwB2AHkAeQB5AHkAIQApAEAASABVACEATQBoAGAA aAByAG4AbwAhAFUAZABsAHEAbQBgAHUAZAAoAC8AZQBuAGIAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAh ACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEAIQAhACEA IQAhACEAIQAhACEAIQAhACEAIQAhACEAMQAhADEAAAAjACLxDAAAAL8BAABgAD8FAAABAAAAEPAE AAAAAAAAAAAAEfAEAAAAAQAAAA8ABPBCAAAAEgAK8AgAAAABBAAAAA4AAFMAC/AeAAAAvwEAABAA ywEAAAAA/wEAAAgABAMJAAAAPwMBAAEAAAAR8AQAAAABAAAAAAAAAMgFAAADBAAAAAAAAAAAAAAB AAAAAQAAAHQgAAAAAP//AwAAAAYAi9PzABAAAQD0zZ4JBgCM0/MAEQABALTNngkGAI3T8wARAAEA NM6eCb4AAAC+AAAAyAAAAMkFAAABAAAAAgAAAAAAAgACAAAAAgDGAAAAzQAAAM0AAADJBQAAAQAB AAAAAAACAAAAAwAAADgAAAACAAAAKoB1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpz bWFydHRhZ3MEgENpdHkAgDkAAAADAAAAKoB1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmlj ZTpzbWFydHRhZ3MFgHBsYWNlAIBCAAAAAQAAACqAdXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpv ZmZpY2U6c21hcnR0YWdzDoBjb3VudHJ5LXJlZ2lvbgCADAAAAQCDAQMAAAAAAwAAAAAAAgAAAAAA AQAAAAAAAAAAAF0AAAB3AAAAEAEAABYBAAAvAQAAMgEAAE4BAABTAQAAJwIAACwCAAA2AgAAOwIA AOYCAACBAwAAgwMAAIYDAACHAwAAiQMAALkFAAC6BQAAugUAALwFAAC8BQAAvQUAAL0FAAC/BQAA wAUAAMIFAADDBQAAxQUAAMYFAADJBQAABwAFAAcAHAAHABwABwAcAAcAHAAHABwABwADAAcAAwAH AAMABwACAAQABwAEAAIABAAHAAQABwAEAAcABAACAAAAAAABAAAALwAAADAAAABcAAAAXQAAAHYA AACOAgAAgwMAALkFAAC6BQAAugUAALwFAAC8BQAAvQUAAL0FAAC/BQAAwAUAAMIFAADDBQAAxQUA AMYFAADJBQAABwAFAAcABQAHAAUABwADAAcAAgAEAAcABAACAAQABwAEAAcABAAHAAQAAgAAAAAA twAAAL0AAACPAQAAkAEAAOECAACBAwAAjwMAAJADAAATBAAAEwQAAEIEAABHBAAATAQAAN8EAADg BAAAfAUAAKkFAAC3BQAAuAUAALkFAAC6BQAAugUAALwFAAC8BQAAvQUAAL0FAAC/BQAAwAUAAMIF AADDBQAAxQUAAMYFAADJBQAAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQABwAE AAIABAAHAAQAAgAEAAcABAAHAAQABwAEAAIAAAAAAOYCAACBAwAAuQUAALoFAAC6BQAAvAUAALwF AAC9BQAAvQUAAL8FAADABQAAwgUAAMMFAADFBQAAxgUAAMkFAAAHAAMABwACAAQABwAEAAIABAAH AAQABwAEAAcABAACAAAAAADJBQAAODABAwgAAAANkRAAAAABAAAABAAAAAAAAgAcAB3///8oKVY8 /w//D/8P/w//D/8P/w//D/8PAACeKUQBMJSqi/8P/w//D/8P/w//D/8P/w//DxAAWyfCBKhbPi7/ D/8P/w//D/8P/w//D/8P/w8QAAhQpQjWtCwKFQAQABEAEgATABQA/w//D/8PAAANDVwLXBm2vP8P /w//D/8P/w//D/8P/w//DxAA4irPE06eSrv/D/8P/w//D/8P/w//D/8P/w8QAJhthRTCcvw9/w// D/8P/w//D/8P/w//D/8PEAC6fM0W5v7Klf8P/w//D/8P/w//D/8P/w//DxAAOVvOGJ79bNL/D/8P /w//D/8P/w//D/8P/w8QABRU9xm4SSqb/w//D/8P/w//D/8P/w//D/8PEAANF3YgXMDqJ/8P/w// D/8P/w//D/8P/w//DxAADT7MIZYyeGv/D/8P/w//D/8P/w//D/8P/w8QAH93Dif0BcYk/w//D/8P /w//D/8P/w//D/8PEAAXGck1bAMQiv8P/w//D/8P/w//D/8P/w//DxAABXx0OOLyAhz/D/8P/w// D/8P/w//D/8P/w8QALoiyTnKb1b6/w//D/8P/w//D/8P/w//D/8PEAD6d7FB7MewHv8P/w//D/8P /w//D/8P/w//DxAA3mwVRWK/7r//D/8P/w//D/8P/w//D/8P/w8QAHI60EuejJ7r/w//D/8P/w// D/8P/w//D/8PEAAsFWZQbPSUoP8P/w//D/8P/w//D/8P/w//DxAAJEKuVdhauCL/D/8P/w//D/8P /w//D/8P/w8QAMgm/1renWIV/w//D/8P/w//D/8P/w//D/8PEAAeXv5b/GsE6P8P/w//D/8P/w// D/8P/w//DxAAATUpZNqYwi//D/8P/w//D/8P/w//D/8P/w8QANVHhGmAxgDt/w//D/8P/w//D/8P /w//D/8PEACVJXBtJQAJBAEAAgADAAQABQAGAAcACAAJAAAAiz7jbu4JFr7/D/8P/w//D/8P/w// D/8P/w8QAFoEfHQeLRBs/w//D/8P/w//D/8P/w//D/8PEAABAAAAFwAAAAAAAAAAAAAAAAAAAAAA AAALGAAAD4QAABGEAAAVxgUAAQAABl6EAABghAAAT0oBAFFKAQBvKAAAAAEAAAAXAAAAAAAAAAAA AAAAAAAAAAAAAAsYAAAPhDgEEYSY/hXGBQAB0AIGXoQ4BGCEmP5PSgEAUUoBAG8oAAEAt/ABAAAA FwAAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4QIBxGEmP4VxgUAAaAFBl6ECAdghJj+T0oJAFFKCQBe SgkAbygAAQBvAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhNgJEYSY/hXGBQABcAgGXoTY CWCEmP5PSgoAUUoKAG8oAAEAp/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SoDBGEmP4V xgUAAUALBl6EqAxghJj+T0oKAFFKCgBvKAABAPrwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgA AA+EeA8RhJj+FcYFAAEQDgZehHgPYISY/k9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAA AAAAAAAAAA8YAAAPhEgSEYSY/hXGBQAB4BAGXoRIEmCEmP5PSgkAUUoJAF5KCQBvKAABAG8AAQAA ABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EGBURhJj+FcYFAAGwEwZehBgVYISY/k9KCgBRSgoA bygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhOgXEYSY/hXGBQABgBYGXoToF2CE mP5PSgoAUUoKAG8oAAEA+vABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RoARGEmP4VxgUA AWgBBl6EaAFghJj+T0oCAFFKAgBvKAABACIgAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E OAQRhJj+FcYFAAE4BAZehDgEYISY/k9KAgBRSgIAbygAAQAiIAEAAAAXgAAAAAAAAAAAAAAAAAAA AAAAAAsYAAAPhAgHEYSY/hXGBQABCAcGXoQIB2CEmP5PSgIAUUoCAG8oAAEAIiABAAAAF4AAAAAA AAAAAAAAAAAAAAAAAAALGAAAD4TYCRGEmP4VxgUAAdgJBl6E2AlghJj+T0oCAFFKAgBvKAABACIg AQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EqAwRhJj+FcYFAAGoDAZehKgMYISY/k9KAgBR SgIAbygAAQAiIAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhHgPEYSY/hXGBQABeA8GXoR4 D2CEmP5PSgIAUUoCAG8oAAEAIiABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RIEhGEmP4V xgUAAUgSBl6ESBJghJj+T0oCAFFKAgBvKAABACIgAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgA AA+EGBURhJj+FcYFAAEYFQZehBgVYISY/k9KAgBRSgIAbygAAQAiIAEAAAAXgAAAAAAAAAAAAAAA AAAAAAAAAAsYAAAPhOgXEYSY/hXGBQAB6BcGXoToF2CEmP5PSgIAUUoCAG8oAAEAIiABAAAAFwAA AAAAAAAAAAAAAAAAAAAAAAALGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+T0oCAFFKAgBvKAAB ACIgAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EOAQRhJj+FcYFAAE4BAZehDgEYISY/k9K AgBRSgIAbygAAQAiIAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhAgHEYSY/hXGBQABCAcG XoQIB2CEmP5PSgIAUUoCAG8oAAEAIiABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4TYCRGE mP4VxgUAAdgJBl6E2AlghJj+T0oCAFFKAgBvKAABACIgAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAA CxgAAA+EqAwRhJj+FcYFAAGoDAZehKgMYISY/k9KAgBRSgIAbygAAQAiIAEAAAAXgAAAAAAAAAAA AAAAAAAAAAAAAAsYAAAPhHgPEYSY/hXGBQABeA8GXoR4D2CEmP5PSgIAUUoCAG8oAAEAIiABAAAA F4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RIEhGEmP4VxgUAAUgSBl6ESBJghJj+T0oCAFFKAgBv KAABACIgAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EGBURhJj+FcYFAAEYFQZehBgVYISY /k9KAgBRSgIAbygAAQAiIAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhOgXEYSY/hXGBQAB 6BcGXoToF2CEmP5PSgIAUUoCAG8oAAEAIiABAAAAAwAHAAAAAAAAAAACAAAAAAAAAAAVEAAAD4QA ABGEAABehAAAYIQAADUIATYIAENKHABPSgIAUUoCAG8oAAcAQQBuAG4AZQB4AKAAAAABAAAAAAAB AwAAAAAAAAAAAAAAAAAAAAAGGAAAD4QAABGEAAAVxgUAAWgBBl6EAABghAAANQgBNggAAwAAAC4A AQABAAAAAAABAwUAAAAAAAAAAAAAAAAAAAAtGAAAD4QAABGEAAAVxgUAAdACBl6EAABghAAANQgB NggAR8okQ0oWAE9KAQBQSgsAUUoBAHNICQh0SBEEXkoBAGFKFgBfSAEEBQAAAC4AAQAuAAIAAQAA AAAAAQMFBwAAAAAAAAAAAAAAAAAABhgAAA+EAAARhAAAFcYFAAE4BAZehAAAYIQAADUIATYIAAcA AAAuAAEALgACAC4AAwABAAAAAAABAwUHCQAAAAAAAAAAAAAAAAAGGAAAD4QAABGEAAAVxgUAATgE Bl6EAABghAAANQgBNggACQAAAC4AAQAuAAIALgADAC4ABAABAAAAAAABAwUHCQsAAAAAAAAAAAAA AAAGGAAAD4QAABGEAAAVxgUAAaAFBl6EAABghAAANQgBNggACwAAAC4AAQAuAAIALgADAC4ABAAu AAUAAQAAAAIAAgAAAAAAAAAAAAAAAAAAAAAAABgAAA+E4BARhAAAFcYFAAGwEwZehOAQYIQAAAMA KAAGACkAAQAAAAQAAgAAAAAAAAAAAAAAAAAAAAAAABgAAA+EsBMRhAAAFcYFAAEYFQZehLATYIQA AAMAKAAHACkAAQAAAAIAAgAAAAAAAAAAAAAAAAAAAAAAABgAAA+EgBYRhAAAFcYFAAHoFwZehIAW YIQAAAMAKAAIACkAAQAAAAAQAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EaAERhJj+FcYFAAFoAQZe hGgBYISY/odoAAAAAIhIAAACAAAALgABAAAABJABAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4SgBRGE mP4VxgUAAaAFBl6EoAVghJj+h2gAAAAAiEgAAAIAAQAuAAEAAAACkgEAAAAAAAAAAAAAAAAAAAAA AAoYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP+HaAAAAACISAAAAgACAC4AAQAAAACQAQAAAAAA AAAAAAAAAAAAAAAAChgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/odoAAAAAIhIAAACAAMALgAB AAAABJABAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+h2gAAAAA iEgAAAIABAAuAAEAAAACkgEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhOAQEYRM/xXGBQAB4BAGXoTg EGCETP+HaAAAAACISAAAAgAFAC4AAQAAAACQAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EsBMRhJj+ FcYFAAGwEwZehLATYISY/odoAAAAAIhIAAACAAYALgABAAAABJABAAAAAAAAAAAAAAAAAAAAAAAK GAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+h2gAAAAAiEgAAAIABwAuAAEAAAACkgEAAAAAAAAA AAAAAAAAAAAAAAoYAAAPhFAZEYRM/xXGBQABUBkGXoRQGWCETP+HaAAAAACISAAAAgAIAC4AAQAA ABcQAAAAAAAAAAAAAGgBAAAAAAAAFRAAAA+E0AIRhJj+XoTQAmCEmP5PSgEAUUoBAG8oAIdoAAAA AIhIAAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAGRAAAA+EoAURhJj+XoSgBWCEmP5PSgkA UUoJAF5KCQBvKACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhHAI EYSY/l6EcAhghJj+T0oKAFFKCgBvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAA AAAAABUQAAAPhEALEYSY/l6EQAtghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXkAAA AAAAAAAAAABoAQAAAAAAABkQAAAPhBAOEYSY/l6EEA5ghJj+T0oJAFFKCQBeSgkAbygAh2gAAAAA iEgAAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4TgEBGEmP5ehOAQYISY/k9KCgBR SgoAbygAh2gAAAAAiEgAAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4SwExGEmP5e hLATYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZ EAAAD4SAFhGEmP5ehIAWYISY/k9KCQBRSgkAXkoJAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAA AAAAAAAAAGgBAAAAAAAAFRAAAA+EUBkRhJj+XoRQGWCEmP5PSgoAUUoKAG8oAIdoAAAAAIhIAAAB AKfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY/k9K AgBRSgIAbygAAQAiIAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhDgEEYSY/hXGBQABOAQG XoQ4BGCEmP5PSgIAUUoCAG8oAAEAIiABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4QIBxGE mP4VxgUAAQgHBl6ECAdghJj+T0oCAFFKAgBvKAABACIgAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAA CxgAAA+E2AkRhJj+FcYFAAHYCQZehNgJYISY/k9KAgBRSgIAbygAAQAiIAEAAAAXgAAAAAAAAAAA AAAAAAAAAAAAAAsYAAAPhKgMEYSY/hXGBQABqAwGXoSoDGCEmP5PSgIAUUoCAG8oAAEAIiABAAAA F4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4R4DxGEmP4VxgUAAXgPBl6EeA9ghJj+T0oCAFFKAgBv KAABACIgAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+ESBIRhJj+FcYFAAFIEgZehEgSYISY /k9KAgBRSgIAbygAAQAiIAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhBgVEYSY/hXGBQAB GBUGXoQYFWCEmP5PSgIAUUoCAG8oAAEAIiABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4To FxGEmP4VxgUAAegXBl6E6BdghJj+T0oCAFFKAgBvKAABACIgAQAAABcAAAAAAAAAAAAAAAAAAAAA AAAACxgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY/k9KAgBRSgIAbygAAQAiIAEAAAAXgAAAAAAA AAAAAAAAAAAAAAAAAAsYAAAPhDgEEYSY/hXGBQABOAQGXoQ4BGCEmP5PSgIAUUoCAG8oAAEAIiAB AAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4QIBxGEmP4VxgUAAQgHBl6ECAdghJj+T0oCAFFK AgBvKAABACIgAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E2AkRhJj+FcYFAAHYCQZehNgJ YISY/k9KAgBRSgIAbygAAQAiIAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhKgMEYSY/hXG BQABqAwGXoSoDGCEmP5PSgIAUUoCAG8oAAEAIiABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAA D4R4DxGEmP4VxgUAAXgPBl6EeA9ghJj+T0oCAFFKAgBvKAABACIgAQAAABeAAAAAAAAAAAAAAAAA AAAAAAAACxgAAA+ESBIRhJj+FcYFAAFIEgZehEgSYISY/k9KAgBRSgIAbygAAQAiIAEAAAAXgAAA AAAAAAAAAAAAAAAAAAAAAAsYAAAPhBgVEYSY/hXGBQABGBUGXoQYFWCEmP5PSgIAUUoCAG8oAAEA IiABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4ToFxGEmP4VxgUAAegXBl6E6BdghJj+T0oC AFFKAgBvKAABACIgAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EaAERhJj+FcYFAAFoAQZe hGgBYISY/k9KAgBRSgIAbygAAQAiIAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhDgEEYSY /hXGBQABOAQGXoQ4BGCEmP5PSgIAUUoCAG8oAAEAIiABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAL GAAAD4QIBxGEmP4VxgUAAQgHBl6ECAdghJj+T0oCAFFKAgBvKAABACIgAQAAABeAAAAAAAAAAAAA AAAAAAAAAAAACxgAAA+E2AkRhJj+FcYFAAHYCQZehNgJYISY/k9KAgBRSgIAbygAAQAiIAEAAAAX gAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhKgMEYSY/hXGBQABqAwGXoSoDGCEmP5PSgIAUUoCAG8o AAEAIiABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4R4DxGEmP4VxgUAAXgPBl6EeA9ghJj+ T0oCAFFKAgBvKAABACIgAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+ESBIRhJj+FcYFAAFI EgZehEgSYISY/k9KAgBRSgIAbygAAQAiIAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhBgV EYSY/hXGBQABGBUGXoQYFWCEmP5PSgIAUUoCAG8oAAEAIiABAAAAF4AAAAAAAAAAAAAAAAAAAAAA AAALGAAAD4ToFxGEmP4VxgUAAegXBl6E6BdghJj+T0oCAFFKAgBvKAABACIgAQAAABcQAAAAAAAA AAAAAGgBAAAAAAAAFRAAAA+E0AIRhJj+XoTQAmCEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfw AQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAGRAAAA+EoAURhJj+XoSgBWCEmP5PSgkAUUoJAF5KCQBv KACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhHAIEYSY/l6EcAhg hJj+T0oKAFFKCgBvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAP hEALEYSY/l6EQAtghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABo AQAAAAAAABkQAAAPhBAOEYSY/l6EEA5ghJj+T0oJAFFKCQBeSgkAbygAh2gAAAAAiEgAAAEAbwAB AAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4TgEBGEmP5ehOAQYISY/k9KCgBRSgoAbygAh2gA AAAAiEgAAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4SwExGEmP5ehLATYISY/k9K AQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZEAAAD4SAFhGE mP5ehIAWYISY/k9KCQBRSgkAXkoJAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAGgB AAAAAAAAFRAAAA+EUBkRhJj+XoRQGWCEmP5PSgoAUUoKAG8oAIdoAAAAAIhIAAABAKfwAQAAAAAQ AQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY/odoAAAAAIhIAAAC AAAALgABAAAABBABAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+ h2gAAAAAiEgAAAIAAQAuAAEAAAACkgEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhHAIEYRM/xXGBQAB cAgGXoRwCGCETP+HaAAAAACISAAAAgACAC4AAQAAAACQAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+E QAsRhJj+FcYFAAFACwZehEALYISY/odoAAAAAIhIAAACAAMALgABAAAABJABAAAAAAAAAAAAAAAA AAAAAAAKGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+h2gAAAAAiEgAAAIABAAuAAEAAAACkgEA AAAAAAAAAAAAAAAAAAAAAAoYAAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCETP+HaAAAAACISAAAAgAF AC4AAQAAAACQAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/odo AAAAAIhIAAACAAYALgABAAAABJABAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4SAFhGEmP4VxgUAAYAW Bl6EgBZghJj+h2gAAAAAiEgAAAIABwAuAAEAAAACkgEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhFAZ EYRM/xXGBQABUBkGXoRQGWCETP+HaAAAAACISAAAAgAIAC4AAQAAABcAAAAAAAAAAAAAAAAAAAAA AAAACxgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/k9KAgBRSgIAbygAAQAiIAEAAAAXgAAAAAAA AAAAAAAAAAAAAAAAAAsYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP5PSgIAUUoCAG8oAAEAIiAB AAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+T0oCAFFK AgBvKAABACIgAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EQAsRhJj+FcYFAAFACwZehEAL YISY/k9KAgBRSgIAbygAAQAiIAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhBAOEYSY/hXG BQABEA4GXoQQDmCEmP5PSgIAUUoCAG8oAAEAIiABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAA D4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+T0oCAFFKAgBvKAABACIgAQAAABeAAAAAAAAAAAAAAAAA AAAAAAAACxgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/k9KAgBRSgIAbygAAQAiIAEAAAAXgAAA AAAAAAAAAAAAAAAAAAAAAAsYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP5PSgIAUUoCAG8oAAEA IiABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+T0oC AFFKAgBvKAABACIgAQAAAAAQAQAAAAAAAAAAAGgBAAAAAAAAChAAAA+EaAERhJj+XoRoAWCEmP6H aAAAAACISAAAAgAAAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAChAAAA+EOAQRhJj+XoQ4BGCE mP6HaAAAAACISAAAAgABAC4AAQAAAAKSAQAAAAAAAAAAAGgBAAAAAAAAChAAAA+ECAcRhEz/XoQI B2CETP+HaAAAAACISAAAAgACAC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAChAAAA+E2AkRhJj+ XoTYCWCEmP6HaAAAAACISAAAAgADAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAChAAAA+EqAwR hJj+XoSoDGCEmP6HaAAAAACISAAAAgAEAC4AAQAAAAKSAQAAAAAAAAAAAGgBAAAAAAAAChAAAA+E eA8RhEz/XoR4D2CETP+HaAAAAACISAAAAgAFAC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAChAA AA+ESBIRhJj+XoRIEmCEmP6HaAAAAACISAAAAgAGAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAA ChAAAA+EGBURhJj+XoQYFWCEmP6HaAAAAACISAAAAgAHAC4AAQAAAAKSAQAAAAAAAAAAAGgBAAAA AAAAChAAAA+E6BcRhEz/XoToF2CETP+HaAAAAACISAAAAgAIAC4AAQAAABcQAAAAAAAAAAAAAGgB AAAAAAAAFRAAAA+E0AIRhJj+XoTQAmCEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeQ AAAAAAAAAAAAAGgBAAAAAAAAGRAAAA+EoAURhJj+XoSgBWCEmP5PSgkAUUoJAF5KCQBvKACHaAAA AACISAAAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhHAIEYSY/l6EcAhghJj+T0oK AFFKCgBvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhEALEYSY /l6EQAtghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAA ABkQAAAPhBAOEYSY/l6EEA5ghJj+T0oJAFFKCQBeSgkAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AA AAAAAAAAAAAAaAEAAAAAAAAVEAAAD4TgEBGEmP5ehOAQYISY/k9KCgBRSgoAbygAh2gAAAAAiEgA AAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4SwExGEmP5ehLATYISY/k9KAQBRSgEA bygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZEAAAD4SAFhGEmP5ehIAW YISY/k9KCQBRSgkAXkoJAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAA FRAAAA+EUBkRhJj+XoRQGWCEmP5PSgoAUUoKAG8oAIdoAAAAAIhIAAABAKfwAQAAABcAAAAAAAAA AAAAAAAAAAAAAAAAFRAAAA+EoAURhJj+XoSgBWCEmP5PSgoAUUoKAG8oAIdoAAAAAIhIAAABAJ/w AQAAABcAAAAAAAAAAAAAAAAAAAAAAAAAGRAAAA+EcAgRhJj+XoRwCGCEmP5PSgkAUUoJAF5KAABv KACHaAAAAACISAAAAQBvAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhHAIEYSY/hXGBQAB cAgGXoRwCGCEmP6HaAAAAACISAAAAgACAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+E QAsRhJj+FcYFAAFACwZehEALYISY/odoAAAAAIhIAAACAAMALgABAAAAAAABAAAAAAAAAAAAAAAA AAAAAAAKGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+h2gAAAAAiEgAAAIABAAuAAEAAAAAAAEA AAAAAAAAAAAAAAAAAAAAAAoYAAAPhOAQEYSY/hXGBQAB4BAGXoTgEGCEmP6HaAAAAACISAAAAgAF AC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/odo AAAAAIhIAAACAAYALgABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4SAFhGEmP4VxgUAAYAW Bl6EgBZghJj+h2gAAAAAiEgAAAIABwAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhFAZ EYSY/hXGBQABUBkGXoRQGWCEmP6HaAAAAACISAAAAgAIAC4AAQAAABcAAAAAAAAAAAAAAAAAAAAA AAAACxgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY/k9KAgBRSgIAbygAAQAiIAEAAAAXgAAAAAAA AAAAAAAAAAAAAAAAAAsYAAAPhDgEEYSY/hXGBQABOAQGXoQ4BGCEmP5PSgIAUUoCAG8oAAEAIiAB AAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4QIBxGEmP4VxgUAAQgHBl6ECAdghJj+T0oCAFFK AgBvKAABACIgAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E2AkRhJj+FcYFAAHYCQZehNgJ YISY/k9KAgBRSgIAbygAAQAiIAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhKgMEYSY/hXG BQABqAwGXoSoDGCEmP5PSgIAUUoCAG8oAAEAIiABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAA D4R4DxGEmP4VxgUAAXgPBl6EeA9ghJj+T0oCAFFKAgBvKAABACIgAQAAABeAAAAAAAAAAAAAAAAA AAAAAAAACxgAAA+ESBIRhJj+FcYFAAFIEgZehEgSYISY/k9KAgBRSgIAbygAAQAiIAEAAAAXgAAA AAAAAAAAAAAAAAAAAAAAAAsYAAAPhBgVEYSY/hXGBQABGBUGXoQYFWCEmP5PSgIAUUoCAG8oAAEA IiABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4ToFxGEmP4VxgUAAegXBl6E6BdghJj+T0oC AFFKAgBvKAABACIgAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EaAERhJj+FcYFAAFoAQZe hGgBYISY/k9KAgBRSgIAbygAAQAiIAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhDgEEYSY /hXGBQABOAQGXoQ4BGCEmP5PSgIAUUoCAG8oAAEAIiABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAL GAAAD4QIBxGEmP4VxgUAAQgHBl6ECAdghJj+T0oCAFFKAgBvKAABACIgAQAAABeAAAAAAAAAAAAA AAAAAAAAAAAACxgAAA+E2AkRhJj+FcYFAAHYCQZehNgJYISY/k9KAgBRSgIAbygAAQAiIAEAAAAX gAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhKgMEYSY/hXGBQABqAwGXoSoDGCEmP5PSgIAUUoCAG8o AAEAIiABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4R4DxGEmP4VxgUAAXgPBl6EeA9ghJj+ T0oCAFFKAgBvKAABACIgAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+ESBIRhJj+FcYFAAFI EgZehEgSYISY/k9KAgBRSgIAbygAAQAiIAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhBgV EYSY/hXGBQABGBUGXoQYFWCEmP5PSgIAUUoCAG8oAAEAIiABAAAAF4AAAAAAAAAAAAAAAAAAAAAA AAALGAAAD4ToFxGEmP4VxgUAAegXBl6E6BdghJj+T0oCAFFKAgBvKAABACIgAQAAABcAAAAAAAAA AAAAAAAAAAAAAAAACxgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY/k9KAgBRSgIAbygAAQAiIAEA AAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhDgEEYSY/hXGBQABOAQGXoQ4BGCEmP5PSgIAUUoC AG8oAAEAIiABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4QIBxGEmP4VxgUAAQgHBl6ECAdg hJj+T0oCAFFKAgBvKAABACIgAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E2AkRhJj+FcYF AAHYCQZehNgJYISY/k9KAgBRSgIAbygAAQAiIAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAP hKgMEYSY/hXGBQABqAwGXoSoDGCEmP5PSgIAUUoCAG8oAAEAIiABAAAAF4AAAAAAAAAAAAAAAAAA AAAAAAALGAAAD4R4DxGEmP4VxgUAAXgPBl6EeA9ghJj+T0oCAFFKAgBvKAABACIgAQAAABeAAAAA AAAAAAAAAAAAAAAAAAAACxgAAA+ESBIRhJj+FcYFAAFIEgZehEgSYISY/k9KAgBRSgIAbygAAQAi IAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhBgVEYSY/hXGBQABGBUGXoQYFWCEmP5PSgIA UUoCAG8oAAEAIiABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4ToFxGEmP4VxgUAAegXBl6E 6BdghJj+T0oCAFFKAgBvKAABACIgAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EaAERhJj+ FcYFAAFoAQZehGgBYISY/k9KAgBRSgIAbygAAQAiIAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsY AAAPhDgEEYSY/hXGBQABOAQGXoQ4BGCEmP5PSgIAUUoCAG8oAAEAIiABAAAAF4AAAAAAAAAAAAAA AAAAAAAAAAALGAAAD4QIBxGEmP4VxgUAAQgHBl6ECAdghJj+T0oCAFFKAgBvKAABACIgAQAAABeA AAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E2AkRhJj+FcYFAAHYCQZehNgJYISY/k9KAgBRSgIAbygA AQAiIAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhKgMEYSY/hXGBQABqAwGXoSoDGCEmP5P SgIAUUoCAG8oAAEAIiABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4R4DxGEmP4VxgUAAXgP Bl6EeA9ghJj+T0oCAFFKAgBvKAABACIgAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+ESBIR hJj+FcYFAAFIEgZehEgSYISY/k9KAgBRSgIAbygAAQAiIAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAA AAsYAAAPhBgVEYSY/hXGBQABGBUGXoQYFWCEmP5PSgIAUUoCAG8oAAEAIiABAAAAF4AAAAAAAAAA AAAAAAAAAAAAAAALGAAAD4ToFxGEmP4VxgUAAegXBl6E6BdghJj+T0oCAFFKAgBvKAABACIgAQAA AAQAAgAAAAAAAAAAAAAAAAAAAAAAAxAAAA+EgwQRhJj+XoSDBGCEmP5vKAADACgAAAApAAEAAAAD gAEAAAAAAAAAAAAAAAAAAAAAAAoQAAAPhDsGEYRw/l6EOwZghHD+h2gAAAAAiEgAAAIAAQAuAAEA AAACggEAAAAAAAAAAAAAAAAAAAAAAAoQAAAPhMsHEYRw/l6EywdghHD+h2gAAAAAiEgAAAIAAgAu AAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAoQAAAPhFsJEYRw/l6EWwlghHD+h2gAAAAAiEgAAAIA AwAuAAEAAAADgAEAAAAAAAAAAAAAAAAAAAAAAAoQAAAPhOsKEYRw/l6E6wpghHD+h2gAAAAAiEgA AAIABAAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAoQAAAPhHsMEYRw/l6EewxghHD+h2gAAAAA iEgAAAIABQAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAoQAAAPhAsOEYRw/l6ECw5ghHD+h2gA AAAAiEgAAAIABgAuAAEAAAADgAEAAAAAAAAAAAAAAAAAAAAAAAoQAAAPhJsPEYRw/l6Emw9ghHD+ h2gAAAAAiEgAAAIABwAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAoQAAAPhCsREYRw/l6EKxFg hHD+h2gAAAAAiEgAAAIACAAuAAEAAAAXEAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhNACEYSY/l6E 0AJghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABkQ AAAPhKAFEYSY/l6EoAVghJj+T0oJAFFKCQBeSgkAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAA AAAAAAAAaAEAAAAAAAAVEAAAD4RwCBGEmP5ehHAIYISY/k9KCgBRSgoAbygAh2gAAAAAiEgAAAEA p/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4RACxGEmP5ehEALYISY/k9KAQBRSgEAbygA h2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZEAAAD4QQDhGEmP5ehBAOYISY /k9KCQBRSgkAXkoJAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRAA AA+E4BARhJj+XoTgEGCEmP5PSgoAUUoKAG8oAIdoAAAAAIhIAAABAKfwAQAAABeQAAAAAAAAAAAA AGgBAAAAAAAAFRAAAA+EsBMRhJj+XoSwE2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAA ABeQAAAAAAAAAAAAAGgBAAAAAAAAGRAAAA+EgBYRhJj+XoSAFmCEmP5PSgkAUUoJAF5KCQBvKACH aAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhFAZEYSY/l6EUBlghJj+ T0oKAFFKCgBvKACHaAAAAACISAAAAQCn8AEAAAAAEAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhGgB EYSY/hXGBQABaAEGXoRoAWCEmP6HaAAAAACISAAAAgAAAC4AAQAAAASQAQAAAAAAAAAAAAAAAAAA AAAAChgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/odoAAAAAIhIAAACAAEALgABAAAAApIBAAAA AAAAAAAAAAAAAAAAAAAKGAAAD4RwCBGETP8VxgUAAXAIBl6EcAhghEz/h2gAAAAAiEgAAAIAAgAu AAEAAAAAkAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP6HaAAA AACISAAAAgADAC4AAQAAAASQAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EEA4RhJj+FcYFAAEQDgZe hBAOYISY/odoAAAAAIhIAAACAAQALgABAAAAApIBAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4TgEBGE TP8VxgUAAeAQBl6E4BBghEz/h2gAAAAAiEgAAAIABQAuAAEAAAAAkAEAAAAAAAAAAAAAAAAAAAAA AAoYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP6HaAAAAACISAAAAgAGAC4AAQAAAASQAQAAAAAA AAAAAAAAAAAAAAAAChgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/odoAAAAAIhIAAACAAcALgAB AAAAApIBAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4RQGRGETP8VxgUAAVAZBl6EUBlghEz/h2gAAAAA iEgAAAIACAAuAAEAAAAAEAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhGgBEYSY/hXGBQABaAEGXoRo AWCEmP6HaAAAAACISAAAAgAAAC4AAQAAAASQAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EoAURhJj+ FcYFAAGgBQZehKAFYISY/odoAAAAAIhIAAACAAEALgABAAAAApIBAAAAAAAAAAAAAAAAAAAAAAAK GAAAD4RwCBGETP8VxgUAAXAIBl6EcAhghEz/h2gAAAAAiEgAAAIAAgAuAAEAAAAAkAEAAAAAAAAA AAAAAAAAAAAAAAoYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP6HaAAAAACISAAAAgADAC4AAQAA AASQAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/odoAAAAAIhI AAACAAQALgABAAAAApIBAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4TgEBGETP8VxgUAAeAQBl6E4BBg hEz/h2gAAAAAiEgAAAIABQAuAAEAAAAAkAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhLATEYSY/hXG BQABsBMGXoSwE2CEmP6HaAAAAACISAAAAgAGAC4AAQAAAASQAQAAAAAAAAAAAAAAAAAAAAAAChgA AA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/odoAAAAAIhIAAACAAcALgABAAAAApIBAAAAAAAAAAAA AAAAAAAAAAAKGAAAD4RQGRGETP8VxgUAAVAZBl6EUBlghEz/h2gAAAAAiEgAAAIACAAuAAEAAAAX AAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP5PSgIAUUoCAG8o AAEAIiABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4Q4BBGEmP4VxgUAATgEBl6EOARghJj+ T0oCAFFKAgBvKAABACIgAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+ECAcRhJj+FcYFAAEI BwZehAgHYISY/k9KAgBRSgIAbygAAQAiIAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhNgJ EYSY/hXGBQAB2AkGXoTYCWCEmP5PSgIAUUoCAG8oAAEAIiABAAAAF4AAAAAAAAAAAAAAAAAAAAAA AAALGAAAD4SoDBGEmP4VxgUAAagMBl6EqAxghJj+T0oCAFFKAgBvKAABACIgAQAAABeAAAAAAAAA AAAAAAAAAAAAAAAACxgAAA+EeA8RhJj+FcYFAAF4DwZehHgPYISY/k9KAgBRSgIAbygAAQAiIAEA AAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhEgSEYSY/hXGBQABSBIGXoRIEmCEmP5PSgIAUUoC AG8oAAEAIiABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4QYFRGEmP4VxgUAARgVBl6EGBVg hJj+T0oCAFFKAgBvKAABACIgAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E6BcRhJj+FcYF AAHoFwZehOgXYISY/k9KAgBRSgIAbygAAQAiIAEAAAAXEAAAAAAAAAAAAABoAQAAAAAAABUQAAAP hNACEYSY/l6E0AJghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXEAAAAAAAAAAAAABo AQAAAAAAABkQAAAPhKAFEYSY/l6EoAVghJj+T0oJAFFKCQBeSgIAbygAh2gAAAAAiEgAAAEAbwAB AAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4RwCBGEmP5ehHAIYISY/k9KCgBRSgoAbygAh2gA AAAAiEgAAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4RACxGEmP5ehEALYISY/k9K AQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZEAAAD4QQDhGE mP5ehBAOYISY/k9KCQBRSgkAXkoCAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAGgB AAAAAAAAFRAAAA+E4BARhJj+XoTgEGCEmP5PSgoAUUoKAG8oAIdoAAAAAIhIAAABAKfwAQAAABeQ AAAAAAAAAAAAAGgBAAAAAAAAFRAAAA+EsBMRhJj+XoSwE2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhI AAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAGRAAAA+EgBYRhJj+XoSAFmCEmP5PSgkAUUoJ AF5KAgBvKACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhFAZEYSY /l6EUBlghJj+T0oKAFFKCgBvKACHaAAAAACISAAAAQCn8AEAAAAAEAEAAAAAAAAAAAAAAAAAAAAA AAoYAAAPhLABEYRQ/hXGBQABsAEGXoSwAWCEUP6HaAAAAACISAAAAQAAAAEAAAAAEAEDAAAAAAAA AAAAAAAAAAAAAAoYAAAPhEACEYTA/RXGBQABQAIGXoRAAmCEwP2HaAAAAACISAAAAwAAAC4AAQAB AAAAABABAwUAAAAAAAAAAAAAAAAAAAAKGAAAD4TQAhGEMP0VxgUAAdACBl6E0AJghDD9h2gAAAAA iEgAAAUAAAAuAAEALgACAAEAAAAAEAEDBQcAAAAAAAAAAAAAAAAAAAoYAAAPhGADEYSg/BXGBQAB YAMGXoRgA2CEoPyHaAAAAACISAAABwAAAC4AAQAuAAIALgADAAEAAAAAEAEDBQcJAAAAAAAAAAAA AAAAAAoYAAAPhPADEYQQ/BXGBQAB8AMGXoTwA2CEEPyHaAAAAACISAAACQAAAC4AAQAuAAIALgAD AC4ABAABAAAAABABAwUHCQsAAAAAAAAAAAAAAAAKGAAAD4SABBGEgPsVxgUAAYAEBl6EgARghID7 h2gAAAAAiEgAAAsAAAAuAAEALgACAC4AAwAuAAQALgAFAAEAAAAAEAEDBQcJCw0AAAAAAAAAAAAA AAoYAAAPhBAFEYTw+hXGBQABEAUGXoQQBWCE8PqHaAAAAACISAAADQAAAC4AAQAuAAIALgADAC4A BAAuAAUALgAGAAEAAAAAEAEDBQcJCw0PAAAAAAAAAAAAAAoYAAAPhKAFEYRg+hXGBQABoAUGXoSg BWCEYPqHaAAAAACISAAADwAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwABAAAAABABAwUH CQsNDxEAAAAAAAAAAAAKGAAAD4QwBhGE0PkVxgUAATAGBl6EMAZghND5h2gAAAAAiEgAABEAAAAu AAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAIAAEAAAAAEAEAAAAAAAAAAAAAAAAAAAAAAAoY AAAPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP6HaAAAAACISAAAAgAAAC4AAQAAAAQQAQAAAAAAAAAA AAAAAAAAAAAAChgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/odoAAAAAIhIAAACAAEALgABAAAA ApIBAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4RwCBGETP8VxgUAAXAIBl6EcAhghEz/h2gAAAAAiEgA AAIAAgAuAAEAAAAAkAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CE mP6HaAAAAACISAAAAgADAC4AAQAAAASQAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EEA4RhJj+FcYF AAEQDgZehBAOYISY/odoAAAAAIhIAAACAAQALgABAAAAApIBAAAAAAAAAAAAAAAAAAAAAAAKGAAA D4TgEBGETP8VxgUAAeAQBl6E4BBghEz/h2gAAAAAiEgAAAIABQAuAAEAAAAAkAEAAAAAAAAAAAAA AAAAAAAAAAoYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP6HaAAAAACISAAAAgAGAC4AAQAAAASQ AQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/odoAAAAAIhIAAAC AAcALgABAAAAApIBAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4RQGRGETP8VxgUAAVAZBl6EUBlghEz/ h2gAAAAAiEgAAAIACAAuAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhNACEYSY/hXGBQAB 0AIGXoTQAmCEmP5PSgIAUUoCAG8oAAEAIiABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4Sg BRGEmP4VxgUAAaAFBl6EoAVghJj+T0oCAFFKAgBvKAABACIgAQAAABeAAAAAAAAAAAAAAAAAAAAA AAAACxgAAA+EcAgRhJj+FcYFAAFwCAZehHAIYISY/k9KAgBRSgIAbygAAQAiIAEAAAAXgAAAAAAA AAAAAAAAAAAAAAAAAAsYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5PSgIAUUoCAG8oAAEAIiAB AAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+T0oCAFFK AgBvKAABACIgAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E4BARhJj+FcYFAAHgEAZehOAQ YISY/k9KAgBRSgIAbygAAQAiIAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhLATEYSY/hXG BQABsBMGXoSwE2CEmP5PSgIAUUoCAG8oAAEAIiABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAA D4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+T0oCAFFKAgBvKAABACIgAQAAABeAAAAAAAAAAAAAAAAA AAAAAAAACxgAAA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/k9KAgBRSgIAbygAAQAiIB0AAACVJXBt AAAAAAAAAAAAAAAACFClCAAAAAAAAAAAAAAAAA0NXAsAAAAAAAAAAAAAAAANF3YgAAAAAAAAAAAA AAAAyCb/WgAAAAAAAAAAAAAAAIs+424AAAAAAAAAAAAAAAAeXv5bAAAAAAAAAAAAAAAAf3cOJwAA AAAAAAAAAAAAACwVZlAAAAAAAAAAAAAAAADVR4RpAAAAAAAAAAAAAAAABXx0OAAAAAD4YIMJCQD+ AAV8dDgAAAAAAAAAAAAAAAAXGck1AAAAAAAAAAAAAAAAHf///wAAAAAAAAAAAAAAAFoEfHQAAAAA AAAAAAAAAABbJ8IEAAAAAAAAAAAAAAAAcjrQSwAAAAAAAAAAAAAAAN5sFUUAAAAAAAAAAAAAAAC6 fM0WAAAAAAAAAAAAAAAADT7MIQAAAAAAAAAAAAAAAJ4pRAEAAAAAAAAAAAAAAAA5W84YAAAAAAAA AAAAAAAAmG2FFAAAAAAAAAAAAAAAAAE1KWQAAAAAAAAAAAAAAAC6Isk5AAAAAAAAAAAAAAAA+nex QQAAAAAAAAAAAAAAABRU9xkAAAAAAAAAAAAAAADiKs8TAAAAAAAAAAAAAAAAJEKuVQAAAAAAAAAA AAAAAP//////////////////////////////////////////////////////////AQAAAAAAAAAB AAAAAQAAAAEAAAASAAAAAQAAAJP+yjABAAAAFAAAAAEAAACVPwAAAQAAABYgAAABAAAA19KLBAEA AAAYAIsE//////////////////////////////////////////////////////////////////// //////////////////////////////8cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//xwAAAAAABIA4MXYWNRkBMTYVNaZDrNsbvrt5Ka2 NBRPmHEEvO6QGEyUr257EgDih9ya0k8OUvqpvpFmYyxskMrSzgLf2q8mOToRcLyEt4p8HpYAABIA DwAJBBkACQQbAAkEDwAJBBkACQQbAAkEDwAJBBkACQQbAAkEEgABAAkEAwAJBAUACQQBAAkEAwAJ BAUACQQBAAkEAwAJBAUACQQSAC5E+uh0/p7p7pJ2Q4oCUB0AIhKlXB42v8qiKCrAyD6ioqtUAhIA lJyEWfBu/mD4fWSMYLd4ImCEOHgGHu7RbrPGGCSmlvRml1o5EgBUZ/Qdfqp+XJivujM02vL6Qsv2 sWTGqlJoj0Cb0L+A+voJxCoSAAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBBIA DwAJBBkACQQbAAkEDwAJBBkACQQbAAkEDwAJBBkACQQbAAkEEgAE7mLxGP6+mqC6gpwUjQITgJDW xpaRmhZGBCiTrv+kN+SbWFgSAA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBBIA AQAJBAMACQQFAAkEAQAJBAMACQQFAAkEAQAJBAMACQQFAAkEEgADAAkEAwAJBAUACQQBAAkEAwAJ BAUACQQBAAkEAwAJBAUACQQSALIOmhXEZxg48LaaOA7/FI4MpS6FDoaEZPjtpGv8HqjwVKlQERIA ShJUU7DGwOjEJtLaJNz8lth6DPImm6ghclDIdjCKjnZm9iy7EgDyfEKS9gvSq8ZeVl6yHvglXHFu 2siwrF/cieiQvACSTK4JnpwSAKZ2yv9kPOJgyIyEToIH1HZC9Yh/6ggOago7ZmooHCRAlGr8mBIA 2IZscxkACQQbAAkEDwAJBBkACQQbAAkEDwAJBBkACQQbAAkEEgABAAkEAwAJBAUACQQBAAkEAwAJ BAUACQQBAAkEAwAJBAUACQQSAA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBBIA DwAJBBkACQQbAAkEDwAJBBkACQQbAAkEDwAJBBkACQQbAAkEEgD00f5TMqNgLDgQCGSyjXSLtlVK jujqTsCel+J6ftoMI0JWmpESAAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBAAA EgAPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQSAPbAnmIwIOgTQOmyT+TLnrpW DSqQQi5IHuC3HPJK7Up9sO/g3ngA1HfUAAAAAAAAAAAAAAECAAIAGykbBD50U3cBAAAAAQAEAL4B AADVEqcFAAAAAAAAAAAAAQIAAgBFYCwH5n0WawEAAAABAAQAvgEAAKt9swc+dFN3AQAAAAEABAC+ AQAAm02RCD50U3cBAAAAAQAEAL4BAAAabssJhQ//HAEAAAABAAQAvgEAAHh9MgzmfRZrAQAAAAEA BAC+AQAAbRU0DuZ9FmsBAAAAAQAEAL4BAADlbh0PPnRTdwEAAAABAAQAvgEAAFxlIw/mfRZrAQAA AAEABAC+AQAACxjJEIUP/xwBAAAAAQAEAL4BAAAjC6YThQ//HAEAAAABAAQAvgEAACg5yROFD/8c AQAAAAEABAC+AQAA9hFbFAAAAAAAAAAAAAECAAIAJi57FuZ9FmsBAAAAAQAEAL4BAAAaZJgXPnRT dwEAAAABAAQAvgEAAFlIDBg+dFN3AQAAAAEABAC+AQAApBmHGOZ9FmsBAAAAAQAEAL4BAAC8TcEY AAAAAAAAAAAAAQIAAgBAeTMZPnRTdwEAAAABAAQAvgEAAPtKNRk+dFN3AQAAAAEABAC+AQAAYR9J Gj50U3cBAAAAAQAEAL4BAABOCWIchQ//HAEAAAABAAQAvgEAADJS2BzmfRZrAQAAAAEABAC+AQAA hQ//HAAAAAAAAAAAAAECAAIAHRYGHeZ9FmsBAAAAAQAEAL4BAABBbfQgPnRTdwEAAAABAAQAvgEA ACBPYyMAAAAAAAAAAAABAgACAFZ6tiXmfRZrAQAAAAEABAC+AQAA6jMBJoUP/xwBAAAAAQAEAL4B AABIakImhQ//HAEAAAABAAQAvgEAAAkS1iaFD/8cAQAAAAEABAC+AQAArRZLJz50U3cBAAAAAQAE AL4BAADJJXgphQ//HAEAAAABAAQAvgEAAPxmSSqFD/8cAQAAAAEABAC+AQAA7WQAK+Z9FmsBAAAA AQAEAL4BAAAuOgcwPnRTdwEAAAABAAQAvgEAAOovCTKFD/8cAQAAAAEABAC+AQAA13vrM+Z9FmsB AAAAAQAEAL4BAADWF1M0hQ//HAEAAAABAAQAvgEAAHpUDzjmfRZrAQAAAAEABAC+AQAALBGJOIUP /xwBAAAAAQAEAL4BAABOdz065n0WawEAAAABAAQAvgEAAEc4JTuFD/8cAQAAAAEABAC+AQAADk5Y Oz50U3cBAAAAAQAEAL4BAABSRh09PnRTdwEAAAABAAQAvgEAAMJxkT7mfRZrAQAAAAEABAC+AQAA MT9HPz50U3cBAAAAAQAEAL4BAADGZk9AhQ//HAEAAAABAAQAvgEAAP1bX0OFD/8cAQAAAAEABAC+ AQAAp031Qz50U3cBAAAAAQAEAL4BAADmX3REhQ//HAEAAAABAAQAvgEAAE0PiUQ+dFN3AQAAAAEA BAC+AQAAwUArRYUP/xwBAAAAAQAEAL4BAAAdRi9G5n0WawEAAAABAAQAvgEAAEtC/EfmfRZrAQAA AAEABAC+AQAAeyRLSD50U3cBAAAAAQAEAL4BAAAReUdJ5n0WawEAAAABAAQAvgEAANEV20mFD/8c AQAAAAEABAC+AQAAxWR6SuZ9FmsBAAAAAQAEAL4BAAALQvxL5n0WawEAAAABAAQAvgEAAEV1bE3m fRZrAQAAAAEABAC+AQAAdhtkTj50U3cBAAAAAQAEAL4BAAAVBuZOAAAAAAAAAAAAAQIAAgD7bSdS PnRTdwEAAAABAAQAvgEAAJNfylI+dFN3AQAAAAEABAC+AQAAJGzYUoUP/xwBAAAAAQAEAL4BAACC EeFUhQ//HAEAAAABAAQAvgEAACoEKlU+dFN3AQAAAAEABAC+AQAA0CFoVoUP/xwBAAAAAQAEAL4B AACMCGtWPnRTdwEAAAABAAQAvgEAAFdxEVc+dFN3AQAAAAEABAC+AQAA4AwWWOZ9FmsBAAAAAQAE AL4BAAC2EcdYhQ//HAEAAAABAAQAvgEAAMk+H1k+dFN3AQAAAAEABAC+AQAADSzdWT50U3cBAAAA AQAEAL4BAADoL/haPnRTdwEAAAABAAQAvgEAAMYHD1s+dFN3AQAAAAEABAC+AQAAHSYPW+Z9FmsB AAAAAQAEAL4BAAB2addc5n0WawEAAAABAAQAvgEAALJtA17mfRZrAQAAAAEABAC+AQAApAauXuZ9 FmsBAAAAAQAEAL4BAAAJYnNgPnRTdwEAAAABAAQAvgEAAJw0kGDmfRZrAQAAAAEABAC+AQAAUD1g YgAAAAAAAAAAAAECAAIAFgRyYuZ9FmsBAAAAAQAEAL4BAACfENFjhQ//HAEAAAABAAQAvgEAAN4E NWQ+dFN3AQAAAAEABAC+AQAA9n/PZYUP/xwBAAAAAQAEAL4BAACMX3JmAAAAAAAAAAAAAQIAAgC+ G6tphQ//HAEAAAABAAQAvgEAAAZk7WrmfRZrAQAAAAEABAC+AQAA5n0WawAAAAAAAAAAAAECAAIA +3lza+Z9FmsBAAAAAQAEAL4BAAAbCr1rhQ//HAEAAAABAAQAvgEAAIcAHmw+dFN3AQAAAAEABAC+ AQAAUVojbIUP/xwBAAAAAQAEAL4BAAB7eKNshQ//HAEAAAABAAQAvgEAAIQASG7mfRZrAQAAAAEA BAC+AQAAJiNDb+Z9FmsBAAAAAQAEAL4BAAB3ENZwhQ//HAEAAAABAAQAvgEAAJNWCnHmfRZrAQAA AAEABAC+AQAAclshcT50U3cBAAAAAQAEAL4BAAArWT9xhQ//HAEAAAABAAQAvgEAANx14HHmfRZr AQAAAAEABAC+AQAAuV8Ccz50U3cBAAAAAQAEAL4BAABcU0RzhQ//HAEAAAABAAQAvgEAAHNi3nMA AAAAAAAAAAABAgACAFgW8nU+dFN3AQAAAAEABAC+AQAAOWmsduZ9FmsBAAAAAQAEAL4BAAD+V/h2 5n0WawEAAAABAAQAvgEAAD50U3cAAAAAAAAAAAABAgACAGdOw3eFD/8cAQAAAAEABAC+AQAAV0QH eYUP/xwBAAAAAQAEAL4BAAAEVgp5hQ//HAEAAAABAAQAvgEAAGJBTHzmfRZrAQAAAAEABAC+AQAA ugS4fIUP/xwBAAAAAQAEAL4BAAAFMnh9PnRTdwEAAAABAAQAvgEAABh2tn0+dFN3AQAAAAEABAC+ AQAAcgAAAAQAAAAIAAAA5QAAAAAAAABxAAAAkwgBAPggAQDqJwMAb0cDAMVJAwChLAgA+WwJAMV8 CwAmAwwAeQYMAOkVEQB8NBEAWg8SAAR0FQBJHxgAuhoaAB9RIwDLJSYAzzQqAGcwLQDhNS4Apn4y ALcaNABHLjcAPTM4APcCOQAsFjkABhw5AAsUPQBebj0AmR0/ADZtPwB8F0AAT2BCAJ9BRgAeZkgA eRRJAEBtSQD4JEoAGzBKAHt/TABLWlEAyjZSACYdVACARVUASxFYAK03WgAWZ1oAtGhcAHBvXwCg a2AAHgJiAIYQZADuBWgAFhpoAOtkaQD5JWoAhWRsABYFdwC8QXgAGHp7AHEvfACnUHwA+EF+AORr ggC3FYYApn6MAOQUjgBRVI4A9FeRAIgMkgB6I5IAn1KTAPkvlABvLZcAFkqXAA1BmgALZqQAUwSm AFwaqACXI6gAZzWzABsvvwCyUMEAvE/CAMojxACnb8kAX1/MAE46zQBnVM4ALmHOAEId0ABIG9IA wRnWAIwc2ABRSdgA01fYALN52gAaI9sAQSTcAKpT3ACaKt4AzB/jALoi5wBUQucAK07pAFdw6QDZ FewAmSvvAMBM8QCHDvIAWwT2AMlb+gBjKfsAAAAAAN4AAADfAAAA5gAAAO8AAADwAAAA9gAAAFQB AABVAQAAXAEAAGUBAABmAQAAuQUAAMkFAAAAAAAAEYEtAAgAAAACAQAAAgEAAJ4BAAACAQAAAgEA AJ4BAAACAQAAAgEAAJYBAAABAAAA/0AAgAEAAAAAAAAAAAA4MAEDAQABAAAAAAAAAAAAAAAAAAAA AAACEAAAAAAAAADIBQAAUAAAEABAAAD//wEAAAAHAFUAbgBrAG4AbwB3AG4A//8BAAgAAAAAAAAA AAAAAP//AQAAAAAA//8AAAIA//8AAAAA//8AAAIA//8AAAAACwAAAEcWkAEAAAICBgMFBAUCAwTv OgDgQXgAwAkAAAAAAAAA/wEAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUW kAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEA AAILBgQCAgICAgT/OgDgQ3gAwAkAAAAAAAAA/wEAAAAAAABBAHIAaQBhAGwAAABHFZABgAYCAgYJ BAIFCAME/wIA4Pv9x2oSAAAAAAAAAJ8AAgAAAAAALf8z/yAADmYdZwAATQBTACAATQBpAG4AYwBo AG8AAABDIJABAAgAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAQQByAGkAYQBsAE0A VAAAAEEAcgBpAGEAbAAAAE0GkAFQAwAAAAAAAAAAAAAAAAAAAAAOCBAAAAAAAAAAAAAEAAAAAACL W1NPAABNAGkAYwByAG8AcwBvAGYAdAAgAFkAYQBIAGUAaQAAAG0WkAEAEwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABOAGkAbQBiAHUAcwAgAFIAbwBtAGEAbgAgAE4AbwA5ACAATAAA AFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAATwaQAQAOAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAE4AaQBtAGIAdQBzACAAUwBhAG4AcwAgAEwAAABBAHIAaQBhAGwAAAAz BpABAAAAAAQAAAAAAAAAAwBAAAAAAAAAAAAAAAAAAAEAAAAAAAAAVAB1AG4AZwBhAAAAPzWQAQAA AgcDCQICBQIEBP86AOBDeADACQAAAAAAAAD/AQAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAA ADsGkAECAAUAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABXAGkAbgBnAGQAaQBuAGcA cwAAACIABAAxCIgYAPDQAuQEaAEAAAAAHYQKR3S7CkcAAAAABQABAAAA2gAAAOAEAAABAAIAAAAE AAMQCgAAANoAAADgBAAAAQACAAAACgAAAAAAAABhBADwEAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACKBYoFeAC0AIGCEjQAAAAAAAAAAAAAAAAAALgFAAC4BQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAPECAAAAAAwyg3EA 8BAACAD8/QEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASFgAAAAACfD/DwEAAT8AAOQEAAD///9/ ////f////3////9/////f////3////9/jm5CAAAEAACyAAAAAAAAAAAAAAAAAAAAIQD//xIAAAAA AAAAAQAxAAAAAAAAAAgAbABlAG8AbgBhAHIAZABvAA4AWQBvAGsAbwAgAEgAaQBnAGEAcwBoAGkA ZABhAAAAAAAAAAAAAAAAAAAAAAAAAAAAfAAAAAYAAAAcAAAAAAAMAAEADAACAAwAAwAMAAQADAAF AAwABgAMAAcADAAIAAwACQAMAAoADAALAAwADAAMAA0ADAAOAAwADwAMABAADAARAAwAEgAMABMA DAAUAAwAFQAMABYADAAXAAwAGAAMABkADAAaAAwAGwAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABgACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCr kQgAKyez2TAAAABkAQAAEAAAAAEAAACIAAAAAgAAAJAAAAADAAAAnAAAAAQAAACoAAAABQAAALwA AAAHAAAAyAAAAAgAAADcAAAACQAAAPQAAAASAAAAAAEAAAoAAAAgAQAADAAAACwBAAANAAAAOAEA AA4AAABEAQAADwAAAEwBAAAQAAAAVAEAABMAAABcAQAAAgAAAKQDAAAeAAAABAAAADEAAAAeAAAA BAAAAAAAAAAeAAAADAAAAGxlb25hcmRvAAAAAB4AAAAEAAAAAAAAAB4AAAAMAAAATm9ybWFsLmRv dAAAHgAAABAAAABZb2tvIEhpZ2FzaGlkYQAAHgAAAAQAAAA1AAAAHgAAABgAAABNaWNyb3NvZnQg T2ZmaWNlIFdvcmQAAABAAAAAAEbDIwAAAABAAAAAAAbb6G+rzQFAAAAAAFj9ItqwzQEDAAAAAQAA AAMAAADaAAAAAwAAAOAEAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA/v8AAAYAAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5E AAAABdXN1ZwuGxCTlwgAKyz5rjABAADsAAAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAgAAAAAYA AACIAAAAEQAAAJAAAAAXAAAAmAAAAAsAAACgAAAAEAAAAKgAAAATAAAAsAAAABYAAAC4AAAADQAA AMAAAAAMAAAAzgAAAAIAAACkAwAAHgAAAAgAAABDRURFTwAAAAMAAAAKAAAAAwAAAAIAAAADAAAA uAUAAAMAAAAPJwsACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAAIAAAAx AAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAOgBAAAEAAAAAAAAACgAAAABAAAATgAAAAIA AABWAAAAAwAAANIBAAACAAAAAgAAAAwAAABfUElEX0hMSU5LUwADAAAABgAAAHNmbGFnAAIAAACk AwAAQQAAAHQBAAAMAAAAAwAAAEYAMAADAAAAAwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAPgAAAGgA dAB0AHAAOgAvAC8AbQBwAGUAZwAuAGMAaABpAGEAcgBpAGcAbABpAG8AbgBlAC4AbwByAGcALwBt AGUAZQB0AGkAbgBnAHMALwBkAGEAZQBnAHUAMQAxAC8AZABhAGUAZwB1AF8AcAByAGUAcwBzAC4A aAB0AG0AAAAfAAAAAQAAAAAAPQ0DAAAALgBAAAMAAAAAAAAAAwAAAAAAAAADAAAABQAAAB8AAABG AAAAaAB0AHQAcAA6AC8ALwBtAHAAZQBnAC4AYwBoAGkAYQByAGkAZwBsAGkAbwBuAGUALgBvAHIA ZwAvAHcAbwByAGsAaQBuAGcAXwBkAG8AYwB1AG0AZQBuAHQAcwAvAG0AcABlAGcALQAwADQALwBw AGEAcgB0ADIAOQAvAFcAVgBDAC4AegBpAHAAAAAfAAAAAQAAAAAAPQ0eAAAADAAAADEzNDI2MTk5 NjIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAO AAAADwAAAP7///8RAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAA/v///xkAAAAaAAAAGwAAABwA AAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAA ACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAA OQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYAAABH AAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAAVAAAAFUA AABWAAAAVwAAAFgAAABZAAAAWgAAAFsAAABcAAAA/v///14AAABfAAAAYAAAAGEAAABiAAAAYwAA AGQAAAD+////ZgAAAGcAAABoAAAAaQAAAGoAAABrAAAAbAAAAP7////9////bwAAAP7////+//// /v////////////////////////////////////////////////////////////////////////// ////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAA8Lun KdqwzQFxAAAAgAAAAAAAAABEAGEAdABhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAEAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIBAQAAAAYAAAD/////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAANWJAAAAAAAAVwBvAHIAZABEAG8A YwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEC AAAABQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOB4AAAAA AAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAF0AAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwBy AG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAZQAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///////////////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP// /////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAEAAAD+//////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARhsAAABNaWNyb3NvZnQgT2ZmaWNlIFdvcmQglbaP kQAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --_004_FDBFA77C7400C74F87BC297393B53E3525930387BL2PRD0710MB349_-- From dbenham@cisco.com Wed Oct 24 13:58:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9A421F8A49 for ; Wed, 24 Oct 2012 13:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J63rvxXWnN4V for ; Wed, 24 Oct 2012 13:58:32 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 93A5521F87DC for ; Wed, 24 Oct 2012 13:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2250; q=dns/txt; s=iport; t=1351112312; x=1352321912; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=QBEYgTXCBQJ8LiMg2RIGUJTRZggZgsJqnAdyJaqP0z8=; b=SWSrBsjlz7O4WtYShCm+j5Pi2w0q80C2ps/T71G8ml9gyuOpbNbmFztB b5Rw9Oy9pdY9EcCWOO1ubgZjVuGj9Srv+Uq4TRtcPr7UJxAF45rFOGluH KrtSbMKuTku2+1O6beGxKZt4aXCaJ3BqZJv01cRM287v/AjizwEsfZusr E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKdViFCtJV2Z/2dsb2JhbABEwX2BCIIeAQEBBBIBCmwCAQgOAwQBAQsdBzIUCQgCBAESCBMHh2ILnFugEIthhgxhA4gnhC2FbYRJjTeBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,642,1344211200"; d="scan'208";a="135044017" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 24 Oct 2012 20:58:32 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9OKwWcr027612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Oct 2012 20:58:32 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.252]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.001; Wed, 24 Oct 2012 15:58:31 -0500 From: "David Benham (dbenham)" To: Stephan Wenger , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Incoming liaison statement from MPEG Thread-Index: AQHNscujZwHhFoefwUqXZ7UaKiGxEZfI0J3A Date: Wed, 24 Oct 2012 20:58:31 +0000 Message-ID: <0683D6CB32AC424D8AF52C0F660E5DC51509CFE0@xmb-aln-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.140.227] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19302.000 x-tm-as-result: No--32.289700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Incoming liaison statement from MPEG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 24 Oct 2012 20:58:33 -0000 To further connect dots, this part 29 effort in MPEG/IEC/ISO towards a non-= royalty bearing solution was mentioned in our draft below as a potential up= side to selecting H264/AVC constrained baseline profile today. Unfortunate= ly, the outcome will not be known soon enough, but to the extent future sur= prises weigh on our decision ... this one is positive! http://tools.ietf.org/html/draft-dbenham-webrtc-videomti-00 6.4. Future IPR Status Consideration For additional informative purposes, the MPEG/IEC/ISO made a call for a royalty-free video coding solution for the Internet. As of its 98th meeting, two tracks forward are being pursued; one of which is based on the H.264/AVC constrained baseline profile [AVC06]. MPEG is presently collecting patent licensing declarations that would include patent holder's royalty expectations unbundled from other higher profile mechanisms. Should this effort result in a royalty-free constrained baseline profile, this would benefit RTCweb in the future if H.264/AVC is selected as mandatory today. From: Stephan Wenger [mailto:stewe@stewe.org]=20 Sent: Wednesday, October 24, 2012 2:40 AM To: video-codec@ietf.org; rtcweb@ietf.org Subject: [rtcweb] Incoming liaison statement from MPEG Hi all, Please find attached an incoming liaison statement from MPEG. =A0It's short= , and therefore attached. =A0For those not familiar with MPEG's terminology= : "AVC" stands for "Advanced Video Codec" and is used in certain circles fo= r what other people know as H.264, and sometimes, depending on context, onl= y for the non-scalable and non-multiview profiles of H.264. =A0(H.264 is th= e ITU designation for the joint standard). =A0MPEG-4 part 29, or WebVC is, = as described in the statement, what most people know as "constrained baseli= ne H.264", i.e. H.264 baseline without the rarely used tools known as Arbit= rary Slice Order, Flexible Macroblock Order, and Redundant Slices. Also, in order to avoid possible confusion, let me emphasize that this liai= son statement comes from the standardization body known as MPEG (ISO/IEC JT= C1/SC29/WG11 ) and not from the licensing administrator known as MPEG-LA. Regards, Stephan From fluffy@cisco.com Wed Oct 24 14:15:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570A221F863F; Wed, 24 Oct 2012 14:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.387 X-Spam-Level: X-Spam-Status: No, score=-110.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEQNhHl13BCG; Wed, 24 Oct 2012 14:15:33 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD5121F8673; Wed, 24 Oct 2012 14:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=91510; q=dns/txt; s=iport; t=1351113332; x=1352322932; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=t32brFEGVnc/flDlTRMiJMbxvdP+MTEBFpTpX/6Ply8=; b=J1ncf9PjreIdys0pFYT2yUhE4WeTPYfVHM5/W0UneGJsPNVNERvjePTT Vz1EZJ1sOrGAgxVJBKHymXah5lvo6VIBwV1hU5VLUBHWjKPaeYmrR4oUb dmWxz564tpxj6fPhutJdYhx2cNr7nY0HSzBBSI7iOfP3Thitrlmk0ILzG g=; X-Files: 29n130661.pdf : 65410 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAARaiFCtJXG8/2dsb2JhbABEwX2BCIIeAQEBAwEBAQEPATIpEAsCAQgiJAIYDQslAgQBEggGFIdcBgucZKANBIthhgxhA4xUgiCBIIItkgCBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,642,1344211200"; d="pdf'?scan'208";a="135029849" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 24 Oct 2012 21:15:31 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9OLFVQQ003178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Oct 2012 21:15:31 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Wed, 24 Oct 2012 16:15:31 -0500 From: "Cullen Jennings (fluffy)" To: "video-codec@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [video-codec] Incoming liaison statement from MPEG Thread-Index: AQHNsiyyLrKx3htF00WYSO3HJn4Vrw== Date: Wed, 24 Oct 2012 21:15:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19302.000 x-tm-as-result: No--38.709800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/mixed; boundary="_002_C5E08FE080ACFD4DAE31E4BDBF944EB11189E17Bxmbalnx02ciscoc_" MIME-Version: 1.0 Subject: Re: [rtcweb] [video-codec] Incoming liaison statement from MPEG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 24 Oct 2012 21:15:35 -0000 --_002_C5E08FE080ACFD4DAE31E4BDBF944EB11189E17Bxmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-ID: <0B60FE4C66A49547875C88B544BE572C@cisco.com> Content-Transfer-Encoding: quoted-printable On Oct 24, 2012, at 3:40 AM, Stephan Wenger wrote: > Hi all, > Please find attached an incoming liaison statement from MPEG. It's short= , and therefore attached. For those not familiar with MPEG's terminology: = "AVC" stands for "Advanced Video Codec" and is used in certain circles for = what other people know as H.264, and sometimes, depending on context, only = for the non-scalable and non-multiview profiles of H.264. (H.264 is the IT= U designation for the joint standard). MPEG-4 part 29, or WebVC is, as des= cribed in the statement, what most people know as "constrained baseline H.2= 64", i.e. H.264 baseline without the rarely used tools known as Arbitrary S= lice Order, Flexible Macroblock Order, and Redundant Slices. > Also, in order to avoid possible confusion, let me emphasize that this li= aison statement comes from the standardization body known as MPEG (ISO/IEC = JTC1/SC29/WG11 ) and not from the licensing administrator known as MPEG-LA. > Regards, > Stephan >=20 >=20 >=20 > <29n130661.doc>_______________________________________________ > video-codec mailing list > video-codec@ietf.org > https://www.ietf.org/mailman/listinfo/video-codec PDF version of the liaison is attached for folks that requested it. --_002_C5E08FE080ACFD4DAE31E4BDBF944EB11189E17Bxmbalnx02ciscoc_ Content-Type: application/pdf; name="29n130661.pdf" Content-Description: 29n130661.pdf Content-Disposition: attachment; filename="29n130661.pdf"; size=65410; creation-date="Wed, 24 Oct 2012 21:15:30 GMT"; modification-date="Wed, 24 Oct 2012 21:15:30 GMT" Content-ID: <23C31A1EA07F8B419FDBA02BE28C7B1E@cisco.com> Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNW9ty3LgRfedX4JGq8tIEr8PkSZYdl7bWUtaZjR/i1Jas sUe7tobaseRd5TOTH8oBgdPgUCRMynlIucrkkGAD3X36Cug39aP6TWmdNE1aybWsdZI1RaFWuk6a dFWp/Xv1Ru3U05PPWl1+Vmn37/Mlvk2TrLC/zY1OdVJlaa3qsk503WTR5bV6tsaoNMXr9aUqV91o d1lfq6frtU5SpdX6g/qHik/PjtR3mYrXuGgVv7CX1+ZhFLt3xwdDTs/tz8OXP9gP1REox25ER0XF L48iM4Oj4j47/Zv9IEjbUvuLHdkRjWJH1L5yRNziD2d4bpfpHrrP3EPMHhl2J2f/p1p/r16sO3Ud irxMm6TK01JEri6vI4g8KOgYy13/Ok5Qg2Cq00LVBRTTHOiwyOfo8Pz1y+Oz0yMFIUMghi0IBJfT owiPzs8weW5+mQFn9hX0jAGvz2SkeXd+dgw14rl9az97zh8RaJydv37l9GZHjs5qaR2pkBAzwDdd DXl+tBAzXSW6SnNVZ0VSP8oQHJYcdp9aCXb2EMUnFksWdN9bCTjQHbzS9pX92BE8GJBZ3DX9cW/w ozBm0hmincMRwmVaiHlTAi9pM+T50ULUZZHooqhUna6S6jFIPDl/7mD20qLnHMYLQKkjgx4HnfO/ W+4PR/7VCrwD6YkF6U+vLfYsqC3B47PnltjxT24qKGxaRoXxi2nlWYK1Ggd5IKNo4BZD1gpXXZdp pVXVFEmZNxkJWh9ddhdHMKOfnUdwlSar8tsJ5ggvJbSnqgr40ELQxoRoTkyYNgXlTSGCXr/NFLqI 05lCFFuTCZuC8dgYF9A2dJI3aSas98LhPFd6BovDLHn3v72vuvv6KJqeFzhIyhQRfSDyA5QpQRkk h+AbAkVeN7BEDUbKaVCAYDSI5kZxCFcqvuLNxY53W//slyOTR6j4iTLOyX0Q2Ru+k+8uniiYWDfo 0l1v23f87r17tO/pJRqmKaXOnHzC7BwkJ1Y+0XgQ1uViglGcpdDoVBgu83wJSafDLESQoAgzfaDD ECjKYoYUl/gyD9vcZo8BXyY5Y3CFYgdZnmRhXzZK0GTHVZUUtbGltOqCkCqqBJmCzpNGN82qnxtH odzYe2okWCVSgjHuhkaJjFhsqL0jyAHuA/wD9NPOQKd1ktbVCgzYeZ0TsqFBuYs4A7ibgTOwJQJ0 jTjTk0KeJYUXQzS7RNArLAclApczJoYhaiAG8QyteIIvNHZ50vbN/mF1Uq2SOq/81I+RBOEADXbZ sYNDVidlAzjMloPAoUTaVM3EJuSwpkO8/eRQENQ+iNdFUZeK0zyGZ238pdG+Z9pqfzHXmtrncmZq /wdyfcGbzzQGjwdkZAEzKKGvVZUvEwSMb8pBa6QzdZXqZQRvQwQb5HJVtoggEHFxSzu45o0YxK26 bY1YoqnyMYMKkY+uZNIxhXivpHTk6nSK/8UaKXXnjdRrPluLsZoEKk1KFXNlEqjVG5Qe3SsUGtNq y3OT4PaEMrG+2VErz1GQfY3giP/xicuGbKpT3vWE8IUAdcMiYb0N8VkggyhQHQT1MFxW/N00mgrd gKAOK3ZIEGhiTtUKm1Qd36hnrahcWIpMlAAMes0geJ2kyFbeQCZUd5BlYQUwaJf7BQ26aDRKKd0E JTaSk95K3knGgtN4j7VCm8xX8sHwCS5uiA0G63bLO877mXyKL1PtBw8qU5amSd0LfWoMhM7EPM7E xPoEpi0sQ0SryxXczgIG+1lXP0kq4RSBvMwnSVWNsPiIqIhYnc6PipIk3V7cSpoEsU6zrdPcuO9C lW6mbwuMwrekRcsY9zBbxrjpGHbeV/AmN4RbK3kSTNoJZMRcdQWHodFIpEDmmCtwEDFA2jzxf9VK 9vkRukCoP9lKHrO7ZY2NskiTAtAKKHwhwQxmOnOF8Aym7dSpDC0me/PCRVDTcrOh9He6hvaOad5G 8Y4R5iMdiUJW0X3XxfrJVrGuC2gY7fxy2YI53+5Dtz5E83Z/zaB/397BazGWB11pVhQmBQPC3PwT CDOxXDQAgXF+ctlzl0h0pk08q6FoTCrzzdJ4IKZmRoCZMZFlAty2ZGG3VVSaCNPdRJDqQw75pFUb fijmTDy0MPlpKeQr2HVaIE4uWHTfvw/jOpqMywlCjReEzM6k7NMLBkRRpiFtWLLegNaKLEvqrF5G EOvdt/dcMiVNbdyrd1YbkXC176nY54DUWdgwva9Dj8H0XOcAFStkRtbSGm/2nFBsRJIMrq/dKXlJ fsjnbsO7/SZRr+iOeo4q6vyMd1Rcwt1ept6RKqV2r65IVmaGy7KkfuckrbrhKBK48sPvdoL/vSIr HkYj8SyvM/RrcuDeCXXC25j0s+9tYF52ZTI5l8Npt8N18sVXcJ2VSV5mwOECLYcMEcn1coKADflp FRmhFq/ICWUgvkZCjAwR8QR9vkC7aPL+jnAwjGON7btfO2Bgm4aQ5iK5/F+cnswap72JRmGFpk+j uIAJGAyDzp/prZBfd5jnMt7ZtBrt6hOR326jTv3jxNS2k9+EFpuVSErRrOsvttvM7e/muGq8j1mq zeuEQrrismH0rqqi0uk0ZARfeCrHNE7PnDppd0KKs+z5KReyI9GNesZ3QpbvrH+IJL7LR+pmj5TC 5ELINUiS3oRf94Vvx0SxTDETk+jhfaUt3Jfyx10r3mon0/s5/03EDh1nZHaw6TgDUO1aVNjvLBas K9QD0FWOhAu91iUEYXyFd8WSkqis+Y9jIlFrdzd0BlGsNi3t9G4IMAkMQe1kqOtrpKqy6JnBcCTG uCDtXcgO5cq0/PO8SvIKm2QhcXnrs1suENfN3TuCk2AVUIj9bfqACayhwe5C5iEwh/lQjMgbtD0X 0gNLJ5JSUInkjCbP+E1z5FU9p88QpyCmzG/V2/hEhr09CumkxNZ/nq/KRToJCaTEdvQcgsN4QC8G Vx/y4D7eoSPgdnke58FHUHXpwgrRdi+Y+sLlUU0cwueCUNFTSOoabKBuyNHGES66YwrjcUgsQTS9 F/wcSMt8rtXYwbGmRo6u/YRzcA+cXhFSvN78ybkmbMx3HvepkxlxfEMBbBM6KvFiFJbk8luKkQGm lRiVtPst55Co0O4/UgG77c9hVzhIMknr4TpDcCvg4as6g3k4Rc2RWz9kaCN4s7VjKK1wxkZd49Y+ i+TZJ3nWjeu2qz6pg2/dsyv14UEj2NtEieOB88ubtKBQpDKQcJQ19l0UMz/zKUryL6d76uKgPrYQ HsOgaYTitIoqFiwzTqZb8KajtpwgDIYdtWHlrVHSLCYIK+nlplI7SYRyPiSKERwDeXSWISxnNTq7 TjoTebQrp9x5BFMRTXGT4YTDHIoHnriP3aF4MhwbqEE1uES35dHP6w7aM0EZdL3ZngzmWBvkT5fz xw39SSvBkY6L1QzKc7oh+ic/xLo0aS/wxX1Qc3lVoBAuUQEtwDVWLV5N/CMXdMWCvp9xC6Cu+lky Mnl6NFqjDOQDNMXQPBj4Q+l7kkn57IBZiSjOyaiiaOw2zbXSxqDNwWY+U/BZ/We1OS/3SfU/dY+M G6OjeHB8yPszAM5sCYVNwZ6ogEAvHI9IIUaSVemfCKMPREAcbWDFVlw7qctFW60R5gAoQpIiNzUc e8297i2R50lIRCdNIb4jGvhGWUWjjxmyoRwnY3G8GEY6S3iSWkj7ByYUSJ/zFPEQHdoQ9aELCKWL OZzUYoLQtZQelDhALiyIUOUlZbgJZWUml8/1Coa8QHRxEggoRYqW1AyKBy4Y3K0dwKS6ETSRkYVt brEH33ASCZJkOD55o8SJa7NzONM3E/JEM90NVSPtQLrue3Vztxd+77i6je+q8tOHFvJq2IPZc9qr A6/2ILKhiVXB0yhsZ3Bb9KtVhTlfqAPKz3B+74DoHInFb+NARMfROJxDllU6guakLw7BmpO+1qe6 iz1zJpE4/vz+fW+54tmHwvCa1unsnUGA9v+jVmA0JG54HeJutxWMsYSR5jy/2d5pzRR55OXPoe2A RMSBFXmHyqD3IInPcTogL3BMAHvEndQR9L4OwbdHgfw4X6G2L3AQmiRnAbAHkSEycrSOvomgYE5S AveXB+o66gTQVUp89kkdPDN7yv1sAsPco342oX4zkbt3TEbgnKP1033g/iQgaCudFMYPI3uCK5QL 89KTCPbxihlBb7tHupayL+2yBvo4AWkvFPD0DiHdSjAg+G/E38v3DwhakKOjSDIyg6lhPGKHIMiQ AuCAaQPlTLM/TAHAvqzNb8MyNjx05L49jWzdpmJfZJN3Q14Q80mVpPayaU+2lGQDqAksqS2/oqFL 55Rk+DFnQtXAW6aEUSx5uwjZxyipqBmAOJVUH7vNE4DMyPlrMENVNPWHIr5b2mXBBmZcuqhTMkoR RCuPnoxo33Hj9w22O/IuFPiA3FFuo5p05xCFc0Z6EvH0odD2bi9wlunkxmDH6lBkDgc4DdbctDfN nmAeEOIQrMF81bQ3lxKEVo5p/LJuj5U7SvHqiZIyQ8xTnvSPqshDwooyJSmpCjlA7GiHBKslSPhW DIA6oUJJ10HV/UnjpIsty24TcmbBZheLgoaz8MrZ343V8dZnjlgkUhDWbSNSnrTIIICyFNF4pUuV O9ZcDC10V7+6i820sBn08HT/0H366IE//zSbY98alD1Bc1p85jGpPsR//C8NNlmnCmVuZHN0cmVh bQplbmRvYmoKNSAwIG9iagozNTA0CmVuZG9iagoyIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJl bnQgMyAwIFIgL1Jlc291cmNlcyA2IDAgUiAvQ29udGVudHMgNCAwIFIgL01lZGlhQm94IFswIDAg NTk1LjI3NTYgODQxLjg4OThdCj4+CmVuZG9iago2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAv VGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RUMS4wIDggMCBS Ci9UVDIuMCA5IDAgUiAvVFQzLjAgMTAgMCBSID4+ID4+CmVuZG9iagoxMSAwIG9iago8PCAvTGVu Z3RoIDEyIDAgUiAvTiAzIC9BbHRlcm5hdGUgL0RldmljZVJHQiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PgpzdHJlYW0KeAGdlndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRRiUmAUAKGhCZ2RAVGFBEp VmRUwAFHhyJjRRQLg4Ji1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nnt9fZZ+9917oAUPyCBMJ0 WAGANKFYFO7rwVwSE8vE9wIYEAEOWAHA4WZmBEf4RALU/L09mZmoSMaz9u4ugGS72yy/UCZz1v9/ kSI3QyQGAApF1TY8fiYX5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi48SvbPan5iu7yZiXJuShGlnO Gbw0noy7UN6aJeGjjAShXJgl4GejfAdlvVRJmgDl9yjT0/icTAAwFJlfzOcmoWyJMkUUGe6J8gIA CJTEObxyDov5OWieAHimZ+SKBIlJYqYR15hp5ejIZvrxs1P5YjErlMNN4Yh4TM/0tAyOMBeAr2+W RQElWW2ZaJHtrRzt7VnW5mj5v9nfHn5T/T3IevtV8Sbsz55BjJ5Z32zsrC+9FgD2JFqbHbO+lVUA tG0GQOXhrE/vIADyBQC03pzzHoZsXpLE4gwnC4vs7GxzAZ9rLivoN/ufgm/Kv4Y595nL7vtWO6YX P4EjSRUzZUXlpqemS0TMzAwOl89k/fcQ/+PAOWnNycMsnJ/AF/GF6FVR6JQJhIlou4U8gViQLmQK hH/V4X8YNicHGX6daxRodV8AfYU5ULhJB8hvPQBDIwMkbj96An3rWxAxCsi+vGitka9zjzJ6/uf6 Hwtcim7hTEEiU+b2DI9kciWiLBmj34RswQISkAd0oAo0gS4wAixgDRyAM3AD3iAAhIBIEAOWAy5I AmlABLJBPtgACkEx2AF2g2pwANSBetAEToI2cAZcBFfADXALDIBHQAqGwUswAd6BaQiC8BAVokGq kBakD5lC1hAbWgh5Q0FQOBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6CF2D+qAH0CA0Bv0BfYQR mALTYQ3YALaA2bA7HAhHwsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVfwpMIQMgIA9FGWAgb8URC kFgkAREha5EipAKpRZqQDqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh1mJKMNWYY5hWTBfmNmYQ M4H5gqVi1bGmWCesP3YJNhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxwfrgYXDJuNa4Etw/XjLuA 68MN4SbxeLwq3hTvgg/Bc/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYgJGwkVBAaCOcI/YQRwjRR gahPdCKGEHnEXGIpsY7YQbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9IZPJOmRHchhZQF5PriSf IF8lD5I/UJQoJhRPShxFQtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9Sn0vR5Mzl/OX48mtk6uR a5Xrl3slT5TXl3eXXy6fJ18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJRZqilWKIYppiiWKD4jXF USW8koGStxJPqUDpsNIlpSEaQtOledK4tE20Otpl2jAdRzek+9OT6cX0H+i99AllJWVb5SjlHOUa 5bPKUgbCMGD4M1IZpYyTjLuMj/M05rnP48/bNq9pXv+8KZX5Km4qfJUilWaVAZWPqkxVb9UU1Z2q bapP1DBqJmphatlq+9Uuq43Pp893ns+dXzT/5PyH6rC6iXq4+mr1w+o96pMamhq+GhkaVRqXNMY1 GZpumsma5ZrnNMe0aFoLtQRa5VrntV4wlZnuzFRmJbOLOaGtru2nLdE+pN2rPa1jqLNYZ6NOs84T XZIuWzdBt1y3U3dCT0svWC9fr1HvoT5Rn62fpL9Hv1t/ysDQINpgi0GbwaihiqG/YZ5ho+FjI6qR q9Eqo1qjO8Y4Y7ZxivE+41smsImdSZJJjclNU9jU3lRgus+0zwxr5mgmNKs1u8eisNxZWaxG1qA5 wzzIfKN5m/krCz2LWIudFt0WXyztLFMt6ywfWSlZBVhttOqw+sPaxJprXWN9x4Zq42Ozzqbd5rWt qS3fdr/tfTuaXbDdFrtOu8/2DvYi+yb7MQc9h3iHvQ732HR2KLuEfdUR6+jhuM7xjOMHJ3snsdNJ p9+dWc4pzg3OowsMF/AX1C0YctFx4bgccpEuZC6MX3hwodRV25XjWuv6zE3Xjed2xG3E3dg92f24 +ysPSw+RR4vHlKeT5xrPC16Il69XkVevt5L3Yu9q76c+Oj6JPo0+E752vqt9L/hh/QL9dvrd89fw 5/rX+08EOASsCegKpARGBFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC/EN2hTwJNQxdFfpzGC4s NKwm7Hm4VXh+eHcELWJFREPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtFl0VLl1gsWbPkRoxajCCm PRYfGxV7JHZyqffS3UuH4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoeGx8d3xD/iRPCqeVMrvRf uXflBNeTu4f7kufGK+eN8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9BteB1sl/ygeSplJCUoykz qdGpzWmEtPi000IlYYqwK10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZZruYjv5M9UiMJJslg1kL s2qy3mdHZZ/KUcwR5vTkmuRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6thdauXNu5Tnddwbrh9b7r j20gbUjZ8MtGy41lG99uit7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVsFWzt3WazrWrblyJe0fVi y+KK4k8l3JLr31l9V/ndzPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu4F2t5czyovK3u1fsvlZh W3FgD2mPZI+0MqiyvUqvakfVp+qk6oEaj5rmvep7t+2d2sfb17/fbX/TAY0DxQc+HhQcvH/I91Br rUFtxWHc4azDz+ui6rq/Z39ff0TtSPGRz0eFR6XHwo911TvU1zeoN5Q2wo2SxrHjccdv/eD1Q3sT q+lQM6O5+AQ4ITnx4sf4H++eDDzZeYp9qukn/Z/2ttBailqh1tzWibakNml7THvf6YDTnR3OHS0/ m/989Iz2mZqzymdLz5HOFZybOZ93fvJCxoXxi4kXhzpXdD66tOTSna6wrt7LgZevXvG5cqnbvfv8 VZerZ645XTt9nX297Yb9jdYeu56WX+x+aem172296XCz/ZbjrY6+BX3n+l37L972un3ljv+dGwOL BvruLr57/17cPel93v3RB6kPXj/Mejj9aP1j7OOiJwpPKp6qP6391fjXZqm99Oyg12DPs4hnj4a4 Qy//lfmvT8MFz6nPK0a0RupHrUfPjPmM3Xqx9MXwy4yX0+OFvyn+tveV0auffnf7vWdiycTwa9Hr mT9K3qi+OfrW9m3nZOjk03dp76anit6rvj/2gf2h+2P0x5Hp7E/4T5WfjT93fAn88ngmbWbm3/eE 8/sKZW5kc3RyZWFtCmVuZG9iagoxMiAwIG9iagoyNjEyCmVuZG9iago3IDAgb2JqClsgL0lDQ0Jh c2VkIDExIDAgUiBdCmVuZG9iagozIDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvTWVkaWFCb3ggWzAg MCA1OTUuMjc1NiA4NDEuODg5OF0gL0NvdW50IDEgL0tpZHMgWyAyIDAgUiBdCj4+CmVuZG9iagox MyAwIG9iago8PCAvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIgPj4KZW5kb2JqCjkgMCBvYmoK PDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvTU5TQlNZK1RpbWVz TmV3Um9tYW5QU01UIC9Gb250RGVzY3JpcHRvcgoxNCAwIFIgL0VuY29kaW5nIC9NYWNSb21hbkVu Y29kaW5nIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyIDIxMSAvV2lkdGhzIFsgMjUwCjAgMCAwIDAg MCAwIDAgMzMzIDMzMyAwIDAgMjUwIDMzMyAyNTAgMjc4IDUwMCA1MDAgNTAwIDAgNTAwIDAgMCAw IDAgNTAwIDI3OAoyNzggMCAwIDAgMCAwIDcyMiA2NjcgNjY3IDcyMiA2MTEgMCA3MjIgMCAzMzMg MCAwIDAgODg5IDAgMCA1NTYgMCAwIDAgNjExCjAgNzIyIDk0NCAwIDAgMCAwIDAgMCAwIDUwMCAw IDQ0NCA1MDAgNDQ0IDUwMCA0NDQgMzMzIDUwMCA1MDAgMjc4IDI3OCA1MDAKMjc4IDc3OCA1MDAg NTAwIDUwMCAwIDMzMyAzODkgMjc4IDUwMCA1MDAgNzIyIDUwMCA1MDAgNDQ0IDAgMCAwIDAgMCAw IDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDQ0NCA0NDQg XSA+PgplbmRvYmoKMTQgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAv TU5TQlNZK1RpbWVzTmV3Um9tYW5QU01UIC9GbGFncyAzMiAvRm9udEJCb3gKWy01NjggLTMwNyAy MDAwIDEwMDZdIC9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQgODkxIC9EZXNjZW50IC0yMTYgL0NhcEhl aWdodAo2NjIgL1N0ZW1WIDk0IC9MZWFkaW5nIDQyIC9YSGVpZ2h0IDQ0NyAvU3RlbUggMzYgL0F2 Z1dpZHRoIDQwMSAvTWF4V2lkdGggMjAwMAovRm9udEZpbGUyIDE1IDAgUiA+PgplbmRvYmoKMTUg MCBvYmoKPDwgL0xlbmd0aCAxNiAwIFIgL0xlbmd0aDEgMzg5MzYgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4Kc3RyZWFtCngB1Lx5fFTV3T9+zr137p197kwyW2YycyezZJJJMpOVTIjkhiQICUiULQEj YceVJCyKisS6IKCFumMVsC2utAxhMaDV6KO2aqnYWqu2FmzR2iotbdGqkOT7Pnciap/n+f5ev9fv r9/cnH25Z/ns59ys6lu9hJhJP+GJuujKBT1E+wVlQujORWtWKdm0vJMQ6d2lPcuuzKY91xOi27vs irVLs+lQhJA1VcuXLFicTZOzCGuWIyObplUII8uvXHVNNh1IITx+xYpFY+VKBum+KxdcM/Z+8nuk lasWXLkkW/++TxCW9KxYuWos3YHw7p6+JWP1KdK2lpfffkHyV6/6OSGPNRJixRRQq5b8k9STh4hE OCKTJJmNkf9R+JjokGblOm7LqdyVc+fb6j/Ve/Va9z/4U/4LLPJf0jW3nVk1fLtM9OiMGLT6rADt pNBIC5kjkzOrvjwmZ9/ESr761R4iM/lP9vHFwYZGJ3+CdPN/ITv4D8gxOIHIyJERa4DrQXwUTjc6 xL+/r6WlQh1EmCjTwoF4UcUhVjCQ56/4Kf8+t5sUkiAyjg24fFrJHwYmThyL1NRmI/uKSyuONRr5 P5C/w3H8H/hjJJ5ttS9eVnGq0YIMyt9AbJSSINnJv0cycBxR+Xf3RWIVO57jf4HyV/lXyGKt2SsD FnsFOvwZ/xRxkCB/kD8wVnJgn9VeQRpX8ndgTYbgH4U7DncKTiAr+EfJergtcHvgBGKDH4RLwk1n OfyT/JMY5y60t8FPwq2A2wInYAmfQP7lzOcf4y8jBWh7O383cSLczN+lhT9CmIf0D5AfQPgw0izc MZb+PkJW/sBY/jakXUjfPxbeh3wf0vcizcJ7xtJr+NVau1Vj4U5+5UAgKDcGUK7ApeB4xO5G7G4s 3d1IEfiUv4m/QhvBXoQV6PHKbIhdWzcQCmt7tG6f21uxE0u6Dku/Diu3Diu3jgioc/1Xda7P1inl r0ed61HnetS5HquS4lfifSuxYQS+DKfA8Vj3lVh3lp+BPwR3FI4nN8PfCreTpfirsY5FGNVG/rKB eBDAtmxfWq1oeJpfiqVW+aX7vPkVW75OGYwMEJfuM1jHQhuru0Sru2Sfwcxyl+zLy8+GqHV5o5Vf RK6D40gu/AhcFVwznMAvGogkg4f5C8iVeqJag+u59fx6Yb1OSDVTx3N8BWkHBgaJgy8l9ahQFJxf T8d1G3oM/QZeNiiGlEE1tBt0K/j1/BaeD/JJvoGfzs/ndYOjQwNSXSUC9XyxrnKraacpYxoyHTXp MuKQeFQ8Lp4SdYqYElWxXewWe8R+cau4UzRsFbdKXLepx9Rv4mWTYkqZVFO7SReU6M7GW/iFmCaB L8P1wG2FE7DG85Gv8JfAzcduzMeyXYJ8Ap8gJcMdRfw4Qh1SNtSzoZ4NuTbk2pBL4LOSdrhuuB44 ViqeK/mqDat/ipXAFaLUip6shEM/VuQjBteKlAUpC1IW1DrKncUIZfgKXDscr+UdRwxQA/+rstRY eTdCkbDyU3Cc1o6VqXA8d1ZdUDhURDNFdGcR3VpE1fqGxgq1AJ7D4Zgfnh+dH5+/S1gRXhFdEV+x S5genh6dHp++S2gIN0Qb4g27hGQ4GU3Gk7uEYDgYDcaDu4QtU/dMfW7q61OF+VNXTF0/lR+Hrds3 kEhVaGFBlIUHBrx5FeNsjeO5PZjOfPg74I7B8SQIPwnXALcCTuD2wA9yP0buj5H7YzIdbj6cDi1+ jPY2+KyclbH8HXA6LXYMMe5b5WCG3O6Busrpja0gufPhdsDx6Hs32u/Wamdje7T8DPzjWv50+Kz+ Tjg2yt3n2vAgcHPZOOAH4Rrg5sP1wOnI6/wcMIc5rGf4QbgeuD1wAj8Xzxx+DvdjPLu53XyJail3 BonLBW7jsOvlRpkzAwYs9DHNv1/zN2p+g+ZHVGur5bNWy7OtlltbLYWIcHHSiAZ3a35INTVa9jda pjdaihot6M1NQsTCOTVfZD79WPMv0PwSNTdk+SJk+VfI8o+Q5aGQpTdkOS/E2vmBuxYuV/NNzKf3 an6r5sdUU9DyctAyJ2gZF7Q0Wuh2ijGQiZof0Hwf8+k/99uabcTwNP0naUZ/dKC+KDjIES2gowP1 jcFBOjJQfz6C4YH67Qi+HKi/K/gM/YJqLI1+NhA5EWx00tN0igAWR/81Fv6DTiFPIn0K4TKEj5B6 GkX4o4H6G1n9H6L9A0j/gBToWbuHSbvWfgedouU/NNbuwYGShXjr9wdK1uKtD5ASymrfN1ByArl3 DZRsRHDnQMkVCLYMRNkALxuoLw422ukyEuFY3UUkyrGRTB1742T0fAXS52cbtwyUsFbN7AWDtGkg XI6gkI3yGRom7drrggNhbZL5JKwNzk/C2qB9JKqFVmrTBm8hBVqoHwjfiF7E/dETwX/XP80mTj6l toHtwT89g/nNRvKPdMrAk8E3DrHlGgi+XjJIoweDvww/HXwpMkhnDwSHSgb1KHiuZJCjB4J7scgZ 1OXoweCekmXBH4e10l1hlGKrd9SXBr8fnhvcFkV6IHhjyTNsGORKzHg2ijtLJgSn1j8ZnBQdpChW 6/Ey1RisC/cF08iuHaRT9j0ZLI8MsqGk0MeTB4PFeGMsrA1l1rjDXDWR6Gq1RFolLZRmSxdK46VK qVRSpHzJL+XqHXpZb9Wb9Ua9Xi/qBT2nJ/rcwdHjaoKJa7miJrWJINuUCFpcBmmkQEBNmuOongPu ZHL4Nq5txkSacbSRtpkTM+MSbYPS6EWZ2kRbRt8+r2Mvpd/tRCrD3TZIycyOQTrKsm7xZRxNHYcI pclb7vCx8Ppb7ujspG2ZoUWkbaGS+WwG5mG8cG5GF57oIa41DZ4GxwR7elLz/+B1a5ndzYmvf56v o4h58jP3ts3oyDyR35mpYJHR/M62zPkzlIs7DnG93IqW5kNcDws6Ow7Ra7nelotYPr22ufNcNVLA 9aAaqWcBq7aPFLBqpIDu06pN1XoDmBa0NO8tgMcqvUCnsEoAnxe0Ssu0SoDxXtZXOwtQjQuQiNZX hAuwaoCHbGe2b3ZmJtSmdWYzE60zP6u0NxrF+0rgdXbsHRdFhb3RcVrxk18Xh7XiQ7STsAqHSJR2 au+h2nuyXcSzdQAFY3U4Pep8axn/vyaWTPx/0QPdt+D3ixe1LAm3dIdblsB1ZzavWe7J9C9UlL2L f88KlAwf6164aDkLFyzJ/D68pDmzONys7F2gtfuP4kWseEG4eS9Z1DKzY+8idUnzwAJ1QUt4QXPn vkfWN7V9610bz72raf3/8K71rLMm9q5HtHb/8a42VvwIe1cbe1cbe9cj6iPau9oumkjb2jv26snE ziZsIAv3cSYj8KHbF+qc6JJ7JmjIMT7kucF3WCBgW6ZEZ8YcnpixwDG8KW0sbWRFwE5WZEW2bazI c8P4kO8wfWysSEa2PTyRJIin5dLmc38rV65cxdzq1Qn4q1azQkSAtKEZbZlJF87tyNRn6lsyandz J2W7tnrs19Shys/Vv17PrahfX7+lfkf9nnrd6tWdyHY8V/B6ATe/YEXB+oItBTsK9hSIrODijoNq /Y6CvxfwqwFNdBV+LexVeDVC/LHkqtUYzMqVBC9ZCZd9XWJ1oqmjsYAsgrRLIZmXkhy4MFwl3Aw4 Hfkv+L+G+xPcv+AEchP8u+B+CLeP5fClfGmL59Jm9sZO9HiIePiKfanqitpBhAuWZsMZc7NhywXZ sL6xwoPygYZKY6MNgjclh+G/Cvcu3F/hvoTT8RV8hdY5xsx+nSvJygTFahEkVjFvZWIVTSBC2XKv WplIoAJLIwMprK22vEiP/QhduZpgKbAhCFBJy1/JmuEdaDv2YwUgxbrvwk0lQTg/tCsfIaPvw52A +2ikdfSs7nISHrls9Difg8o/HnOERMm9ZAeJkFO0nLxAhkDJH4Go007uJueT18keGAfW0tewmmFI GI+BXgRB9ycRN9WRbeQdcjHpIx+Q49Ca28gfqAP9tJAeaI3p0b/AbyO3jR5CLSNpIj8hh+kVdAbs Ck1kMleClYiSLaNDxE3io0dG30bqIfIBjYzuJZMR+5DYIZ2vJ9+DGn0ZeXWUWUkiZCF5lF5P/wLZ qptsFqqETaOXk/HkAPkNbUNsGlmre9twANLB98gPqZsOjR4b/TN5Frx0CXr6DrkNIx4gQ1wZ36Tb SRQSI+eRC8gClF5H3qE5tJxXRwtHJ45uQ+6j5J9cgnuZlzCOBJlC5pM7yMNYjbfICYgCJlpNH6JP 4nmD/k33NsbWRlaTa0k/Rv4I2u4mh2g5LefckA85zLCIzELZFrIL799HjtI22kmH6PP8Ll1qpGE0 d9Q5+ufRUVJMOjDCHeR5vOM0TaEO3sAX8KuEgLBKVzF8I2a4mDxIjpI3MI4/YN0/JZ/TYjzvczdw 60fnjD42+gHGoofsUEsuJHPJCrKGXE1+gF19gbxI/kHPcAbUfF14SXet7tTonVjbGJmIsU9H7Rno ezN2aYAM4nkLs7RTBbOopRfQi+gyuoXeSwfpO/QdTuRCYJV/5TP8a/zvhRqdbrQOPbmYJg8omUOW YwduwGrfifk+Rl4ir1AnjdFSzOgttP+MG8814/kh9zr3B/4WfotwVnfryPGRj0fOjG6C7akZcNeB 1XwCq/B36sIYiuhldCX9E0a+ldvPW3mZD/PVfCM/k+/kb+Pv5n/O/1LoE54U3tVN0S3QPSktGLlq 5I3RttGbsRYUuloAkFRCqsg4wM9SQNPlGF8Pnj5yPbmRbCLfBbzcSXZC3h0kz5FXyG/Ie+QT7ACh IYz5Urz9SkDdLfS7eLbR3fR5+hJ9hb5PP2MPV4AnztVwDVwTN4lbxt2C527uKPcW9xHv5xdB/+7H sx2moHdApQVhVFeBZ7Jus+5R8TUpLk2WFup/cfbkcPFw5/AfRshI3si8kXtHnh/58+js0bUYf5SU kjKMdANGuQ0wuAvPE4DEg+Rl8gvyW22s/6Qc1QHiPTQMaCjBrjXQ8yFqTKHT6IV4ZuGZQ+fiWUAX 0uV41tN++h16E72Z3kHv0Z77Mbdd9HF6EM9T9DCe39Bj9EP6V/pPDkDM8YDmKFfIJbk0ZtrEnc9N 5y7Cs4xbgaeH6+PWYIce5fZxh7i3+Bw+Cmq7gO/lt/E/4V/g3+S/EDihREgK9cJsYZlwk/C68Ibw tnBGF9S16JbrtuteEH1ilThLvEy8X9wjfiSelUSpHeLq9dKb0qg+Cor1M8z7APb0619SfJ2u1OUK 13DHgBcevke3gc7CioncTP4K/rv8r3RL6Sleoe/STfyl/OWjP+QncZ/zK+hs7jlawAd1dTDl3E5G 6ZPc+9xp7s+Ck87k/kLjwvfoU9wKvomDjQE09deCU7hJ9xGsAb8lddw6OsS9BMvVTaM/JXW67fSY bjv3BlGE41wOOQas3sDdh0a/5C7lNpMOoUp3hlyKdX9cdw3WewJ3Gy3m3xS2kw/4MPcvaFf3gmoc oa1ChLuES9MnQXGHaYCcpL2kh95DVPo0fY8OQiZ+jH+UTuXM2K0MZ6HjYGw5wofom7yRdLIx0hjn pO3cKW4W/4x4lK+G2nOU/IpcS3maAux89RshVwED7uYKQdNaQE1+TSuIh9wHen965BlGsXVv6zYD zh7mS8hFJEW6uNdIHXDjAzwd5FbY6A4DBm8jKe5+cv1oP10Muj8N9JMj0NtIkppALd0Y23rwCxdX AFo4H6/+HPT/VVD9Nvo3cjVVgFlDJC6wktuFFlCmbtDfzXgWky6kHiR3igd0vybTqZsQQRnZDij/ PbkEPOdPeH8eLNTfA2V7WCjBqBVQ5l60eHBkMlHx3EpeoxxZhzFPAJ63C5NBee8dvQwzvBQ8aip4 4ivk0tH7SBP27qLRm0Y3k/mjD49eDA13xuhjoL9rRgdIDdmg6+Rm6xJCFWjsK/RF8KPf0c2g25PJ u6BHUeohf8XzE4x/gu5pskn4LWhnw+jto7+BlTUOy+s20JlWUK8ryd+wbpP5IVI5cgG3d3QS3wMO dYxcOProaJAayfLRK0B5nyG7JB1oTz8J6HYBdjcLS7kUxltEXDSJ3It1OwhRJ86aqTZMOK9+fF26 dlxNdVVlRXkqWVZakiguihfGopFwQUgJBvL9vjyvx+3KzXHYZZvVYjYZDXpJ1Ak8VOmSlvCkbiUT 684IsfDkyaUsHV6AjAXfyOjOKMia9O06GYW1W4Cib9VUUXPpf9RUszXVczWprNST+tISpSWsZI40 h5VBOvfCDsTvaA53KpmTWnyaFt+qxS2Ih0JooLR4ljcrGdqttGQmrVm+qaW7ubSE7jUZm8JNS4yl JWSv0YSoCbGMO9yzl7onUC3CuVvq9nJEb8EUM3nh5paMN4ym6IaPtixYnGm/sKOl2RcKdZaWZGjT ovDCDGFSc0KrQpq012TEpoykvUa5NIPZkM3K3pKhTbcPymRhd8K8OLx4wcUdGX4B+mjJ2BN4b3PG fe0Jz9dJdA75fMM3S338JkiICqu8adMGJbPzwo5vtPWFWA+dnegjw0UndW+ahBffjn1qY+pbhrul syNDb8ELoWFEtTllZ5dVf6LdlykZQ3hiePmmy7qxMXmbMuSitaGBvDz10OhxkteibJrZEQ5lGnzh zgXN/r25ZNNFa/d5VcX77ZLSkr2yPbuse622sYjZ8s3IEix5tkyLadVZrO2ic+tK2RjDU6A0ZJRF OLK6qCOMOdUyb0kt2bSoFsuPXydFq8xi7MelGUNT9ya5DvkypkgzuqgcVjZ9SrD/4ZOffDtnwViO GJU/JayQQck5QMuAyY0BXSaRyBQXMwCRmrCjGOMELV1dWrJmkMuEe2QFAbRH0o61XdBZl8Tih0Js ezcPqmQhEpn+CzuyaYUs9A0QNQkti+tmJUNflThnsZL+r0rONe8OA473g4cT4szoY+f+bLIrp2V5 XYa6/i/FS7LlbTPCbdDBlJZN3WMw2zbzW6lsOVtQrBvKxmI02xALnhGiGTE6JQzQuwjKHDLwp4tO Crdc2j0ZqIYxZnKaOngfhw5YjPPxWleA34vnftUfS3SYWV9CVNTgf/GgpAcAazlUmZSRuydn/U5j KDSGXv9PjQZHT7FWWvB1s7E5Z+oSY7PKzjEz/lvpbw3PvIlvmwnqxLXNnLtpk/FbZZNA9zZtmhRW Jm3q3rRgcLR/YViRw5sO8R18x6aeFlCs7PYPjh7e7MtMur0TU1lO6wDkHJm4N0xvu3CvSm+bMbfj EIxfym0zOwY4yjV1T+xk68U1zewYG6+28hgx2wlsuZimfmYi454gM+HKEL8K4QyE3+PShBcIaYU7 BVcCp8BdiPwM3Hd1PyOybjYpgGtFPCz8iRQjnIz2lVI+zJQr4f4E/vMz4pDuID6BjP6dv4NMQXgG 4ST01YxwKupPR/w8OAv6refSo4sQtyN+npgmdsTNcC1o9wXqWvh8shhlucjjWD30b0GI/okZ/RXB NX3lMDWIyPBRRkR6J0IFWkY2R8vWPA7GffYToKOLkO/1OB02Im3ScplnhmmbnRp/9cN5D+QIB2F6 ai6cc6yAGfEJtKnsz4PAC3ng2z9ovcRP8jVdRIGeWACNJAKuGoMOEAdPLYbkg/XWZOokJJxyyBSV 0A3+//WrhpTyf/+N04rHQzteR56lFlpHl9IdXC33BH+n4BP+oIvp7hDf0C/CQeE7xhdMz5nbLTdY r7PF5GWOixw9uVc6t7ie9RTmuX2d+buC5yn3hw6F/xb5fWFj/NPiROJ7JY8nTama8tsqg9Xt4x6q PZv+sm5d3dbxbC846ofE7GfHdtjraXs5+jT3LNt37rkBohMGuWf388QoscgBSrx6UfccygEjtIgY 6OX0EuJJyJ/VD9dfIJ+unzZcTxoQl8/CK0+F7CF7FB71C+Sswg+dVXXkDPBmCDA3c6SVux4WkBxS p4bvtT9q5241b7RzxvsNdnI/dHtCjIbHrAXtIhX7c2dewl7SdXK4vl7GG042nCyHrEu7qDNWGOOq ZTLOKYqcM9cd4Ljr71uy9UFa8dl12y8I5bWuG1kRnbr0e3TTm7SGjl5V3PzJyL0vvbVn06MPYAxl GMNsbQxpNVIkFOsn63i83I5B5ECENxgxgOzBKi/2Ozt+9N8HQbtyql1ul8MpE6m6psZRXVVYxpXd v2TLgyOv//u6HdNC3rbrdYuL25beOXL1b0ZeHaFXRVs+ppe/9JvMpkfYCK4aeZLeT34OHJmhFnZy ne4XXbzB3e096uUNlEiCYNM7yEGHajYJdTZn0Nnv5J2DtBhnDLb5Ns7m9TyIQWHlu6YNd53Ewpxw pKnd4U6Xp7A4vTkYEkYUCxdIYrggVl1VU1nhcuaKVy3rNUiSKerILa9rq5m4bMvIkyUFW9pzLIZc Q11l+aSV85ftZbRiBu3nOmAR4UmDqnC6/vzFNet10FTYKTxPOJm2g4tvpTvpUSrC1FB1gPQLM+ey VRruYhuVPAmfDSWRE3KGZnC64TOc+z7W8/dGT9AV0B1MJKH6iSqaeNWg1lUb1Ibq+Qa6w7DHwBlu MV92Leurty+RYHMrT0W10WdnQklSbSwra2x8QfPLkirrlx89wU3AjvLkItVAdK8Fl9VgIwf5QtXC 8bkch2ED4k3QfoJqrsKn+G6+h9/JH+dF/mn6Y+41YZCu2HuMvfXkabag9Q31G3RliXXyi+WpBIWy zk0YcbbTj3Xf/XK27gn0RVpHP+Kf0i0HBYyQwwML9BCXxQGdDrskDlgseYPUpjoMeSSmxjg11h3b GTseE2J2lm2dD3PPehiZdoLQeqOHaQBLO7abJy+Qu3o/m8amzSbetFadSiPhSEEEthyoiJwoRf2+ fF/Ax4s5MVvUFPN43V5ODAn2hSQo5i2kuVbEXGbEIlRZSH16eA7ZuZB4jfCYHVKzXYI4JIoTxcU3 5lQ5xgE63C57LgdYKYyNk92uyoqacTV2AFAWhLjW21fN7X7w+u/f9uuFL9x45Yst6d6aVYGyVCRd VNdcPbmK2/4RnX5R446XRvZ8MnLwng+e//fIR3vvWdC3m6Y/+v7KVOi8GSMPYo9OgdSIWDEXuU/N VT3dnp2e4x6BeFQPtwYKIWdtzIENpxHUZSe4Aa/F9YiHscGf42LPpdCzGhH/p4pjQBsMZFRn0Js5 HubKf6P6FNVhtdpUe3XKtt621bbTJti87sNchJ4YW9xE/TT55AlGR7C7doYwafLpybP000RCoyq9 XTnRSnuuy+V2hqoncNVsARgKnaKtoZz6i0e47lqXUYrmRScKP3v4zIa+2gAXjXL55ddyv7+7WAkE GRyWYI5PYo4Bulz9juQxpd0e/3lVHhWel3m2gMtVJNVLU6THJVFV5glz9fPccz2X61fZVzkeND1k 3WbfbdptfUX3ivvnnnfc73iOK18IX7idTpoveHU+p9flded7JIPb5DHlV3nP9250b1Ekj5fj3Hle s1e08F5OJ0KxdOZKOYJlEMMwGNRcc0O/gRoG+UrVLOvytnjpDu8eL+c9zFdi4e7YRzlzYJDeoVqI +MfpOfNzVuSszxFyBqmk5qiYVB5RVKVf4buVnQqneJ+mXwDPLFRVc+fDoLSe28I9BxPhMe7vnJ7z Bg/D+HYOnk/UZyG6axrQSmaIdXK4q7e+Ybh3r8gEsqe2GOhzhtcNHOnq7UycYCRM2xlHOs3J2Sr7 13nv8KK801q/Qdate9EKlKS9fV3gAwBikqB8qJqQ6ipslSiFa7KkDiYpTgpV1NSM45+cf/Y4FA1l +1WLd8Si3te/v+u9VOsjX0ygC6+YMymP6kbOROlEev/jNz6yuvfQy29uXbbsBwdGTtXK5aXAcgX7 eQj7aYTk81s17rJQG2mxqDZetdFiM3VKQEnKG3QiFcwmCxHMFkE0W7DuftUh6XMlSa/nBUk0w9Jr oZan6YPgsCa6Q7XoqGjQi6JeJ5jNwtM4guSJni5VTQaDjac7+D08xw/Sf6se2qBtgI12A6KP23ib qEpU8lq/scq99YxmdNVjiRH9UGa8uCGdlEGD5ZPycF+9PW1n3CG9oSwhgKKxqM1mA8z3gZX29lFn 2B62h6ppJQLKHzq4a/gFbvVVu0Yi9PR3Rx6gS/v575y9nXt4GIYgDjaRE/xjWBE3KaRmtfK6wnd0 vy14p1BYLqzVrdNfa7jafI1lbc7Vymb9TTmwaWwp4sbrdYWeUKFHxweiApF0h+ki4qHq/sJ2zAQ3 AVRDMroiClwiAEJxwKoDS7l9v9tNLJ7DdALJozZc0ZMdioN3DNIlqoMUqUX9Rbxa1F20s+h4kVAE C6hKQqimGp8zckZvnJHUj86R1BPa8gyfAPDJoKqOdLLrZJ98+iSWgcEbWw7wTZDaYl9EbzfH5Kg/ Fo4FLaGFJN/GCKkeMcUUADW1wyswRBcS7TCIUVP8bryR9gIa3UwOGJflt1mS6szlwH8pWDGjIyLE FEZZr/jO8TeKHlq/5RdLr3v50avv/MPLDz/LVTomrp3WeWtn4/yyG/xRbjWN7Fny3lMDmx/f9OSZ P46svfEy7tB3Lljw/jU7t//66tkljA+Dj27lM+Cjbmg+vJddNMi3LKvZ6t0JdqASyaw6TDbVCfZa tdW508k5n6FRWBB/BflKk2ZOa9ioMRmwafoNBpvzjTgNgdEyZluSbJzIQj6T5bpljcM5WkZZ2UQG Fd+FPDPI78V4wmSR6gtFn7cvq3nZ9mIBZ7b4cpyywXzQY2bjyh3kL1CDAdUDzm8zBMHua3xynS0U DPWH+NDPfd4IY/6QbJhgA/kGJGMYo0zKJ7R90raK9n5rwPz/Iu3QvLHBX/KfYg+/V2WTKStTv/zy vwtAHHg60WVwCoe7P5xnL8cIleqgwQAXyCf+ALSWIA34udxn+T8SN5wEZ+T/qLr1nD/A2/R+Vz4J 9sBuz1Gqt3F6kmxgQHfk6JFkkkGcfPLk3z6hyexPXrfhxRdluPKUT/XprTabRTYGDMH2kOi05ch5 9jyfz+/JF0O4PDYQrWbBvlRHlRYmyrRwoCibrcSy2XmBbLZbyx5waoF6n5xTZbGZ0Hna1mqbJE8J TA912ubIs3I7ApfZlsnLA2vkfmGDdZNtg7zBsTFwW/D7tu/L2+zfDxyyHZJ/mnco8JrtVfnn+a8G fmd7W/7Y9pH8UeAL2+fyF/lfBEoMtjYfF4Qgg0Ui+YGA32A1+gwuv9vn0nOST++05/qc1wRssiIH /P4Cu5xr77FTZvq0DnKvqHYuACEtEMzfRWBOZws3SA+oZr1s450ul15v0PtxIUo12NCG22VV7YNc at/0AA0Mcp+oVkW1tltPWXnro8rlmzTo9uYBejx5IH+aMMdIIZD/NITT4foN1rKEDmRwQ5e1zJPY AI6S8BD5JJWH/ru/QV73Yr1Ujz/Gc7qy+A6f9nV10pAElNaEBUhL42glzUoOmuht4vjHh/91ccH4 hSOzZnkrJ9D3wvTtdNeM4b9cmI5f9eEn9OW3phcGk1I0avOk7hIuPnP/bRfqolGhLFQyn1q4yDAu i/OQgojwIU6JA9CFa7l1amoumRvYSG4LbKzclvdQ4e683YV/yftr4Z+T5lpybeHaygcqtlXuijxR +Xbe24Vvx41C3SD35322ZTV1DGj8BVUsVP/kdFdVqqESeN5AVYUajsPz5Vc1R5qjG/PeoW9F3q38 ICoJERq1VMi8U/Tl5QZcEVfcmSqraIm0Vs2hHd65hfdydpnIdbPo3Eh3XU9df93OOn1eKq+infCy lBcJxL1JQeT4gDswvfK2yAORdyolpU6ta69bxC3iu3XdYrfUnVojrsxb6esJrIqsLLw2frN4q+/W wJbK/rpXk+8mP458GfF26m1BnyFUIAd9rlC4MgJjTAmpTgQjfEFRbUklX1YQr642uIribreLK4sz SNkaozGGK3XVWjCRBf37GhqrWHJf0yQtVHORP3W+nxoDKT/nnyUkgrUl5Wx55JZqhyrsFDgC77jA CyzTaLFXEYEqAoWi8IYaLRFzcrhZJWaIofAtFvgFgGWbzM2yKSxp256ue4a+QUJkAU4hcLPpgtMJ yJ8nATuQfxJdvexOQzlf+hfco0JwsjMh10PHPd3Vx6okEn1ZZgWGBe6UPKmJRRCNGLNyp5m8CnbV mKwKxz0BKuX5vD5OFGMRMNHKWNwTq6RJqbyShgOxSr6Kllfyhb6iSprSlVWSaH5BJQlU8NWVENLk +kQ9XnbuNkPxjfhBJKB9fX2kr/ecuoDjni4KdRcqpBgOVVdW4GCDScfhcHUIqgPLj7oYb2OsDhKz ncXHuJ7ED9wxaUH/sQ+G+ytnRd35hdMqudYfLbp3+/XD10Xnp++864IXDi9uX9V74NnZL2yZ0OHj 9gcmXnzLkkOzojXhPv6KG0IlUU/kqauXPmyTpIbvTLv6MdeZFb4fXjP9zpkCbBcUetj7OhtodYRy 6kRDIEmTXJJPBu+1bQv80PZDx0HbUw6TPoDR03X8dc5rXHfwm1wP8ffm7eaf5g1m3ipw+ZNxPK1L 6mV7xAcFUXeA81F6mAzybQeVB3RxP08HuWMHcHQgU3mQbzywxbLDwlkG+aSazDVwu6Fn0gp59x47 Ddob7Jw9TwUAGuoVD7V5gh7Oo4GHZ0p08SKNryW6+qYxmfizvt5pJ0/3Mv7We7rr9IcNJz85DSJ0 Eoz5FW17FadPNEPdiJlirqjoM5QSsxOe3qsrpUa3BYbLczuXlUD6ertoTlgTNWAScbA9GOcWhbBS CAuAI8KUPLZz44Q3gsEJHz684d11a07ef/Ora4NLR049PbLn0KaDtOGnd20pdvhy80y6y0cqXz+4 ceTNY4Mj/9za+1jugce+PHz2NTrz6cmuHF+K8XzoZbq1oE4uyF682mnymfJvle+RfyPr1shrcjfI 9+dsc77ieyX/TVnvsTty8wO85KQb8m4LcHG9GPSRUIEU9FlCYXfIG4xbrRbOG8f1X72/frqDZgW+ lEN16ByDo384yHDKMSXMcHFCQ7UapkqY9oR3ho+H+XDIrWGjW8NGt7bcbhg+zDKwUdQyxTzWXtxe sGBsDxguDgPyoRFCAE58pm3K1yiX/grF/HkBm1OO5sYCNv9smueEl28Pzqa+HO/sr5b/xhuhu4Ah 9FZ+GzEUAdYhSQwVYtUJaCXwIlw5O+LyMwyI477Cec/vfn5k9e/Wz/6IVoz88tTcldFxoZX8FeuV kuimkWd/PfLBs28u9NNJuC3gpc35DNaLwQ/2Y8UraY3aoFYv81/t/37qcc/u1NOp49X62d4esUda r19v6Bf7pS36LQZDJOjLDxVEg75EKKxX2YLoQ1Zr0ODTS2wpQyxHCnFcUPRJftnH0TDkj/xKsitR RkrlUq50kPs1WEVJAgC1K9/3kd+frzfsxt3T3Q3SeokjkixNl3j09aHarvW1pmx3SSJYmkTTK/J2 K5Bojvl434z26p7qndV8NZG1rZK1XZG1rZILohFtqyJaZkTbqsj2quOH6AZNVGXbpO0VcKYL1pkT w9iuLliYmDYpfwKOjmBEY+0glbA/MkFRPvkJkT9NAJ+0cEzD76L2EMMAKDowbcTCIabtVzI8QR7U SIYeX1M2hkugcbhHUryqsEqMRq1Wx0WzRt6S47UfrlyemtAYX33m41QqobjzIjNTgtNW6KysiC/R ccMfhctWjcQX+cPxkca5hW4lOWHdyO6oW1YX8b03BuLRkd9e3u60sR2dDOr1BKhXFe1SZxqFSWWc tzAvzske2cspNWpNd801+h5Pj/ea4q2erd6MJ+M1lSbXmDaYeE9NWV57TU/N7cKPheM1gpm/1TRU w0/WB4I+z78KHEGfOxSu0ujZPo2e4fIr4dvUpvIHStweT4EYL+Gt8QIDTQQDZsbMAtryB0SGKYEC u73dsdXB2RzTHRzDxfWOUYfgENgeO4CQJ/ZrCDnIfa6ajPXtMWqLBWMcGOwpVWY8MSaz8tiU6sWQ xyDMJxiCYd+S4Hx9EMLYnkIfy2pj2MQxyjfG2KqUhCTro/HCosLiQl40g7HZQvbxVAnKdilhLCWW MDxZsY4nhkKxlJqi1tIxhYxJeui8OKuUJTRbMWNljDBiLxUmsmUpo50pZdUhJ9BSdNpFMUsmAQg1 sJVmTWDCX8DgZq59dmR4Q++9/+pvu70x2HgRZ/FekJ+78vjGkat/sW320oF7Xmtdu6I2J8fHg2TO 3Hnh6iM//vsLI0P3xKL0tqUNoVisKnrlyIIJdWd/+u99P/qvS+d4ipzhSux8JUjoNcDlIHleXRHS cDOkslULqfFqb2iBfXGNPujjQgWeoM8RKvAGfTQUNgR99lDYYedwlRtGH7ZvXj1bcK/AmnoLDD36 fv1xPT+qpyl9u75bz8/XD+mP6nm9wKrpNezSD45+vp+1RWREzdfIwgKlBxrY8RCfCrWHukP8UOho iFvwe+wedoxtILawF3uXJZvAvAa2zhBEmB+FweycUIBl/npdofJiLblrhp9OzYx5LMZgSSrFtZTP iHktRiWRikaj5cq1/BXLQl6HR4ufvVuLM9yA9Cv+EyuUoq+oH9k81Er0bqvXErcV2YqFlOQ4j56X 7PSsoMs9VybXeu6jDyRf87zr+Yh+7LFYPGCRYmpSiq/x1KTO9/CuVKEnluJFjy7ldvMJUoTUeFLn TnuqvdWphorpFctxv2eNZ613VWoT2ei5JbWN3Jd6nDyS2lmRqfiF+xXPUMXvYY47WnHS/VfPX73H Kz4jX7r/nYriIwf3pORc2umenbzMfY33Zc9Lqbc8b6U+8HyQsmZlVyXoywsVlAV98VABF/TpQ+Gs NBsK+grB/YCMhOYSj5dQr8fDtKEJqWRuyuNOJT2QZjB2mPa8bs6gx3dkqVRhXJ+aB9jxJssKFCW0 M5QJsb06HhJD29UKWkE51oVFtik2O5NDy7VNxA6yQxqwO2YownGKPZ0cwS4yG1FWOYLPbCHpDfox 9UgP7YjpSWPX8pk5HxDQ20t6u3DArPqSMsyKNOvJaY/HnvbIjjTRe9LuwdGjB9xpdyo3nTXRaZdn OymkyBC1MytI5TcBhqEhpV9h4reLKT9p+LQv2p4aiafAO3OtbTiboJ/QE7Q/OQe8NNqeHB5KzQm7 hj8VVp9dsy5YHI1WKX38mrnx/MLomd8JWvLspnMFm85sZrIL06wSGvaV0GsOkTIww7vqqpNlqz2r fKv818d7yu7xS2s9T0UOx3/n+53/3YjoLZTL4rF0NF04Pp4qm1t4aWFPWX+Z6WVC8/xF/jb/b72/ 8+kei9NXI++43428A/3r44joV8P5cb2VbXoBDfqkUBgg4QyFSb5SUpwfbwhPD3PhsOQshuTj5PQS Dn3yZGhRal5Pni5vStmYvEPKqFqWKeN2lA2VHS3jy0qoxkapRrKpxkZpgc2qsVGrlmnVEN26vbRs kF69L8TkHk0F+Q+5p2sa00NiWT0EwclODbOzWkcXTGVpB0ShrLrhjxS5/Z5oPFbkhoIR8cMr9BZX 0qgP9GxMFIUsNGXmWlUOFISC4fFCQUAZT3DdiVCNLpOEZimDxbGPEebE/wALmkahKRQ47SnUdIqs HiHRH/lj06qGn66cHc31QYSi/zj4q62/+3l5X2P1RfnL75t888zKdu66kdX9wZJotDa4ir+CxdoG rn3kqPV8o/Hh/o772nC4h/tmRMhoO/8PtQ4XLbm5+XMDl9PLucvzLw/ok6GG0PTQ/br7fI/pHvFJ HM0PuII+OVQAymsLhSVPGCYh2aYPDXJDag64J1Hd1gaHDWS8HVc9BTLIxdU8vUHbH4O2FQZtfwwF blcwEWAbamUtSEAOzA/sDAiBw/huzTX6iWpidNil7ZsLve9TFncxW0YicbqLbVIAKq2pmnUwYLJV 4dZ6AkcZGiNl5Tj0Uk3VcF8Vfaht5DCINJVfYRoFw74sFwR9/g8kZDwQtvMc4WFbzJQTXDbzOV9s enL4eYZyP5wfr2qVYrJu6sgLMyN1486c/gqXBLM154qLYaHFqjogx/yErSrn2G+0iUEuazXb76IB GarSH5+yBjmXZOUkzRbWIA8fPTpEk8zkZXbIIerSm9KPu6hm4/JkjVmV1VljVklSC9WblHDVvxxn gqdC/GH3Ic/TeZnQF5Luce/uvGd0B8VDEsSoR8XHpSecj7p035e22rY6HnBtDekudS52rxLWGvtD urmuOe720BLxUkk3T+rUzzNeYu106tRQO77JnqObIeqUUJVQ65xEplh1UbFIiuvjzrhLBwAOpcAS j4Z02QMJHFxaQ4rRlecqdvEuycKm6LOKMGbrg1aOrXuXPPzSSy9BDIXACRzyqblER30EqoTPZtWj ctAd8AUHRzeodpckKnpJKoAODbDXiSKj3jhaZsdQQRvMY4STRMMZN3X/OeVSXVtdp1yC66OUU3W2 OzPOU06d4ux29uB8WHAOch8fVEL3hpgNDEDT5YWs3EU8jFUz9GPnmVZm99KBsLPI/2726tSsXV3n fozHE+BrHyP8BqMH5weqIw3LyEcH5bRen5OGBvD2wZy0MZ7Dct/ea9MIP2uG78NwWi/iPIaGKRO6 CyFzicwWTjXDOM4Yq3U/mRytLhopjI4IhbJ3ygSu+JLaMlyqV5N1LTqzbmrUEipfcuYG4Xtzc4Nh WMkMZZGKy85+wNtXleZXmygXZRDoG31fWgcITPOBLOwdNNDaoliuHdCn2hxpXIj2G1I+weTgTLDI wiTrTjdogHgOFL0G0SLh4zqDZDSmxLTksHpy0mY4H7Bun95QhbCfhX6E6keI1Biqk62GTqHD8KhB jIkJfYkpbo7nxPOKfMXxwvIaMZ1XlTpfbJbaTJN9M8UOqUPfaewwd+R1pGaWXyoulq4wLc9b7ru8 co2wRlwjrTFeY7rOfF3eNb51/muU1clbhNv1m/y3JW9LbSy/U9pmuivnLs+2vPt9d8fvSd6dekz/ hOEJ0xN5j/ke9z+R/2hyn7RP/5RxMG9/6mepL/RfmM7mf6G0Lk8uSS0v32gQan1XBFYEryoVlkhL 9MsNfJthanByvC0pdPrmJC9M8e1Su36uCYdVMGWbTH5XsthfFCyX0ibDGNTnE8f4Ol/K4BdM9uzK +hx6yURN+nQhlATIEg1MCQPgM9AfO1fxqSUGv19vMBj9OLcOBPS4f+QjOXm5vpx4ssgXd5jtPkdh IOYrTJfX+tKDoz37fCajMji6Qs1N6SXFbDIVwP7o8+X5/QGD0ciww+nzI8OfzNfrC5iklEqWi5LE SvypciTLcxyF8ThYF8EXWvhSUjKM3y7ugnGvf0CtZjY+mAY1U1+sNFWVKu8v31rOTy+fX95d3qMl jpefKteXf6T/s+Eik+9Anukwp+AQ6kvVpJrbzUfNvPnRuvGD3GX7sogGnfSEVz7hkYdP4/wNED/M SG9WqNKCLOZtsK7LYt7XEf1YjoaL/zsyftMqLcnWej0eSa5nOPoVgsI+xxgwhC2GoLlxnFM2BJin pOAFPQ5TQ5ZDAxk7qRPnpBo6jmFkVlrXUDKnkJ35s+cbmWN4Gq6W1lVPDOQmRm6Nj7w2ciQycmWp ObdlPP3MU11bQk3vxxVnniXH680p4uRIbVUpFShXku+KnQcMjlWFbz7zNL/o7EPC0hvcMcj9qYLw DcMSt6FvXkUsx+LQQ79OFVWuHw5yH1+fckNoYlg9+veRSYJj5AHYwpVD+LIB1znwLTmp0XF0mXD+ ZPDHT2E0ZTeDsBqh6pDgOPOeEB6ZNJPJeFNGT+I/QuzBvbHz+CljpzhKg6ZjNahM/XH6pLKo3mTi ZkU1Hh0lZvy3hVOqyeHgZlW6WBWk/7CfMWZETqtOpkNVanUr05IWSpCwwNMVA5rAvBoQikpSVWbV gE7Nan4+8+0oMg+OvqkGWCUc9673UI+W69FqeORoQKrHzcIk9OEXoWfBjMFI55HkMOMebyaO0CQS LCsxNPReIvGi/OYRpnj51BUm/6ZKzjGjhjqUYLq/4THDQSPvSDjWkXWVt5LNps3VYr7DVSc39DcI Bv9U3VSxRWkpmFqnNmzM1xutkkIKptA24xTTlOq2cU11U86bY1pmusVws/Fmk22m6yYXF2yY38B1 63Hxrr6sqLTqaSCvmZhHhw4a0ua4KY1pDal5ddUyMINj6NFt5hUtWGMWzPUe8AK1yJSe7pnvWeHh k571sIfeEIQdFTNO1av1HKbdU9oPa1E11m2Qn6TaBVPZUCkt7Y6SSovZXFWFhT+LHRBnVT5N8aU5 ibI3WtMkGoz2R7dGBTV6Ksr1R2lUZpWiT3NNuM7mBJIH07iLs0wN+JLpckm1phWpXeqXcDhBT0mU HT03TWi6SrNOQMPtS8AYezIBywSzB0KuGkNdXD4DdJ0ePtEln+xtONnHjPf2NKuTSCSzhHGAN1Pc TsgeJ4+dJJ9fPd4f1uWMq62p5XDOb9Tjik6BUsCJ1aa0Quz5OX7iyLEFLX5aEB6vS/tJrb5KodVV Jodf9lNrAbw6sd7PjBoYCBAbHjNsFOPGDoy9ffjqpBd3IAgkv4EGB0PqrgRh3Hl/OWYKiDw+IGvB QWt6nIK5g1UPmFlwXDWZ0h4FF1PgwMdOqXkm8G1TehycMW5EaERoQGhIs/d/89eJeUZBPLSbWDCV jcua+0WnOzebB9sJU/hx2sdEdxhTnCy/0I427KyssoI7/45IzXnzrwsUvfbJnBkN0RiXjEWTmR3X XjDe7zC6bbLZWd+ztLyO3lcyvXl27dSbr7R7v3NZU3nzNbMjG5cWFJTUlVVUlc7eWhScmLhl5JWb xudKlvrae5vvol313pLu9GR2R2H0DO4oHMJtMBdOBX6Vxfy9Afw/ldMwswCXdblm4jEyg4kHAPyh ZgpB5Kxm1NIiDM8ROQ09GvXNZo8b/4zDkMNECXuuakDLXCfxRQ2mUCdEWmbHangvAQgA19Pw9L3E kPwykBYC7hj3jKELHl2gHWvD2gZ0uhjO5EFGxFkejkEvG87nGIXIXv63p1iW2RyLggqgVyD+EIsd GXvfEfY6JkGvlWP0R+JB8YD016CgizVZumqU2Gp+jXArv0F4hH9SL50v0Tp9bqGlMSeQ2+xxm4ng cxGI3edGUh7UbdVx3bp+3R4dr/vYjAu8nojZLFvaLT2WrRahH17Ggks/skWxpBAdshy1SBZg/1P1 1Zbu6AttY2cbzEIEiyzY3zCOsrSR9jXY3WntnpV2rBH3KrxJiil8QKF5Ro+feD0ms1+PVFAIKdRr 8uF8XfTh4g0gjwG+ZtCDYtnLYLyL9kGiZCY6XHDKwpZ2uUIqxNUt+1f6ItNn6PhbHrjjVz/Y/GT7 rtk2xeMvttKc0sor0/MeemhxdXWc++zQP944fU9/XR1/4MHJeXK4Zzg+/PuKyp8/l/mpLxfy5CTA UCu4R4h+OqAX6Ff8g8v71sGCxgNEV9RmkLpDPSGOaTAHGOMI5YPi78/J5WYh8upBxlHyy/HPVnC8 92Kiq+HFkxqgHGGn/nsd2rnGyuLSKhJmu+e2zNFx/pyZwgxoJTOlDl+HX1qmW6PrJ/2h/b6XlKPK cfKBzjAOXw7O9szyzw93e7r9azx9/k2O7+ZstW/1PEJ/xO0J78P3jz+Tfub9i/6E/6/KaeoRuVbH HMfm4GalP3wqLNkV+gw+OFHggiAYuIvNCHAKcNENUyBHQjI0H2YM7Alt/Yad6VTIElqaf8xGbT9z RQ0Spvf2QG6aBWqtI41JmkK/CJrpdPMWM2dOyri6rZJufMS5lWTweetxYmAZHHliZd5NeVx7Ht2R R3FbEvdVTon4BlQWsxdvdWJTQdMh7nvZWzzsrKyrr3e4t+tErwZWiUTDyZO9OC/t7TvhGEMx44z8 Rfkr8/m78kGPezuBG7W1tfgqll3OgcUBJJsRSCJ7mDx/CuqKTpbTFBsGWgnKOLRXzhI8ypSWXgqT cAFXXUWyV2fZ1UgmFjFrMSNkoG18a/Ttmx78iNL9G35SXjI+YDeFwxMWn3fhwxsXXjCuil584L+o eOxtat0yLZaMOdcEA60LH/7RmaaytZh98+gJQQcKFSSlXNsYbMWSmhW4SIT9EqdVml13DNiIku/S CJbLhJGehvAAeFI0u72i1Ubu56pmblA8jGQp/sO4lJLPGDVS+UEHI11yjmqwcrNycgl0KKmkhIFj lnIlQb2ylCsBAeNFeYhRMSZjfEW+LnKgFS5B8Txr6u/Jp2p+dz6XHzShG5NLo2EuHA+IszDCXBYq MDjD5xg1U5RkWZFWR5scvh0Vk2UaVTuSyBK3xNARqJhsMF1dR3BHC7rZe4x6HiJJqF7nn1+VxAap E3HhpTt5vXC9bpPQn9yTHEpKarI/yZGkq9iZmKWbpZ+ZuFfCh7pUSY4znm+cbbxfeLR4Z1IaSp5K cIpClNBhQLsJXLClXpmuXKIsNV6hXKvsIDuUJ6RD0svFppg+p9Dc6AjkNDvzC12N/kB+cxDNTEKJ U1u1YAktKQnypiAxhcy487tMdTi7Xf2uPS4+CO2cc31c1C5irPivdFUsfOr8arGprGn92DHItJPD fV04o2I/qAkn+zBlkEdZo484sWLXUTUymRdLCPrCaExfpJCEAC8uRRVarCvRCCMzq7JzRwC4Bt84 f2S3UzrBnRlRxHEvGPGY4YxRxiw7duvC1fYy7hwMcz9r6m+99/jn/7V2OihkXsJC7aW2kMtXaho5 VSbWL0p2tMzLXDFv2aTzzrz0Ej1/2uMPaYTyzHsPn++3h3tfoW8396SnL//5q78FRE8FvZyBG2m5 JJ9fNwbRcb0L/M7MrkUQ2CURWDWCaXWmVEIVkAaO4LIVPkodHdJoJYuodjsM1/jsxBe1S+yEkWNn lftZaxY5wGgqPksYfUtrgcirTzFsEMpNJgAQI6+gr+yWH0KcEzKwBjtOHhn6mhnnO/vJTpAjng1B hXKhDSL7xuzJaISBsIz/u5OR8HlENwTHnZIg3Sn8QBjAlRC8SsLUGCbGGHzn5gYDmCeLYrYAezZb BFYXy8KBa+DbLDyBq2AYa9eLXV2JiuyNRIA94+Vex3xPl7ebdOe+xeu8ih9imj/tUv1pWItwDaWp tUofZCyCJffF41Va9ozisiqf6DV05Fzimo/bxPPyJNxJFSXcjtY5p4gbudvFDeZN8i35P+Se9BzI eZN7x/aufJr7F5/jwCUcfQ9mt9HwvPRz2ykJnE6y3MzxBoYnIvCktcYwiTvfMD04k5tpWIhvxzfm bPRuy/mR4UfGQf0BQ8b4M+7P3HHzaWOu/qiELxeOSlwvC9nabcWiZaBqrhNyScrlZDPIcaQd853r nTucx2Cxcvp+zW7UjB4FA0Hw0UDWfKROhnEJa3yxjzIYkH6hd8V9aZuLrnCtd22Bze10bm4/O+Da qudS+i36Y3pe1qs47OrRZ3D4JeqfsDoFspHBFf6vmCNlZffDeGKVrYqVP2WlVjYSA9bS2hRoGpNc oAJMG8b1WQj47BbtScj57ICZIShwrQ/HJUzWXuGErA31gN3UAesBi4FZtbYWRyK0qWO/SCjH9XZq ygEaZSXyQ0TC20zhtFktTVvgcOg2NBBnJjMWMBox4MumfNmysZQxmzJmywxaSrUa0k7Zm/Yq9rQF TtPqvyWld3Z25ojZ40v3GAcDLXA5oyFwL7Av8V26ePGGubeUBp2v3r/r438cfODl4Q30MZ3sXVQz 4yZu/C9WrVp0Te7G9yl952MqvfZEXUekVr0R8tB0HB9fq7udJDj9GHZHSzV+VaoyablU06t9sDZb Raq3FlE9Y2LUgbX+q4r/qAfUd7CcseMJkbEnA3iSUR+JBvClGA71BqlvwCGy25Inh+ShhiO4oZpl SmBJQ/KL8svsgcCElR1jS4fwVQBrg1s7PjW/SIygJ30ROxARZ1GRYSDV5GptGG+rJg0btXwM611N vrZaS0u+YkGQsBNDeP0RcCBmUfCpEzYr25zbYnwz32ye7L2Fv8Wse0CgydL1IfZPFnfodxi2y9vt mVKDLIJOzS+en+D8euv+gP7OAro/IA3yejUYDuwIPIero/ZI1E0T7VB+U8VFDruol4wyAHyQXrRv CxTeQe6zAVqcGKSyaokXUYfNLt9ps9EIA9Z93d1VWlhXlw0bGrJhpFwLVZc/VLXVShmIz7f2WIes R62i1VtyGJ+3SFkJqotprAloucxewoTqegQfdp1gF81guqvHNfGGYWi2oJYa/3FEC3NdsagzFnXF /aQwN+LX7EvsXB2sBifqXRCSvnGMwO5NhKthtK+BcK7dFAMf0gQmaH7OSid9xB+dMGP4vaL4RO/A QMeB3ks76qoC7srWYDBWpvo/4acOP9JfUBKJxJsXcnMn1298dnVzaW2gOnRlTk75srcmTgb4kfNG JvG/g0w+nkwhnfx96nccrvb7YttqeFxWmcetKV6DTzaLxTLxos2K0DBu+rwV41bHeuZtEbbobnLf 7NlSvWnCTS1b2m6dfo/7Hs+26YPCId1+937PK1WvtA3NOzrv+LxT83x5irNSrs6tCc7TPapvrWnw ERdfE2r1EW/T11/qG3Jycg16GB0cUWYfcoAjITK0DweiLIQBydSwI7on+lyUjw7S7Qc6Ev1QtlBV tbC6jh2hPaHncN15rI0WokkIdVXP1lbayr7YaMUN7obWEoY6re25NHeQ6tWcFXq6Xo8IvtaZpa8W tzXRpkG+XDV7W41JL2339uOrjp9yv8JXBgZ+GqlHkVGUvPjPIiUltmnP8inwuwD8NJnGp9SgnKIr UltSO1J8ysP4a8rM2F6qOl3G98+kM9ncLMBtRF7dL+ONWg6rgsgpXIoEgs3Ev76kcTZpHFNXbYnT 6fGe+FD8aFyIW1lNFJ3ezwgEIn9THUw2ja9W5qXmqfN2Ys1181hTv8lcNc+65d5JdJJmxZlUrrio zdXjeh3EfnD0n6qdtXOZmWDg0saIE7KfqjnbGmhDeYpv57l2Ht+AyeyjCWyDN79KC9ErwtOafs8i T7E58pfOnXeYXkNC1Lh3Iw5KcMDGrjb0wbajRU4m+k7IiV6WDR6QvY7ZK5/QrrCAIo0xheEPGYto kNmHBOw2Up/M6oNVgEvsfz10LMSBT/SdPgmhDP++av/r0WNR5PQxxGNqOyjOue9cENUw7tq2OXUt kWp/vttDYRioKK8sryrnxcbY9FhZtDg2OzrTT/3jcfu8rXqaQibSBoWcp2vwk/bSaX5yUWKmQps9 k/x0VuEcP509J7/Oh+q+8WRqeatC21qra1SuSQEdnyDU++kFyQv9ZEbRhQppcTfhO1CMMmti0uxM WWPTuVuhrJBdqGE/3HNjzK5XMzapxjIZMFqNY/8yAMRenP6jaieNZb84dGsXaZieLobD7I4odCjN DMRMRNqtUabBs8uJ7NbNOK0VPfeZBPt+ETrY2EcTLIV09cy5R3be1P1CwoovyXhb4uraF3c1n18S DKX8Pb88r2vFZQ+eef6WNpO9WppflUhTZ+vi5qr2qQtbKkc+T6bqFv90/5OVVQ+8Ty8ouqvzthdV nWhw5xl14uSe/oO5sXSuXZEEXmew9FzUu+jOORU1Hk90omFRsDwYvoTbsOba7XMm9l27Y+7EszdW dkRTkQnrJ1e5XAKYPr4NIvy/oM3VcFvGeGN+LZgeN0s22o0aIzR6Iizt0Y53YRb9XMMJRI7jiyxA pcfKjAYe3KD6K9ASGbFQVXVhKQ3h8yAYE7Q+QqUe1kfp4OiX+1kuIp9pJitEsjiGyCeqjTUv1for xY1lG/4j8x/x34f/SKJwcbhCUgXGa6vW7FjVNaTQnl+CYx98ZJFkVixw3U8+AVCO6YOa3Ul+8eUK HBgyrRB6IRRExoa/0g07qoDW4qxqzccbC6vQKevSXmjU2K9RY7lGjS0bxyxdWtaY7ctTO46GtJoh LTuk1QxhNqc0yy8i+PepIDaInH2KMfHS0tpxY1xbY9pjceiQCXa0BzUS1jGGVwBin5qsVYurjbXd kJttUVusv3ZrrZCpHao9WssnRNpe213bw7LUWqroPUUBnBjiM8KC0qJAYWuBsSggt4ZDRYHYIG9V y8LVhWWNVYHqZqoU4stuNkuIVXa7bPR6IoatRpoxUpuxx7jD+LpRwGnVT9VoKQlFyoKl7aXdpT2l Qn/p1lIuU0rZ9cqh0qOlQmn3uEegHcLQDCLEJEtIoCz86hDpJL5VTGftZ2zxNVKRm+fX4cDEF/Pr vH4cO+dJ+Yw9j1nKNMMwbnFrh692xo+zJlmgXPbeDbAN17c1aVDSVENnqHrs5iPLhC2NTlvxncYL enw5VmNKHZngVCuMfLA5VX5ZqzM9aaTuvHCuxxbMcyat1KH77vDCa1tmX6w+MfLMHNjZIpHCmHwB bb73kmTV9BH/JWXBSCTHWDubPy+rPbKTmXp4EvDFRAq4sZOZQyQCRpDPRESHRQN3S0izZIQ8jHuE cjy8ARxEo+WIHNcAH5G3NERC5JcHGdwbLMCpLMVH5I9aLYZlX6HbWwc0bFOYOcQ9PbQitB5suGAF cLgbH5xrkqymtTNsFAvEHEiDb4GoH+mS38uqkgB/DQuOACVAMxNABHoOEyyKhgMhzWf97G9rg7GD RRobsxHVO26cOEtlpq6dIsdeSmBeKJBy2PQ+U/0Mk3BvN2zR8MHCMbC3aPjAZpbFB0Q+0/CB5Wj4 4PFEwt/AAS16BGN/70jDEYCTBjcaKni3Rmh3pCeyNbIzciqiUyLtEU5lXoQxzoqKKi2srcuGOB/V 0uGoFqpl3rwqIEhOa4GlKOAAWhR6G5VAqNnsNedsxVTShBT8n8a+BcqN8kqz/tK79KjSWyW1pFLr /WipX+q22o1Vbfy2GzeYtt1AYxNMgEBC24kDBox7sgOGJIs7r02AbNqTORmSyUkwtjEmHoYO8bDM SRy8O8BAziThZD3EBJt4OIQliS3vd/9S2yab7G7bVXWrVCqVSve/z+/e32Xz+6QZVJs2SAfvv7xO G11u1k23uVxu1Z2J6OUGbhxZnIGh/pkIG4uwzZGpyAzKgc9ELJH96f1/y4cD3TbVkRP48LRhpsId w1czoiQ0FAwVBVY3wsKXFK75L/B1G9Db5utiaeHCUml44X1qz0jr8surMYctEe0oeFjA8jC9MFwq LWylzmnrG2Dk6PA4u+ErFU2VM1PIKtzYWsb2WPaAa4vsaFvOOwt+7gT5k/T7vXeQBDQniJFBGIwH 4jXdb/CnwdsSMbUb3nuLvwXEKc6rIP6N8yqI13QHvSUpWIt54ldXAQdgPhVDsZ9i1ofTxyhqp7x6 zBDUkH3zjFl+Ab7Loa9HmVVlZXrSzcG6u7wf4k8vj5Vnyt/2fDu+t2zVsDNdNik4crxsitoLeW0k nygsUekrWcf9UUdJjWlFly10mHmQCUH/Dxs+WZ71M9QG36wPl4yfWV9eN1XL4XAUv6/BtTz0R6MY vJtJJmc0JmuMqofPaCZNo4sjXvk7eIw4QdtfKv/3FP3mHKBGwg8ZBHAsGkssvWnJm6Pv4deHsQX9 1Gwakd591mOxg5zfTm+bQEnncLu+1VduF3RzIal0JDxyPNshJztYwoOsAkqFebEmD5XBipn4UNWj 99IUFgK8H+abQnl4uAz2mH5x77Ube1LRmPeGVKQausg9e/jLpfJwSzv70bdPLE6ne922DdkNXxA/ /9VyinMQQ68UVAhD7g2anmvzTznK1b/K1xrGuTju5WsD1YcjxAEhWsM2OMl5hAi9TKyRSw3kq0nW Ng84wjdl5QZDlev/aoj4EbaZYSeAMOwEEO9As/KXWgZiu6owb9Kck8LRLCx1fBCZ7EdgLeSEOnjP N8CthYFBIafiZ8ZtusCSh4Btw3koLP/Vk5IVv1D5dLltRJxDqhrpqvmEGE9fledegNSEHYGhawQt uEx6Rm4kG6LPqjD8/5LjK9KMc8b1mPyo9zHfo8nZxgFJaqiN6CZlk3dT8nblDu8dycdEx9uJ00lx 2vFXnhdML8hviW/Jp72/9dmbXvScTi7Qmo1l8jZpu2yviSVFy2q5WgOZAMUWVMbZVcrVmjmtbGAb 5DeV3ymWld4Vyecdz0v/U7KEHSElGU8ml4qLZavTK/vdUVdcTniS1nWmcWRjJpSrvVf7raocjyeS 60RzO/FQG4CmAiczxSTl63hG97qY6x6IQAmoUZcLH922bnhQMIWn/ya3a0Cc4XIcxB+4HK9WGwva chx2DU/3kT1zDAqImzS8wQcsmnFFZqLX5/crajKaUKswVfKdkuhISGSp5NMD+dpIPTGwBD1cnZA7 GS0Z0JioJWEbdjMxwFBgqQla0s/MeVGWFCUioQ1N+DA7pa+JuH7idEpWWDWqGpGc3a5pl3jGxY67 3nCJU645yumEw7NAMESTDdaAaSNkajWhqgCfSuBUy1iVTVdn0Axl84LGYXbXgdTfIcmOoY2KfQxs WJdXKNsIg0wRNETa5s0chNxoJKv07WG5EeMgRoFaTQOrBlSyQQg4IdLWALxoE2E6lG4CVaMcPWqz TUApbNu2lVI+29rwGPQd3IrEzzOCgmETgL+SLKD3A5a4DsYryA2R9JSz4aSNtyEbG4hs2kMedu5J lN2R6TXPshxE4yWfBRF2A85ms/m5T0P2FQRHfx6hEaMalBJF89YWGVZr31rlsqdy7OGrPj7y9tsf 6ezOqItal+dihdav1epoq7osHXTKHi0aLHmZYnn47NQrS3wuVyCO7IVYXfh661/vSdU8UibDgv5w H7u5dXxiQYRlMl5nOHWlafHs8pg3PQVr5jJYWDIkTZB9wZA0zwhhmBfcvgq4rMzWjs9xmcG4zGD4 ru/O58J/wz0MHDFMKBCvcoEB4hdPke5yWZ6FcLBjsaHF8690p/9CXpwwnj8v95Ij0fYhyC6Hz6BA L12wlfJ+biUFAlzXIE2A+YfakTuuRBhXInRThtEDgoQXT40bRo/Lha4lPM4Pl4QM/ybPGZFMeXom PBc+EzYBiT53oLmsn7b6UGNhPwvvd28ZGAszPTwW3hyeCs+E9+JEm6uYsK3qZMWENZ+eT5TjlmxW SWAZNz6bX4a2erS+sH/GxcZcbLNryjXj2us647K49ocuMVsM8705fKG7CDXl4fEznr7+sG0yb3Lf o/YvbzWb1agnGYkWUOhsefiPI+sXxLkdYtIfW05JamCiSItYuxEF22D6l7YWCU9wb3OCx2DDXm5i eMfXdM/LexC/4T8fHdFlMm67y/yscs/gsvmzQBhn0RE9RWctG1k+ws8b4YwywhllZE2A1Mqa+feB MPQLCOMCIP6gQ0/gJIkus6bM317mby9jWhRgrIiJBnmZEPZf1jn6ebCDLox9OMH07kFkD2lN1xj0 8mt4+TW8sB9OGtfQuukc7D9vXEMr0TWw/zPdSdegDCTfPwsexXW0kFrrXbqCDCpt+dXjOp1TG2dr x+8Y3zVuGl9vXd4TyVacAGRZDGQHyvQpK1k+ppyDSpubm/eLiekMh5hc4nmyzergR/A75aLKiFqT l3AhaK0P4/K4utNmsV09vt4W6Vnu5Rzv1XgCVStzJ7jMj5UHR/jeCN8bWYPv9RuuKTRtI57TB1yP cIKGBoh3+auDgxvxG7zDxwsIYwSB+IC/umbNxMb2wEFeA7dIawV3zhd8Gegc7jsgvqWchkTd50a7 wucAiTgpLMVSw9J9/uRT0QgKViKUg8TfREzv6Lcdn/htyDSNyPAEedvIKM5MwKnWigkUtpw92DlY TPSA0J2da4qJ5as6vcVEGH71wXS5mAD8y30wPVJMLAOhL0qP50dHrk6ML7EXB0f1RrFgF2zZ5es3 0A+Trbgkp81qttiWL+tBpYw0AesT5bupbo1Nafs0EYnZui4PFqvlzILuQTY1uG9QHKRjodENI5k1 a5KjY6Pi9OjMqCiMKqPiKMb1oUCof3TzxonD4jXQWbsih9mW+7lJ2rZI4YeQX37C2AxfQbYplBf9 EfR1GMXdpMC4yYOHO99ZCE+37bN3osDRnU3nMq4UIF5ypyd7qc8OLFcZSAUCtwwaLvufcdzbuoRg CFabLXxRjszXYwOdcNGj/5AF28fGtvi6bulbf2/w5odXr9yaCrmlgctaw/6FqbBkjuXX129bI4rB oWWtnjUNpyVVWTtQX9el9qxuLWz2Rrmdm5dZoCye2iLnSls23bV69fjQva1Pr9dCcPDDSto7xj47 VdXrK5zl1mru9UMrXYVjPXq8MtgKXjMQy2RiC8fZ9V+tzNvDLsTN/hckWZ94QZLVuSSjQLQ43sPX HrscSpNIqNKxdDxTtHOR1K5o4/LAHuLhtXb1BMdFIG5sGLsgDAgniHf0HI33kBDnwiTOLxTnl4gX eXStyA3n4ryBDIJMNHEchCHkQPxBl+gqRaFDzIBrf6U7erhn1tPrppYgCpZOLIi36Y6MnOm1RSsG SqxW48E1hWPFPhRhQ4KaOIVLEpIcR/nq0lyXfn0tRKrSiNH3cJrfQI9xfTlj52ECO5cUdi417CEO vwjxQyEASgDPCAHSEudnxvmBOH8xzr8o+WOcoA8C8e7T9JZisd7fFhf/z2AbbNOhOqJt9jqN/+76 WH0zSn9n6pYuM9M5PY29fXXrvvrxurivzjbXp+tzdVPcHiomZCPwViwmMqs67cWEZ1U6XkykjcBb T7400p3oWYIpgXr7+BPNpNMokJDCoYxtxs722ZmMBPCs/SXMi0OBN7Q8iGdKyeIY+gRNFc3TxZni vqJJKCpFEV9tTndgwBc39xvBN8oA/H8G33wR1WQ1Z1VTuIOh1ZYlOj+MER1HIfjkVkIb8djbX4y8 IcZGqbP5cFw7GEcYNrb6b764+nYt5HH2LG4t9Ot9knlk9M5POz00EAPLehB16zDG4ennV68fvre1 Y0NS5TE3eS27c+fWz7Tik6E4RtryLezqb62I8sgFhDbwkBhnshAXXW2boQNmIA0oF0cNtX06hcDQ rihy8e9xe4EI3U8Hzfw0cxh4aSULm48ypFwTtsNhF8EVDnqdzovSm2PEU1FzgHNcwIXqYFhwUPtY 4+KwA4g0mxMuV5KDJLgqomEAXcQ/hNKwS33TQfZ46FAI7fwdR+OvO6y+X0tshWNpaEPwfvZ5x0Py 6zFbUu+tmzk4YjbJXgj+c1TUk2ylff5ufPi4Ob0M+38tWNHMjtN6zLzZPGWeMe8zW82nqGVSU3fN wsW5gAsgXDAFZsur9xUwycrYldc86UqsfDJpXokOvc8SEpomOKQZJUkFXr7xH4SoqRdlYAFT71vK W7FLdqEdUFzH88ro3THA4r6sJyei1ZSUtea8ckAT4iyqsZADVMQGyu9WNBYzYRV0hjVBtWBFEoL7 IkQgmEFIYPAauA74A927XdxuvVu623O3767Q9sj2DvvkBBwhOD+6o0PxNmJYgMI486TTSNRA2Rip 2nYaZmAg3EkZFwAGyIfJicLx+2779Eu7Xrr75p0/WVe/bfHsZ26479blpie+sfuJe85Of+tz37vv 93eONL9x74utX+z90Xuf3wyn4/zvW6tMPwCv5YWG2NnmteJCjrfvlUpkgVE6AOuIXxU0U9HPZbBf 43B7mDd/4DEOEGe53AXRRuFqpkLZZ/ZYowQdQNsl3Qnzo5r1DExYbTw+hhI4io8JDNwJCYt8BjIa ELgXoxDAEQCXC+kKYXvsoi/yjNB7/uxTxIi9EvEkEHXWcUlaOIS743zr5zLSj3shHcCjV+/oMe7z azirYPXkUbzrwc046W7oBuiXbipGGoKKwPCJEJ7HuUsP7iauvk9aSFCehrJSuVZ5yGt+oMIWVpoL V1eurXzM+7HKJ+07vDsqf23/lu0t++8d7u6FG/sm+m/vN+sLWc1uKhR9fphV6gOdfhhX+bSQT63N J4Qloq9cMJmrygCjOxFR4OBxqhFPb09SmpHEzdK09IRkkt7WRB7Ci2naGOCdItLTBPc0Soktqc1D BOhFSgJCkdC8BpZ3GN+IIrDzcLVy2eShrjXojQSO1mp1m9ue7c+5ct3Zuq1XYzU3Vn2OAY31OKsa JRnbrAtBSf37gFibmDBl+4Jk6RBkwEgH5ufNmr4QLKF52WgxBCbcaeJMgrCJLJpbvmftZ6/b+uDU 368aKPSGG6tbmjqYR7uxdCKSZf0Oz8fXbVl05XX6xu5axtTY9uqOG27/65dPP7YrKHe13rq+L5HN spCzZ4vpIxPdEc+u1t/fkR7aeMVHn/kfW6+I+MjTQl5PfBq8XGBPtTm5UOKcbE2GvXluQuQjSdZ2 uC71TxC+NawPEIbdAOIdI4+d5O5TkhsaOAprmMZDEtGjSEilkFsEFbm/0j1r83fkd+VN+YIt4gKM o3mM/BA09CMeujQ7R+CYF+bthfmkXJoul8N773DsQpM1XCBixZ1ydvZyP8OLz6bBZh0H8RvuKhDB UTHJZKl4UeXj+nCuj7VjUJRWQ+UJjGy5V+yVdVGXP2O26SW2qcSSxIvcqn8gnUc4OZfILxEkZ8kb 0BRmjlATyoaC4NgE+rHaYLdvsjKkQqzVJObGEbwIFSc1Nq3NaKKgKbDj5wB1tmibixRComa3Rmx4 WNkGFDDHrSD/fnoSDMnLLNvwSZ4YQPMisqWDpIJ55pmzzEWt+6dhmTWf3DG4oj+T3hD0Bbu6/e7F i1rlZZ2qZHGno8m8xIKmJ37608sr+YGlgeL1rZVr8lCxmRC3em/ce1kHqVnwy5bzJ8RXwC895v42 v+T7OL/0oepCHBcZz2gxntFicixqz6O+TRzPpxB0eoMrXBDv6b3ED3KPzZ6XUdFUtrAdFna7hVmy NcZYyabemWA3ovdZVouyzSgUF6M+IB+BJYSmqmGLzSTiZ01Sz9DOx14+prxsyLsLwZfelJy3m0uh hK9qEUs9NuMyqm+1hd1mucciWrIl25IE25L4FIBLWZ+T0R2+qyN7bR2X5b7eqN1DpD0PTJd1PJ/v 6+XcgsywsT0KTTcJFObkJKJyk03lKLVapKAesU7RUVEros9X1Z2NCqpOIoEJ1zW5x5QvZyySDSUo xc19U33TfVa57zDT9N0QkT92/9hzNHM0+6/pVzOvV940v5l+M/NWxelrViYrn+jaWdnD9oh7TNPB 6eh0bLrjoa49VTfg6aKEBk/WDqnyYuc/p+0dplDAh858ajFWecTxiPSY9qX0lzJOX9ldqKyqrO3b 1HdX8a7KA55vp5/oO2l6s8NVtPckhGfFBEuyGm9IV94vPIty+qjuLUUS6rOxRDQZZUpUww9wmJX3 q88iTxLVO30+ZO+cZjnPN5YE+29CtVbqQbMkPNTofaqKOcqW6YFQjR6s+BMfYz4CjPyW8ECmgO6c ol6fU+hgawIibkBHPxi1mgTmpzKbZ5vzU/npvEnLd+fF/A+YJvQy7UkDwYjBMXp6G0BdyB+fI6zi +RSwio0atP/+8wwkoRlP4HUoJsqqnaAifz5ywg3YDhKs6YzbGXC7ndQgj8KpE2iLh84sCKRSVyqD 5qQR9j5Y1RzufqGMkCvEf0ehmNQUFPokvXBvrUV7B4YwwCq2gqWDGaKf40dwZ7rjj7b3lfe9fyyY kYPZhvgsHVRn0fZ81jTrfNQ9E5yJzsRmOh7p/Gp6tssFIwauMcfvb9SdmHY387nKY5nHKpZJmqlO 9xY0teEoqA2mSw0RC1Xr7pcaMD/ndFVqVHGowhfUrCkJX9Oj0QqKHrhLvlEbGYSTAD6Fm0kbFzYo D6i0K3/3+4xroYiYoexZxFLRfPSeM0gY4zS5YVLc+Bw3XeCM7nPjc9w4Bwu6YtBihI4No+3/XEMt UmUVoiZpnpQnzAv62RmIGRJcaW/ffGkLsuu8nXc4RG2LxJlU7s7rlq3Xkpu++ONnt199eyoYdqdS Hd/4yNINN7R+0dX12D0Do31execyPdF68UsfW9W1oFCsLr/xmzsfSUhRtvzzD1/ZWHr9zFBjw9av hWVPBDIscP4/xGHzD4UYO9eWYdm47oPZFkdWUBx3urib7Ar6mcXPST9XZP55TAuI97gJB+KMAW7x O+0VORRA6zxMvoGEd/PYObTCPH20HUn7+Xyt1MUQmRqG6w9nla+Dl9D4bU/ymBd+XYNQQegBOnsK tchyjAVvDbCVwMvRx+lgRXy2M8Ys3ISzcJfXwrWgBTdIWTBkOnGnXP+BMPIwfn+846L+K3O0dvPc 8cnJOQWJ/8n5zDN+VlQouHEDI67GJrZJFJvxR7yPqM8FnwsdVk+qttk4eyiKUpi17k2uTe7fReAv BiN5tHQJRtSoidEqENvLTMHu9t2autHax+qq002HXgJI+rdo/H5TIPYTwUnZmYoG5Vmtxfeh9AJ9 58xmSyYw5mfTaJvvV/z7/HP+4/43/Fb/5o7vAttmGHC8GgstgtFLFeE89MBEx7kTqFDGHl5CW9Uw ppcIo9EHknIE7YJlto0qYLx96AtMpS7ojUVIYuCzgPBE0R96Xa569dW+QmqRN5+eXlLdWPrC4Ce7 wkXzD1v/suzc9ycWFQsfubFv043iLanQrStyN5FmFOGBnsNch1mxu81VoTyP9ECwUXyWObVCO27b toe0RDtue8LInGtRfmLUx2PE6EFlQKhAGB4DiPc4uMOXmXcQPJGs1al5ItZ4xQPAPuTBU+Qg2CUB mfNjsGZhRyHEiVasNCaPGSFcqn+56BroG2wGsNxklzCVesQDEC+ualzSyezEPgzJfKw5UzEtCjOQ PF56JSqReoz67PacxjlPQ3stuA9aDnf7Luc9EAaWgwgenfX58rk27/HoLFYUl+XB2fIcuZBNMCHH N8EehBsT0+ssT+EWLU/6YV/e3O8cTA5pK5IrNEvU7l9L/kFqbSKbT9vzbMSWsC/RnNm4/TBbqvsl VLVAJdEj8khOyelM8aIWD6bzwaTGU2yWvYQ6bg5k8qlRRNnG/DN+cRorTCNMTKe12Q5Ml3veKHO5 YKdBFSGoAm1DWT4ERwn+yHvLzOOZjER9rEP2dsjRDkHxxpQ4ql4JyUTlLaj4I0a8WL0yz4cAL9nq qTZ3AsqUr5tuROVKMu9pvdP16XuXjm6tdAyuYCMTzfLHVzeuMX353CuzvGbl+enFE5+fZo+M9MZY 9txj02MDa0TbFYNoIYG8Cnj0NHhUE39o8Oghh0OI+qy8z68XdrmGRUSqG+haVJ+dOtVEppI3MWnn gXsiEjrrORydKbzPGeAhuoDf6i0RL3h9VpEfwfjWOKHRdY6VL/6nlvTwFH9+DH4j/awO3zppY+Ra Fe2dUWPnrHeSRrshWA+ogWja0SmlvJovE9FULTrkaEhDSIzW1aHoKvtKxxJpaWSpujJ6q/3r9kcc /zX6aGy28zvCt+3fcnxT/SYaRvwjSjcOSYciT6s/iB6JzXW+Enlfej/yx2jXrIPRpxzo3dzPt+Ue Y5soGltUYvHj+byxTaeNrdfLt7qudvTLnfcKaPEjTlnu1f7Kcr93T6djyN4v9aPu7gXrXOq1qO1B 6aHIbtU06FsREf2RQMIvxLSE4JO8CYyCB9AyIqpqEVXtdkgBdI6IRaMZhx0UnyANk14nmN8Hs0mw RlUn4vRQT5skpkgZoO4OSS9LFmmnA7D6m3VFt9b22p+x/xTtz3Y61O1RKl/XBAe+n+zrd9D3BFSY tvt767R52lUXHHNwlw6z5w4pnWy603gaOIu+9SHZ358iwaoC7bt123uTJDai5yJvqhCrkfeip2m7 LQJDq91yBalpSFa0XSdz6v/adwUahdLhdEH646xv9Ft5StLQwwHC6+TT2DoysJfhLMBKQajiDV3y N+waGpRg4c41x7hQDQi10yLwrN/PHWbez8GK7AD1fACSNu9lT3Tki8FXXg3bnZ39rNwfSHe0jhRb z4QKSW+v6cvZnJbubllF94K4xyE70ZrYm1h29h2TZaCmOOwYLe7zJywHMVoqpmPt0ZJLJbwesUIB cY/gyEXs5kI2aZWtxObNZq2GuAHa/sx3WzHGDJpPQXsuIakY6aC1na/hJ2HIQLrSOpJzmIUCv/gO VN8J21Hs79wO1LnTuHql0pVKVbto6EBW0mc1J9GC5+eT/MPIyOVxdLIufEBaAG7erIfycDC92bxW 3VS91TFVfSv7VuGD7AcFF52w31/n570YS/anqtXiloG4iv57aaVqlnLxXCXXyI2HHw8/Hnk8Z3dm BzOD+bXCGjZqW2lfnlmWHy2MFh+0TSvT3v+cfbDwYHG6+qjyZTo5e0R5JvtM4bnqi9kXC69nXy8c ryYx0w4KSs1hR9aWdxSsxXr4cuVy75jlKtv6yFXFh5x7lAcjD6kPpR/MPpibroZ3Ox4I786Z3I4J dqdyp9eMMYFfM5uVmA2jQgl7E4qWTiU0oVhJCLLkSchJNZGAW//AAYJ3HT6/U9cj2Qw6Dtkdtkyx ECgWC+CGbL7b7gigeTKsEzWYkbIBScqmM5nuiBqIRNRiLo25CmmCQgm/wxF2CoMowU4dSDLZS3uK 4IFtAi2oKHDgNUGkg5gLA6dgkEaOYMbJLGY3+DtdLui4WdR4OLWz8k0Smnw/eXBOuKmIaePtehAt 5cZUtldlz6ovqb+E1PtipobhHXtak7PoGMF4iQUw/dkjTAEsKYgR7tKl2qYc03PT1H2SnTro2Jmv 2X+AYW6H8SehapJNF84URECa5p7CWwt7MeHAzXpsrMimi4xyARomE9hXnCseL9qKm7suWE2ngerf qkZPnzsBB2hre2zjUBQHoN4iJ6IwpWihwU5qjXqNQ8ORiWWoOW5gkboz/KwL3ZcI0WKfFwecmD+C Oe8v7fXyl2i0xkQHGC4wEPc1kg1laEr4Qk/lqB0fOSZUigJr9o39cerGd2EToL0z+8MNPMsz+4N8 78mgITpI7hiSg6Pu/X5ICQPeAg5tC5L2PkubDDniZtNQw0f/qT+SDw2zgysSqAL8YSDfYKkNxdZP i//e+l229bP4gmHIE3OiI1k59x/se7uHwx5UEZuQMwwEz73L/jig+WkmFfetZ98WV5572iSu7EPg DR2dkB38NSTMAtO7bZvRlZMi/Tlzl4BL1SBnDnb5FRFTgv/qkNCV8BqCBiFfai7GV0bkl1Tpbt9S ie1x7/Hs8e7O7e5/1flq+Gf5n/U55Cri786MC2Ax55u9to6hqnzNgLnatDSVpndBrllo9HcPrXSu VdZ6lyVW5tYUVvfrQ+vV9dmxoe22Xc5dyi7vrtCu8Fdss8qs9/HIkVzCY5EV2StXkkrSm6wUpWK4 NiShT7rjmoGxoXnEWAb3vQOINPoin0aTx2quPyKZhSp9h0Q1Hm9Uq0MUMeECDbn4Jn0TLtHmjDV9 p2/mMDaRRcr399clYB36YH7YbGquH5OO1rO+PaEaQCR1mKUhV3ynOoaIEebZSO9Cx8E9aZZWswCb 9XW9Wyzm+8bwtHfWWd1isWVVmy1Tzwbq9awrlM9397kCfX0uAJ0iDle4L59VnQtquYhkcvXb6jIq TJL4JWpV+hmgwL1e0spVM8rZuhKJuOSCifnUHSEWqqIMynNAUxksmTk4hXVd3ae+oZ5RzXSAtLF6 RBxAT1Qbu3l/vZqHPDiALsd9R8QfolZpSBw9kDrGi3XQABgR0PJkeWt7niaMsMl5bUtl1QhXY/zx vmvcscFzo3gG77pEA40IhgZmO2uRU8qJSXrGmHUGD9qH2rdJHFH4rnLvKVA2uzKMWWcQ5d559Cht jtqP2rCx4yjCHiiG4S0p5gFmTowpiXBkHzztQOEuogygTx7AFlmXk8jBeJtupA2aUOAnD2CHtrof 3QAtlHmyUZumAaKG8EzQtbxZBDgNVzhzSG5kNZkU/mv7ZSoHfQObXmwOufGCmx+hFmc5RCVyqArN YsH7YDJyIwHxC7IVgGbjJkPM3VDwALxYwghlKIrcwDwMCJEEG+QIQyogUU4b2GJz2MDTPqP7g40B e7BRQEvPIhavPdSAwfSGHgs1iroXS7DRSws+OUyfjoXePg+dI9ny4b8/jYi0UwNtlB03YIxSoHCY Qv4X7BcA7UI0P5ORCMiTaOL75JYOUoVrjD1RTKWdoZHVKzpzbKAn0zO+88TVKxqtsS4Amx/40pKu rtYrmVjumrnvr7ryMgimjnCkV+m85ZYbo8E4xFKkc9vjrcM7ekyZTMATDk8ePXqtN5IXMxlLIH7n +bO3D2KsuFCH+B4kU++FDBes03LJJNyVZ/k4PAbYL2gRQ4LJy0lqQndI5KRIZC8ne0EazgRws6fw r1k7RpHbS32KhKMsxANe8W60dhVQ6WpN302fIQcCaCDc3zcvI+AJHoVfSDYPTw/0dO9TgNl5Fm3x PhDU82eEKNJ+koIkJQF1vuugui1P+StF0d9fDW0Z+E+W+62iw2Hx2VV71FEORHOOjC+DHgQLGOa2 iy333eK4RbpV/Wj0xtgtlbvsO6Qd6p3RT8XuqjwkPaR+Tfia46vR/1I+Ihzv/3drGjZJuVwplSTG LXWVzPtKb9u8z9k1NRrtLkkBnFApl7lhXy7hLaWowyzZMU1yVIWlYU+3Tfw8uEj34G7ztXQjLvcD 6IPJbux6bI/EfimdoZTWlPRbpLR2Nh1rHZscJsdOOLYePV5+FZhzWZtFnmLPpgqrVZoVsaL29X+H wD0E7EFH6hOTW0+cQ/N9WN7n2oCe0XMnyoZGpx+CxC41xOX2O4kPKG7y0f6ior6onDFJDXQzNOqf N8W5Lc7d2UvCeYPUIRH/XOy7wa6u1C+PeW32zjIrZQsRh9r63MATVy5cM9idahSkxPLMSOtpOaUq 4T7wcD6eX9rqZX8oFnwOpxvGeiTlaZ79xP0PLqmU+kLyoolZ8UCymnYpLnBvEXr1dnBvkH1Hr/ns 5oh51jzrnvV8x3zYbJsNM3d4u7tnYEzYKI8FTTFz2OOXrzdfJf/SfFy2tT3dAjOFQyZZ9FhcSBnc Y2Fjls3IGnS7rEtk9imZbZLvwCyF3aKEWBOEJF/hseE/z9TAtRXeV5SRYILCWhm912I5KCWcZjSf z5jMAZPJbHKKZpm5PGE3fYp5DNmPbjcAC5sQ1weCWZKPiIsED5oyLdIrJladxdeqjrlZt1tHwyKT O1oLN8Nrgf90VdEVFZPAqqHw3xgqBEjk0fdO0AQMYAB0yEQgnGaGovpnWs3fI26VSPhuu3cejbT7 yLc3EyT6ESRDfAJG1zOC5/xx3QEpb+rGisMM3CBknfYyIUIU/9uhUMNcCBD52iH0OphCB83D52cO oc9BJEjkyUNBkDInL+meyWUmROUEQ3d6luKN+9KDqSDD1GYQeKbrnGdfEze3Xr5h2B8zF6wm4dyj 7IpbV4cVJ1Nbv86YSmq6d1Ure/bldEW7GclMzAl7s2kd+s2HhC7hM3oBFePmSDgbSxY67V5nQe88 FPbqzkNIrwsmwLyjMu+yRkXMJV2ODe1FBvdHsifpmcZkO3TMYR56AqFWtVo7zD51IEVzQNLIQpcT 6tV/brI9qJpAe5OtfAkL0PPFYwxeqPC8kKjDeMj++cNs2cY1ksPtrviKl60avPz2+8Vrb0JizeWs hIqXjS5Y/LEHLLcVq1sWpt0e+bJK99JPjW/5Xi43dN2iDo9HWVjuWbFt/NbvCefPzz8FZhIAezf/ rYDvTK0fRYGJJVMRPvQkf1ato6Z1As3RWRM+p1/29djXq9+pHa69WHurZr3bsz38Wc/9YXNE7UDu 3yyn7CVX5FBJzziNaTt7mh1DY11M7kqivZ2piz/AvZDcP/rQfJ4HZLW759JHR7NevT9J+XZqj38C /+lB8UHTfmKYpRBB2PkkOG/20k5yWv7C8U/e1JScbikUCpWGRwcX37ab3bhhVEI5ZijsxYMcWHL7 /a2jpcbkZXhMdvtwuXvFtg23fj9T6rppYdrjttsXlbuXbcejpGfC/86nhC0G9SfrBdg3oT7KBaTR /MzAASGIJ2jM9Htxft+SUEEpeh+eP8w7YbGwRFgqLBOWCytQ2b9KWC2sEUaFK9BzYky4UrhKWCeM C+uFDcJGYUK4RrhWuA4NLw8KTwn/xD8f3Ycx/OnPitS5MHrFusXrJspX3/rxmz55xU13XnXHx2/4 xNi6UbSE/N9PRFaxCmVuZHN0cmVhbQplbmRvYmoKMTYgMCBvYmoKMjgzODUKZW5kb2JqCjggMCBv YmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvUENYTlhKK1Rp bWVzTmV3Um9tYW5QUy1Cb2xkTVQKL0ZvbnREZXNjcmlwdG9yIDE3IDAgUiAvRW5jb2RpbmcgL01h Y1JvbWFuRW5jb2RpbmcgL0ZpcnN0Q2hhciAzMiAvTGFzdENoYXIKMTE4IC9XaWR0aHMgWyAyNTAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDI1MCAzMzMgMCAyNzggNTAwIDUwMCA1MDAgNTAwIDAgMAo1 MDAgNTAwIDAgNTAwIDAgMCAwIDAgMCAwIDAgNzIyIDY2NyA3MjIgNzIyIDY2NyA2MTEgNzc4IDAg Mzg5IDUwMCAwIDY2NyA5NDQKNzIyIDc3OCA2MTEgMCA3MjIgNTU2IDY2NyA3MjIgNzIyIDEwMDAg MCAwIDAgMCAwIDAgMCAwIDAgNTAwIDU1NiA0NDQgNTU2IDQ0NAozMzMgNTAwIDU1NiAyNzggMCAw IDI3OCA4MzMgNTU2IDUwMCA1NTYgMCA0NDQgMzg5IDMzMyA1NTYgNTAwIF0gPj4KZW5kb2JqCjE3 IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL1BDWE5YSitUaW1lc05l d1JvbWFuUFMtQm9sZE1UIC9GbGFncyAzMgovRm9udEJCb3ggWy01NTggLTMwNyAyMDAwIDEwMjZd IC9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQgODkxIC9EZXNjZW50IC0yMTYgL0NhcEhlaWdodAo2NjIg L1N0ZW1WIDE1OSAvTGVhZGluZyA0MiAvWEhlaWdodCA0NTcgL1N0ZW1IIDQzIC9BdmdXaWR0aCA0 MjcgL01heFdpZHRoCjIwMDAgL0ZvbnRGaWxlMiAxOCAwIFIgPj4KZW5kb2JqCjE4IDAgb2JqCjw8 IC9MZW5ndGggMTkgMCBSIC9MZW5ndGgxIDMwMTY4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0 cmVhbQp4Aby8eXxU1d0/fs65s693Jpl9JrPcmUlmJsmE7AkhuQkE2QJBUAgSCQjIopAAgmCVuCCC C1gXRG1F64JLyzBBDKI1Vau2aqG1rbZawUqttkbtU6Stksnvfe7E7Xme1/f3en3/+GY4+7nnnnM+ ++ecy4Z1ly0jJtJPBCJfdOniXqL8SW4kL120cUMoXy68lxBdfHnvxZfmy/4XCVFff/Elm5fny9Ep hHT+fsWyxUvzZXIWae0KVOTLtBppdMWlGy7PlyMzkL52ydqLxtqlkyivuHTx5WPvJ++gHFqz+NJl SPF32X5EFb1r129QiuSyENIbetctG+tP5xNS0PrSW89r/TUbXiFkfyshFkIoelWR/yJNZBfREEZE kibnYyVT2ItEjTJvV7Ndh352tHWRtelznUeHCkIeeL9mMk9f0F4+8OWOkZtEoqtBX73SnzfgOW04 107mieTLHV+cEPNv4i1f/VUdnBsaVJkGTJZKnmYLXJWDKuNASShobRVVdtKPwIgVcQvCIgRBiSmR Vfbs5VXyIJJ1+WRNPlmVT+ZWyc+g+zRSNTqksg+43JW874DBVNnPU52el23ZBVVyq15lw3J5PxuZ k0+znXwUW7aDj2Ij5+RrBya1559qy1c3j3VurAq2RtEthCAj9CIcQPgMQYPZ20gaYTfCKIJKKfF+ WxF2IexDOImg4VPI6qqsrT6ViBZRWbtIgsilEQTSo+K7m1Fiq0qHXdGRWQj3qbREpTJkySXBIxhE GGhv5zMVBlLlSpotSVQqDVmvv/JZlcD2kmISRE+adfqUFpJtaxvL1NbnMwPJssoTrQYVIZ8iMBVR UVKSf2qgpLzys+dQpkKOWCnltcLZAbEQbxNGBqwFlXKrKPyHdCIwkhEOkiEERtYKn5OtCAzdD2TL xvEXCQcGDJZKEf0/JSGEfgSB7ENMlbKMHO//6UCBkw//16zVpjx3IltRnc8MiO7KztZC4R3M5xfC b4hEgsKfkRYhfRlpAOlLwivErMzzwQGrWNmP9/0I3X8kbCYJND8kbCGVSPcLVxGf0u0PWUv+PX/I liQrWw3CI8L3lC7rhT5Sja6XCKuzlcHQUeFBzFQWPh7QG/n8Ps6KjspnhY+E1aQQvU6hlytofVZY Q9IIfCWDA3pz5e5WkzCIZQ5iW4KYIyX3KbEs/CaLgfC+R4V+4kTbMeFq4kD6mHBN1hEcOir8S3nf GT4K3vcAMIYnA2ZL5VCrXngArRnhv7Dj/6W87fRAvL6StMaFm0gFAsOmvo/c+8iJwifIfQIwfQLQ fALQfIJZfAKkJcIwWobRJy28S3qFt8luhPuQV2EBm7PYQQ66zdloSeUR4Urhe9gJ8Sj2jqL2qgG9 hc/se1l7gdLte5zAW54V3iSzEBg26y1OkWuPCrcoS9k94PbxB36b1ZuwdVfkYYGRtnAYPCv0C9co O3G1sgOZn6JIiVW4Vnl4dMBkq9wK6M9FcS3iXQjHET5FUKHbXKxhLlmEAOYtdA5YrJXWo8IC5eGp WUtV8FlhCpY+RdmtKVlHRJnzOWMZlTXrK6r8KWjFSsrA0SpVFpUmmw7OPipMB/7MEmZmlwYx99lZ jMv3ZOZAfWNlxVFhprIXM7NBKV+dLfAomclZfR6vJg4YbHwmk5SOqazOorSnxkhSSA4UuiqDraLQ qKy2CjER6gC+OoCmDnRSpQCjckC0A/uXCpXKiipJD3L7EDIIKsC4Et0rAeNKclKpsQq1WG4tGUUQ ANta8hkC2KwwjrQg7EJ4DuEkglqp7UGOob4Cb+hBvBuBYcQ0yiJiGaEHoR9hH8IQwmcIWnJMKMN7 ytC7AnE/QgbhBIIKsCrFPErRZhdCZARCJUi2sr1yI91KttKtbKuwVbVVvVXcatPJNbHSSnkVj8p5 VIKorkffq+/XCxV6Wd+pF0R9SM8GR4ey2sYqJLJd01j1x46/dXzRIdjrdmt2a9mxVhO1kRMInyII 5BgVURJREuXtwrHmE82fNgvHOk50fNohHHv3xLufviscKztR9mmZIHf4GivrFtG1dCvdRVVBmqYt dBZVLRLWCluFXYIqKKSFFuCCqsfYa+w3ChVG2dhpFERjyMh2G/cZM8Yh43GjOqMZ0hzXnNR8plF3 ano0vZp+zW7NPo0mqE1rW7SyRvVZ60T2NjZ1H+IMAiP9iHcrORExJUOIjytlXgtwIO5VyjLiTiUn Ia7gOQQJY/0R/foR70YA8SllCXEFLyNI4O5/QJ9exLsRGPuD7I9UROUoE6OhKCNR+lmUHo+ejLJM dCjKhlob2Vvovw9xBoHP8i08yXMS4gqeQ5Aw2zeVfm+iHyf8fsS7ldw+xP+9rgd1vUqrjLhTyUmI K3iOvZmV6qytLnYPRlyE+D6EEwgCSSNuQVirlIKIKbsHsczuHiguhcBnd2fj4JFIIvmkKJ/4lWTA 461c1Gpld2PIuzHk3RiSl4IILbw0OsT2ZifxvnuzE/JJY9WJ1jpIUT6VveQAAiOzEN+n5NKIW5Qc bwGr+rqcQe6k0tKLeJ+S48/xUSAHEH/1rMDuxm8vaqxsC2q3yEZGnE5oTnabzj7Ins6utAcH2aFs iYhkIJ9kedJawATsvZl+osQ/UeL7lPh2JZ6nxFbZKJn/I5l/LpkfkcytBjaNRPHQZ0r8kRKvki1R 84dR80tR84+i5gei5qP0fRJBp7DsjZj/EjH/KWJ+KmJ+LGK+LWJeGDHPjphnRPhQJSREzCzAY3qh EvtlV8h8NmR+L2R+NWR+JWS+P2TuCpkbQ+hO/4tUo+O9SrxHiWueqjYHq82BavPTDJyJXpC1Ev1R xugFxCwYssnm4KCgVxIWznbEsAP+bEcrEl+241wk3mzHOiQF2Y7bgq16ZqUHoawEmYUe1PHUlE1e jWZjPtFlkxeipM4mG4KDNJdNSki+zC4PIPkiu7wIyZns8mokn/PkGfpPspxhGPqP7PIfYnj6N1LC h6V/JXH2ONLBbEcLej+Vfzs9RJppDNVZaIe82xPZJCZH92eTJUgeySajSB7OJz/KJoMo3Z9dXo7k h9nltyH5QXb5KSR3Z0su4a/bS0qUce4icSVdn+3wobkv28EH6s12pJGszXbUIFmdbX4dycps8yn+ 6MX0IAVm0+Ukqcx0cXZ5Es2LxhbSTUqU5oWkRhn5nGwH35LJfJBWM20fW8gkOpHrfLSNHlRGkbPJ CnRrzibjSCbkd64puzyFUn22BFtN67IlP8TO1Y69IMHh8wyNYhp8ICmbfBydgtnlCSRF2eXtSHz8 Scy5YOytdtKsTMqWTfJeYjYZCv6UGslyZcoGEqd3Hw6OYNwvmwfp+dngF/KgjmaD/ypBcjj4cceS 4N87BqHxBv8GSn78cPAEur7bjKxsDL6TPBV8e3kk+Mskesi+4C+S5cEX4puDgyVHgwMdRcGDmFhm +ZLggeXKCD+J47FscH/JIKN4et/yGcG7kqngnjiAdDj4fXTezt+BgbYlNweviV8dvAyIuKFjR3B9 MhDsLbkwuKqEv8gVXJk8N7gCC7kYzyxbfnFwcfK2YE+NMuMLk68H5/BsNjh9ubKiqc1Kw5Tl5wYn YwZoaOENmMF44GUlHi2vOcr3CJrKxIHXg+fVPcMghWk/wjq5XPus9irtEu1cbRvkTbE2pg1ri7SF OrtO1Fl0Jp1Bp9NpdCod0xEdYYWDoyflFDfZCjWK5aaBEUAJzBDEIuMxIsSEUR2DoZUpEKaz6XPa MnWp6YPa0XMz9anpGV3nBfMPUnpLF52eGbqITF8SypyZIw1Sw+wFGbXURjP26WT63DY3OmfYDYOU zJ0/SEf5E9t8GfvE+UcIpaXbbvbxdPK2m7u6iHNji7vF3mxrmDzpf4l6lMqeSe2TUt/8ub/JIudO BTJ3Tp8zP/NYoCtTyTOjga7pmcSc0ML5R9glbFX7pCNsNU+65h+hK9gl7efyerpiUhe6jVe6kWa2 Gt1IB0/QjS0kzbwb6hd+qxs9iOpJB5sR8U6z6EHeCUQzS+m0QBmLTvx2J+FGOlHpNFG4Uen0w/wL k5gHXijzBGOpLyFJ5YVJ9SVKNzfvdjAex+uWI+qaf7Ayjg4H45VK8+xvmkvyzT/ON/+YNw9S+k17 jdJ+BDyc9zgCllaCPt/Zwv/HhWVt/xcvpAMTNq6Z375Mau+R2pch9GRu3LjCnelfEgodXLORN4Qy QrxnyUUreLp4WWajtGxSZo00KXRwgvLcf2uez5snSJMOkvntc+cfnC8vm5SdIE9olxZP6hqYeXV9 33fetePrd9Vf/b+862o+WD1/10zluf/2rj7ePJO/q4+/q4+/a6Y8U3nX9HPb6PTO+Qd1pK1rImDO 0wFmNIBaenzhrjan2NuskM74sPsq39MqQvcTY6orY5LaMmYETlVlrWWtvAkkzZssqLaONbmvGh/2 PU33jzWJqLZJbWSDu33lJPxbj78NGy7DH2Cyfn0eMLyN16falXZ02IAcYvyhJ/I8oOKb9g2EjzH2 l0rl+5L1qYnzD3Z0tLtXTvJBiR/geneqaz1JpdBTeRfBO7FqRdF3Koq+UeOs+l3HXzo+7xCGFA3/ OLT7k4qGPwTt/jjCSWj4RcJQ8/Hmk83CUMfxjpPo++7xd0++KwyVHS87WSbUjc2Av6qLYqrf/C5L rb+MV6eoslpl3SihZkNqPbYA8dg2oISGDQh8l3gbz/JHUxhOaUzlV4GafEZ5cv0GFPgDSq1SxZ/h T13Gh+fN/+NvrBYsWH0LCapnKMEv3A7vBRl9D+EUwoe5aaNn1auJlFs1elIoALuO5sOYAy5GroOi 9yG5kzxHusmr0BvbaTmZD0+Pm3jA2BvIdGyfi6ipAa4fiUwnnXBFTCN/oWZygIwjf6OTydXQbWaR e6EXzoSR3kpuJfvoOaMfkavJG3QleRxP76cy3E0z6JTRE2Q26Rx9Cu8gZDzZQ+6mFgirGdRApdF3 McJ6sp08TX5PRskCcpd6H0bpJOeSNaNPkYXk13QBvWDUT6aSNeQqche5nzxLTtEb6JBKPdpDasgS so5qaQEtEa4Z3U/q1W/pnxx9cfQ4vJlr0Pdp8jFLqSaPfkJk8qGKjq6Akl8Ar2cVWh8gh8k71E1r hInEAvVzIfbie+SAUII5TiE7sLan6RX0gGAZfRCrqSMXka1AqcvpEAur31J/NrqF2LG+asx0J3mQ /Iy8QP6O0SbTucKluZZR+AEgT1OkHW+6jlxPfoKdex6/F6mVhulUjPwz+i59T1gjfICRHyHD5Az5 Ny2hK+lVrIVdo64cuXr0SRLHCmWMMZXMI5eQJ2icyvQCPHsv28Sugql8WHhHVaL6dLR+9AW4b2CS k2vIY1jXr8gb5E3AazLtoL9nVwkD6utHr8B802QFVnEdeYgcIZ9TNdVTEy2kIVpF67CyK+gQfY8F mMTmC0uEA+qbRjeP3kzCwJVusgxPriLXkm3kKXKM/Jn8nQxTL55M48kW2klvhon8IjsmzBMWCneq ZNWdqsdVz6vOqm3q53O/zp3ErvNxKkgHft1kOdmCvR7E7wXyRypQHy3CSBPoNIy0iC6n36O76R30 R/Rhepi+TI/Tj+in9D/MzW5it7Oj7OfsGDsuBISkMEm4T3hNFVb9UfWldvFIIPdc7tNR42hqtGp0 9+i9o2+PDitQ8JMYaSETgV2rST9Wv5vcQX6APT9EXie/A96dUH6nyGeAwZdUA2zyYEYRKtFiWorV zaPz6Sa6k95GH6Qv0ffoKXqWEWZiEfySrJZNYwvZNexjdlYwCJLQKlwu7BF+I3yh2qyuxO9x9ZPq zzSntDHda2fvGXk3R3Irc3fm7hmtAS5qgHkFoLlq0gacmwYoLyV9+K0jG8km7NEW7Pi9wJwDJEuO klfIa9j7Y+RtnACcIKeU30eAxGkyQnKUAZ5qqsMvP/cKQGYisKWHLgNs878r6DV0B70Lv3voD+n9 2N9f09/QN+gJ+j79HGsirIy1snOwok52AevGbxG7iF3NbmSH8PsV+z17m/2ZfSGIgk0ICsVCu3Cx cIOwU8gIh4TfCr9TxVWtqimq1aqXVb/Gyqeop6oXqS9S36i+X/0j9fPqX6pPqUc1t2ke0AxqPtQa tLXaTqilO7SPao9q39GO6oqBTx2YfWKMT/HkNnqBKs1201E2iHX/lG0QXmW308e/1YOod2IGS2FM DwrPsh98bzecwE+wawhRTVJ6TQAXe408Q15Tv6FyqD8kLzMv+QT88HZhMfspTG03rRXGq7apXgPX 2Yx5/oidYFp2AD3+DmgsIudRD/kv1fnkU+z/MfVO7Olk9i59nL0E07mbvEUeZEcJjHqyjNZhdkvJ k+QLcis9IoToYeDdVnKcfExOfjNfVXqkjbVo3GyjphEQOkJnj77MEqN/B9W/R7eRt4UvgPvn05k0 TR4m7wPqv6PVNKjKqXzk1+B8ReQeYO1fyQBo8JeqKCjoc3JEqCYLVCeBr+mRX+QmqTcI19IzrBXg dCmcexbnxuDBd4FXcT5qIQdA6+AiCkX/nbxOI5Anb2j+SO4mu8jTgoPEhIdYPxsVXlGFyPfhEpyB t14J/uTHWdV+cilZid0NjX6QexAjrCL1pJ4uoQvIJLRMIUWjl2LmD4MXyaMLR/equ9Qp8is6gzrI c+BebuzinWp9bhg9D4EO3yZT6I1kILeUDEGuuGmMVgKbhtUb1bvVj6kPqX+qfl0zjlwOqr0HUPwz OQ2pEaIXYS/+Rv4FXG8D9ZSCfloxiymQYZewLuFZMpF6SS94YAn4dhv2YAEguR6jXENuAj09BBny K/IZFelC8lPyFijHBTq/CO/XYZzp5DxAfT15GNzxWjqAmqU4UkiCzr6gFlrPNuB9nM/eCT47hDm9 Qz4A5xhV5lVKx9NJgN5F5F+clvGGWtIJe4CMHiYNkJSThNfIX+BYE0kb+MuDeK4HuGHBUUWD+n3K SGlu5mg9Wyk8S52QhhZg1VxI9gm0D7OwYh0jxEFnkZrcORjtcfCyTvVDkL4pSAYHc6jmqc/DvP8I SfYrsm50Pr1bCwqQ286bK7c0T2ga39hQX1dTXVU5riJdXlaaSiZKiuOxqBQJh4JFAb/P63G7nI7C ArtNtFrMJqNBr9Nq1Dg1oqS0XZrcE8rEezKquDRlShkvS4tRsfhbFT2ZEKomf7dPJsSfW4ym7/SU 0XP5f+sp53vKX/ekYqiJNJWVhtqlUOb1SVJokC6YPR/5mydJXaHMsJLvUPK7lbwZ+XAYD4Ta3Ssm hTK0J9Sembxxxc72nkllpfSg0TBRmrjMUFZKDhqMyBqRy7ik3oPU1UyVDHO1Nx5kRGfGEjNeaVJ7 xiPhUQwjxNoXL810zp7fPskXDneVlWboxIukJRnCleiU0oVMVF6T0UzMaJXXhFZmsBpyY+hg6dDO mwZFsqQnZVoqLV28cH5GWIwx2jO2FN47KePacsr9TRGDQ13f/u1Wn7AT6nGId965c3sos2/2/G89 6wvzEbq6MAaeZbHJPTsn49U3AVLTuYmXYdu65mfoNrwSJkdMWVV+fXl7KNazKpTRS23Sip2regAa 784MOXdzOOv1ykdGTxJve2jn3PlSONPik7oWT/IfLCQ7z9084JFDnu+2lJUeFG35jT1osY5lTOZv Z5Zh0/NtSk7pznPTz/16ZymfozQ1IwOjLgphJvMlrKmeR8vqyc6L6gEA/HVRPJVZCoiszOgn9uwU G3k9lkgz6pgohXZ+ToAB0vDH361ZPFajiYmfE97I8eRrVMvQxV/lM6lUJpnkKKKdCJhijs1Kuaas dOMgu0/qFUNIYE6STuzt4q7GNLY/HOYAvnFQJktQyPTPnp8vh8gSHxyBaZhdrIe3DH3V4jiPt/R/ 1fL14z0SMPkQ97QQR0YX//qfVXQWtK9ozFDn/6F5Wb59+hxp+uwF80PtO3vGsHb63O+U8u18Q7Fv aBvLZQomzhd8DHU8x3yC0gqkXLjg6y4ozDdlVDH80yhIvXRQqwNWKjU0NDkj9kzJx12GcHiMZv7/ Hhoc/Yw/pSTfPDa2jExjamyi+Wlnxn+n/J3pmXYK0+eC5bDpcxfs3Gn4TttkMLOdOydLock7e3Yu HhztXyKFRGnnEegzxTt728GG8hAdHH36Rl9m8k1dWMoK2gi8ZaTtoERvmH1QpjfMWTD/CLxioRvm zs8yyib2tHXx/WIT584fm6+ymRwnsbmEaBqonwGYCG3sMVLJGvjhOpmGsB2hEiGMMAOhHaFF/TIR 1eeTFNLZCD7kE6r3SbmmgcwRAsgT4kRdXHszSaA9gPpOtFcjH1etJ6vQNg35CgQRh2x29F+I+pRw M5mJdBbSWZhHG+o7UJ6M+SQRUprHMAeUUT8NaTH6Tcf7ZqMvH7cF9bAogZccMwlux2igg2AfIO/y NUr1dyIGTRcKA1GjrxZWEf/TEwNio5L/JjLhsN4CSScSG6wV/qZCxA7IOBfhtikhXshDP+QlDvm/ eezrXAhWRgQWaxSaVxzWWYnSkoD0TkFqAwqkHDZQBWzYyrFnakktNO3vk2fpfmZjTwrdKpVqpVqv PqH5vfY+3cX6eYaEMW180GQx7TLvsFxuvUFM2Mrsbvv9BRcXph3XuYjrr+47PXu9K3zN/t2BF4oW Fb0bWhX+SWSXtDu6JM7ilxdvKlkNm9oPDcuvxlEudqDtEKMvaLSDgk4uIGrVCwIxaFUvUOLRadQv MOEZ2kr0UITOJ+6UeKZppGmmeLqpY6SJtCAvnkU0riJsC9tiiKhfRc6GhKGzspp8iasoQxwybbm9 9Flaxa1W2fYfRrV6FX2evGafajKopjvg2JeNtCpopdZW949vxjtOd58eGSYtw6eHqa2hYVwF7S6o qa2tqS6OSxGtRorEa6prqyqhG2iWb1ip1Wo1pkBq/Lyl55y/5ce5vaWV982xQVWwLWxuW7ptw653 +Qwq6Vq2mTVjtV7ZxN4G2NTUo+IvmymeEj8g6Y5hvCZcE2abR46wc+jaY/wpNvoea4HfQiC1cgCu 3xYmFDImEIFSZhQO8EEOsFLVM+18zsMzxTMdmHVTS9N2dXnqSvFFjAgVmLXkJvbT59Srv9io3snJ bdroKeFJ9QquJ9Fpskfv0wQ1MX3CpXX7HCFHzJ3Qa3V0ky4A93TWri5GMqAx212DgkGOETkaryZy qhxRVS2i8ROqZehh+/jKyuzWSBA2IO9p2WWmZrnAUW32lH7+D77MM6l1HcPdE+fLrogcLa6O8EEi fJAIH2RthPZx504XOiqZjmHu9nbB+4XOLu4FQ38lxSM8fRJP9bjGngKwWrCDEzfLS2gyFA6GmcZq ES1ME5ViEtMYTQaT3qQzqTQOZ6GTaTxur9vnFjQMpraKCppkKpFimiJbZAn4ByJ/gWsJLVEjClsC S6hkKl5C3E7kUhQ5Pk/Ko+TY39Wkj/bRQq2FATeK8auprqvlGOJyqkVe5mijsYkup7Oqsq62Tniy IbL+++cv+eGE0nCquer4ho2vV0zMvaYyxD31KU/MW2itL6/0JDXs4Vczl+ycvbR7Ut/eH/3pyN4f 3X/D0Xfo0vE3jgu5pYMjn+ZOLjmnIlR/GceV7SCliwBVF7n2GWKhP6Y1REcfOhxZpF2rZRSnVrxG S/8DZuCkDxEr/RdU5xriZEy2WHVErdOaUBmE7o8jRVm0WDqta60HrIIIsvC4LT8Fm9axl4ibuegJ hQ5PgQq7u5s6xJFuTokt9obPh8/Sz1O0OwXEsxVirVWOcE1VJSjHVh3ne1AcY/c4J3cER2qj86Z5 7eNCVVPt9J/qFV8+fmV7aSxWMrmfPXdhOhyKnlJoBiu6Fyvykw/l6A3sJ+wJQSg23SEwg9FgpETt s+9zHnIyp59hTgajzj9Iew7b066Mi7kGaSRL7TqONkZztW5QiB6yqCmuGtHTso+oRTVTv2N/w+qn z/mp31uEu1vPUUo9gafh2diN5YEqu/vEM919HadHuk+RlpZh7m6VC3Sy09yik10WRB4rInMDR4Qu bALa8/iKHgqeopOS+kQlzfptLUrfU+ApNnsDRei2NdgbUBR/wZkM6Q6Ha4i9plrZKwWBwGO0GhrG HtZVCZ1n/0zX/uCaC+8+L1b7zu6LH+uZtiz3BI1d0pqMRJ30SVq+e+WNd5uHBnsembptx5Hck/ZU O9/H8Oj7wk7sY4ock4Naq8u6IrU5tc2xzXlPwR3OR+0PO58uMJb5W/ysUEcH6R2ynkDcANxhI04d eyCewuw1HH/8CqJGh/0027CfSO0OpOxXh2WL2msmhThlPhSiVG14mt5BjNR7uCi/zWAGT9neIAkx wRKcMdisLuryllmLaBFnD0We0m/teQp73gcucXq4Wzw9YmtIe7zDTcTd0uIdTqXEkVPiKXtDunvY rvBk0k1rmtm3dwsMWevElpFwhNMgKFChOHDuOE2vmy9vXnDTktiU93be/NR5F1x2Re71XO6JWQ1t qXBAfOG8aauG2H4p3HBZ05xNt5sf2f/E+uk31jQ8ctVvc282lLSUt1p09122YMdfsTEzwD+fVyit GDuqLxTocudGJzMMjv5bdtgLq5NC1PGyQ2jRqSNud1CtjzueZb8E974DElZP734yHheJGie3hkOi OfKOaZC+N0C8Cfcg+8WTVm/Qy7x8m4yFfHcKPSV55nk6hV1ROPwZLphAbOlhcfgUUCiPSArrK/fF DAXRuN8X8DGNPWaJxwyRJbTI5l1CQlbkJGN8CfUVBJeQsBkR52MKG0slU1dfTbpBud3UYWHa2rox 6cZFHTbYHqUaR6HdBeZVWwN+JkWE5598e6tUGmhtu+vVNb9cf+VvN71Nb8v9QldTHi4rnzIxNbVE vcJffuuxvUX6wj89d/3JLTuo7p5TdMdHI2t2yjtzuerY6gdp4Upc+SLt2M1j8NsbyJ2ykeg9aqbR afUGA079ZSuhUHfgSCCCXkt1Wk69JnuIPYfLEExkjIHMD+v1OhUxaQbZq7JB7zXt1lLtGePnR+it nEt90M2lIifgJpAop1G5kMmgRCaDLBknZMZJOk+Yyl66GrYr0vMr0a+mYXBvrVQQpnQ17cv99aE5 jfH4EqEk1+BXLUoVzaEPfXEXl6stWMlTwAsntKwh2WcQvHDICnfp9+sH9a+YVJN0apek1rmCxfSo ggs6ins5uH8KTJBNVjUxu35NPKKHeTj87QXepPSO8deUowH1JL5Gg7ycH2NKeTT4LhZUeuN6ezhm jttiPq/fG/AKmlg8ZJGWkCLRs4TG9chFTMEl1GtHFDVAoH2NCUnsA0cF2u0CadVpOAKAjjg62B2F TEUVJSgvzxwQZ1WVLQ//dbuveV7F3a+v/dXaTb+96vXcKpowJN1pT0mlv7gtNbXY74/f/sdbQp53 f3b9iStuyOUe+n3u8mF2Q+95h38wL+FMjX8493cgAvYPxoM6g/2DX5xWyLdFRKO9Zbm4UdwkbRev lx4zPyVq7zQPmBmNSoxEJClssBgDBlfYHXAZ9VTPdAG90+YIOLEmEnGul6xiSCJhMczCEguX2cRC m02UmBRmJRZrocViZRst1GLYYqNhOHhUTilss2CFLskaiUJNhjg4JcqiVQALMcD1Y3VS59P0GiLR clkKGTwV8d54f3xf/Hj8ZBymczwUl+OdqNkdz8S1uy6FCOkTu097vB0jw93gYE0ifi1NXi4tR5ps EAAuLgFcDd2QAg3bLeUpHTQ2pG6e6X4xxYVEQ4ObiMNUHMrH3d8uaMWmJm0TNF8OLeglYS1o1OV0 QeRCWOAAA8oHL3CFg2uuxcWCIMzNhRv85b5VuQlTL2ynfymgH00uizSP9PpmhZwa5l/1y+P0muva Ug0+UReLGS+6R9X45f4fJoLqWMwpFtkL9G3/pG/kyqDr4UaE2gKq9cGyGEfPk2+9y0Xty3wb2caK R9yPlz5d9HTpa9p3yv6TNpTQejqFTvWdx7p8y9j17LqK/fTl0t+WflD0YeRM0b8j/66wTdHFY/5o tNgSCugjEWsoUBiRKmJFQpSUhyrGJUmsKAprQV/oL4/F9IXRcgdQMVmu0+l1JCSGWOhdzw/sKm9V dJy1OFjMisusFk9l1SBVDYQnzMelh5ncWOiGunKmY+L8w6RcLGflHR91+w6Wdwx3QdJAeRGHeQAd pYc9PFYoChGX0YARBtGKlia+29AwK1NlYcnpVmtdsUjcFdPES2OSM5SmER6ltOVpGnZHeSShTipT J9MgMLHpK2arkFieyDg7sm+p+KiMxUtTFQ2RrtLrS3+v1XCIdiECBLn4h1LwtQ5VE67kAk6j5jVQ qrQ2m7aQ82WlJOz62czeK/bkTo7MunCizzepm+386PneW0beu2X7lHOu+z6tq+3cPmX+3exYmXzB rXuXbo5J9WuE3jUNkdich7qX7LXLGxYsWN9ER+7NdVTW1p2zfc6iPU1cg5g9+p56HuyQKA0cIc7R /gG9odoPPwFPNWOpGanchQqTV++rLejwXu+80bvLt8OvW21bbd9s22zfYXtEs9/8kOtl16s+g8ZJ 4hOdrf5+5zbX9b7r/E+pjhYZ0vEVwU2ajeaNvusLnrZq6yw2ezRAFrAAhWJSCBNoQfhRm92iXhUQ LKsceroobaM2b2+cxu2xNUdopaK4wcLQWw1BAzN0eDynOaAH8rlh2BbdZ7q5NICxAOL6GPadCCOP cPVr+pzNByt1AG/U6deYTQCsTq/VM40vbnYaYkTjR2R0W2JE71XHIDa55AS7vPpq2t1HuvsUQUpt EtdzNZwU7RwqdQ7OQqOKDOXKCK9Szysu/eyurb8d17LwxXv7f7dx3b8e+kPuwFOv0q7nd9230BNK a9Wrc8nBF7+/cc+Rw7nf7e3dcdmm1T+hkwefpwuHmqPpKs4rcbqt7lPoL0WN8kJvPzZe4pHIoxSP Li5Y4b44dndisER9sW0lCntsdzkfLNBcZNGGAiQS0YUClojkL7daWKTG5yM6e5nfGggGWKBZV6Gl nZCjV5ZOeJLrwqe7+zgJQdfH5ookLsKO7yCFYmFFoVBYiy3FJh+Od1QUUqU03DVGUlDa8ht7Id/Y aVJK9NoLbAVMU1KcKE4WC5pvSkzjdLgcbofHodJEYykxHqNJHkleRMUFfh6lUJeKOSKxb5GTYoHl qYnL8Cpub4DhKQaHBGpxccEFnUYjCTBJOATqam2KTeYrG99i1TsnNpSxRf+8/cmjC7//3M4J1y4Q C3xVj8y//NzW5VNisZBjpfC9FdXFsbbZucFju/7xg0Vek2r0y3fnxg3WdXfjZEN975bSICgEJ3Sq LwCPcXSmPOxUefQsVFVR1Vu1u2q/683CN10fuP7l0m82bHB8r3yH8P1C9Q7DXcJdhtsc+4X9Bk2o sN0hV3VWbRbUBsFgYFVyoanldtW9+gdVP9E/XKg2UaKdbTK9qgtoQ6GAOxJJzR437r3SQEozm9JX 1QFNOBRIRCSqISatmThEHH04U4UOp+DSupwD9nL3uJIELTeZ3Anm1mm0Vu0sLWtBtEt7QHtMe0Kr sXIbUVtZdSD1XIqlUy2pWalFqbWpraldqftSutS1orPXudspOL1yFbwoVnPQzMzN4ZCncgw9FOQY I67uPvDM7r51aRiFY2qqODzcNCbvYPHA4LE3pEB4HxNxZCz5qiiI6jGRlurrxh/sahsHaJVNKmdS 3qbkRSEv1xRAK/Y1QM1pD5oJK/ddvUGMx00dyxcXVDfO/ulfKmMTvrykbHzUazGqDb54W5lqbTyw sqf+blVu5K0HfjjSuOH2qtw1vZWhzKHc7JjDEnEvF7630CEB6XJrb+svsgO+uKmhehjwLaVhuUOr 0htKhYhxmlGtUWsMIAYhroob4sa4aZYw2TDLuNyw0XC9wbIlsbv8SdWThpdULxk+UH1gOKM+YzBA yEG8BUIBRyQSn11aOshK5FXFgbgVB9UcyPqADma6djZjr2oC2qJQIBqRdFptnJlmmdksGn8uRmPe TDktJ9RstQQtzNIcsML3x0hzUVHAU1boKC2JshJaYjKbo4WWQAOviJGSWJQ5dGXlz1AGBWsC1YJX prhaDDNCbDoN+DSkm4aVAlXcayJMMJB8E5xtYJog/Q/ED5ROY7D6vDsPu69TTuucF+ZBpsAMzHAM aGOKyLco8ytwVRUvWDfLJEkFj64udoEYR8bnQcUJU3V5wrL+0qYHAKg3avsvHZn3sytyizk5fgUl ns9dseM6HywFMmf0pCaqvoRU0Utkp0FUR4WYJXF58IbgddHrYjcnbkgapDFZZfpvsivJZddE8MwV 2hXGTcZN0SPCT1WDmqeiT8WfShomSZMTcnJ74vqkem98T/IRzY+0+40/j72a0E6zuLkZ0eumRa8E 3Asj3NyXC1Gz1UVtrwRcEanqW+IrQhZUPJoqClIxaHa53RF1TUow10T0xCbamK2ZFnlr+PN6k1hd Yy/xVNc8Q+cAVmvoSQ6rmae59mLVB/VMr2gvemgvM8XUmSZYhopE4xC0NzRQBCJ+Jdu4OybvkiFc wrVzRlwZSmqsRlBLrDgKJqyNmSR9jFjCYhvFF4eiJomSodgcI9aQuY3oEoq8g8DjKqwi9RR+24eB gUIAtxTHoamGfSXzvuK9kH0QhDaNCkYEKLNGJJwd52XgttjE3On77vrl3IWv3zzu4lpn+ziJ3TZ9 vKi/JvfXPT8bfaFuMoXIWza79Od2f0UhBGLkxdcez/3q/hdyf9zpKKTeznQ8FlMHowXTch80jl/5 +Oqdj9NK+rCom55o4BoL+DH7BPQaJDvlsrBc528xhAIsEvGGAvZIxBcKQDMzhgK2iGS34Tq9zmv1 BX3M12yEFT8kuydLLScNtMIgG3oNQwbVIkTM4AmFeaPPF6g+Gaa94aEwqwjL4UXh/nAGBc2EjZCV 4Hzcf4xYYYqKO5bvE2gDoutbbIvTRk3YwT2DfJe4u4x98m3kZz/nhGA1gihi30H4PPKfvQ7Ij5U6 R98TTmOlSTJPNuQXGcfyBtlvZbfkcFhxFBOuserjJCbGWKzZcJ+RGgfpkoHSQMA9SJcP2Geldh1R UEw8M9yQhs+rSXHoQSMGQikT//Y0uT7ztfsbTk1uc4BDj0lcKrFflzZFPVbjzJdvevyN85snzNGq 6rzxCal6F9ah/opyR1a8cHDToUsnz5vZ4HcYZtu8Bf7S7t+y3/ElYU1xaDdmrClGdsm1S3DV6Aqp t1i1GycID0eFbwA5I5IHIbBP8ElRwpfYG+uP7YupY4P0iCyGwiUM8MXFbF3sN+QH2JQDsvMbUHvi FcVy8b5igZsJM+FxUkB2+vQI+CL3FzSd7m4CPdlc3Mc3Zmh9W/L8DxBiK/he1KnNVV/O+IaNsTfG K5B0S56evkt2r0zTd3LRb7OwMYjuW9Fg0c94cF8ef7UrsAO1dJa8rohbwsYiqi+6oohV1LfXdtY/ Ql4h6pi/lm4im/ybAteT7f7tgb2B/YG/Bb4ImHrrT9azoD1YECwUo2JMbbVbC6yF/BBIX6v5Zv8i kfLGQDwytovBxkAsIqVDgZoI+OQN8kQS8IdwglXi9xX6/T5SW0tIWaCoMBAoIrQ24BeCuFNSWwP8 iscCfnyNQ0hdvU/0Um+z4ZjxhJEZvfUKP/MXVSsTQqlf1juc1fVFwZJ0OW+z8bbyk+VsqPw4rDJP Xf0gnQuzbSNQs3QbZ3rdCiFBCKXWpbgYAm4qFpoblMX/eDxmpengt1HDiEbqVjK44678cbnUvY6r 6aQvRel3iS7vo4ZTHiiM0xIb8Nmp1DkByG8USeE47WUledx2TmooHWnK50f+7R75TG2e152rsJTN LDEyNKZYkv5KuApQDbuXnb3mWwJr+MuU6rWz7UtdlS2xGA1Wp40XCAsuriqOcawPwMraA5iH8QmL 3Q5e8++suYEn8iZTg+j3W0V/IGA1NwZ0CgdzRSKsMaCNSLZQwDljzNMBvSIs+l3UGgg0551nAV+E 2KwWSgOusA6KBGEup86qp9wLYqaLcEpzZadEJdFW4ic+2umjxLcWnPDKiMLOxNN93euw65D/0AKU HFca8u4MLmygEigKHfdgbFdd+SJBpVvxWSjiYbvYdOWL28UXYR7BdoaDnIxm5FRBDbGK1jqyLtQb 7g/1h28lu627Q7vDh8ihsFkVUoWTqmJjpCDp1YiDoxdkC2qQPCwX2PnXOGIhFcXddJ8/I2b8Ongt UxSSiF8Bf1LUFfpa0PWkrLe7W4jOUtBCcHI+VrIWtlgHR/86gD5I/5i1uFoUo41fYe6i1AYfiRac zsIcNo4G+dMLztiKIb1qaI79QKroo0Pnjw9Hzq5e3R7KBXvnB1JtzeoZZ59i52xJNTK4TKRZPV/u Ua08+8Bl5wLACy4Rno3WRlgM2lknoPsZbGgzKaKPy1UrxBUFdxnetL/pecv7lv/NwF/teq1bW+Ri bpPL6/IXi8UFxYUlXkMRN+VcPHKMKS2YvGJ4c4ObG+BwxvfLS5HR8F6UR/Y99E62V7NXd6dpj/lh 9rDpZfXL+pcCb9I3zWam0uo0eo0BXnjmMrnMzoB+uWe5/3L1JtNGz8bAHuth9+HAm77PdMbzLRZc yXTWaPV2oye4hvNIkSshsof4RKBIhyxQwZsOtcAFY7UH7cwOvYRri31cP5Gt3+lg74D3mjdx41A5 q+PqyGyujjTRIjEWiBfG9TF13ON1e3F2Z7bHsE++GHXokHNpkLOZLDFq9jPEtMDgjBGvClEq1YSf AkjuvIRBjnOUPu7oPaTT2BvUg6OnZaO9gbntDSYEfBr7YdbWAAXwYyRo/RA0pkfpoBlH/WN/XXm8 QAmohaviNlHLwqHiuA1+e4hrfo7HzUh7jQjN3wUr8I49r+Ruy33/lR/iFmn904tnbTlv78Xt85cs vUe9yJRbk/tNLvdi7uy/X6RmWk5vm/HTe3Pv5B56eEOlTD1/Rp1xDbfoq2FhPATq94JNHztCQqB+ U0OIU/9CY8OsON3jPuM6E/pPRJXU+Qk1hUD5ERoKaCKSmes0kq/cTsr9fk2BHcauTgzT8Ls9zn7n fTDbdqbhIfHlD/fKzMQkmlinqcfETFfG4t+xBzi7VVisQu2KXglShxoAuwC7MWadAWRFQanQ63Z5 XEwjFYbTNOhFFHHA6xVyFXF3F4dIMm+W84Ki3kD7+VpRqAmHuBtLqxFsXH3ghzgs4Wtf+LXjahaN 5h7cvfivYduW6667li3P3cDdVN84rI7fe90zETe7a+Qwu/WuPTfxHeRawx+wgxIpo5fLLed513nv cgg6yS1N957jPyey2H9RRGvnly5EtahRVaQv9m3ybYrcIL3me1U6ntbtdf7W+x/3l54vveq0zjTI fndI2WMlw7cZGbmBbzWEoUIAZVKkUJIiW6Ub4VYmSX/Y1x85FTkdEcRIZ+R4RDgeoRFX0h+R4rFy 3yD9s+yScO0lWlZeACCFfhMORyJQkXVQK6kaaj9JikmWfBcH7TiSMEVjEApjMDOZOjmfLp9wBFdv +R2Ibn6aobiURbiXoalwhwv/cT/mCIdY0zC8zHkHZt+6briSUejmTLrbAhHJBaPiywwVlxZ6HTFP HJ+SFybTtNiLKOUsS9OEO54mXt83fss8NPPHnCVAS6OpIaUzNfjdBY5mmmeiOMH830CtuCyh5o65 pKnAbfo8zENwUo5MG3NWbjxzavcl7d/DdQxfojZ3Xm56V8ONO2fdej9blbvuu9Cf9NQVdy5pDuZq upxBIcZWsb0jP6natvqe27kcxTceqjA4bQMtkxvcFfMSm8KCxkL1Vm1KU+G2ulJl1hQuraQjoVS0 tDZZm7o4sSOxI/lo9WDy6eqChq8ttqmygyyw1gZrWe2j46D1LAgFgqEgxXnN5fLkogXEK+Ks7lFH ImXVxa1Gq9Vv9FtVG60bE/dYHzI+aXzRqkklrEaVpK4ZJ0g1Dv0s3OTPfzqvpvPyTjR8vilb7N7x Mg6px1t1QSiqqDoUHFfuaRykDQfHeO6pYfDVFG53dJ/Km3pQSeFyBEgVU48fl445Mj9GXske1PCL V3JIMApWFkvEU6uMK61bjJut1ye2pe6wPmE8avyl8ZdWM1yXXVy17cMhQgE8KDDklGMEfnoACuW2 G5wqcGlKtirFduNe5+JyeDRrvzpdrROeNyYC71+3fJMjIKcf+2TOubl/vSavO78i6G20x2KlX97a u61qxXVHHpj3yZNtzentPm+RGRZd02PHLj2nTEqXh+detmLF9Y997o0WliQYeev9LbMrFsxuvaD/ h4seOCWaWkMTOFSngbpNoO4QeeIIieD82e2tjnAdcrxorw5FZJDcUERVgQyjf9Jqz8Jp7A4FxEhE HwpYI1LwT17v2aJAUOvFR9lMxI2HXpzwDNKkHIE2xI3qZo/opiF3p3u3W3CHxCBs4c7g1uDuoCr4 NE3i4sNPBsJcCIpnuDtURAAJwkJQTLyRpq88WV+5sqB0cgtZcQljB/+nH0Sx/CSb2hQNzZwUX7TM NbGxbKQxb/Mt2dE8zxVXz8jdunVt2P7l375RIVXOxtl30rV8RypGT6ofxI6UU0G+3231RJjbUBxJ SldIN1tukQ5Ir0ujEv9/cnDbTKQiE4VeqLBbnVtdRyyvlLxV8mGJRS05LGIkFI5L48ILItrnw59L 7GHLYQur0sFHTCORoOJuTIbK4TCOQs+ER8PtclGMaVoV1UNnDG0N0kXB0SALXllRIVd0VvRW7KtQ V+is2iA8is2JRGeSJq9Mj+mS3I2ETVOkC/coY+84w8KPS16FIUXCJfDex+MxS8wY06VJcYlZEiFb wvpiU5pYI4iwqXgg/wxnSn3r4HZaV8DVetijiqgZkzPYd8V2zVvY3HSFLqf4hrUV7Blp1nhP3VU9 a+7piAfKzqW/8zfMsJlbTr+R6bn2Eq98vnpGLNy4YWTF4Y0zL/rJWyxxwUyrKxYrLw/NGRn59LfZ tPzKo+yuyxoiMJGglUK7ywIWYX5CIgErG73R6uMSrVLtcTBRovUu2uBa6XrUNehSOV1wdHs8/HOy APGAsTssAbNJZwyYwh6o7/Lg6E1yrUurCcERCM1Dqy1zgSRdDrVGU+LyIOdx4CK6yqT2QAA7dGq1 Nmw2EUh9Pey2oafKplZLLpcXH2uVExe9RraHTDLqekzU5IlIl4RxNvm1cZXyejpGRtwz25dN+gDe QMWa4geTYCxgMds7ylNcWqi5QYUMTiW93zmQ/M6x5HackPGQ5zxPuUM6WzW0TGjonMEASLDAUtQB WGhhZ3GdOm+IOeCWp1SRBxxe6uy0xuScXFk4l57bMIvtdM4PucRyGqamCmcomDoHYDFNrDzy5WlV 7QuT9DiYtAbs41aPdLOuS6d5i8pNNsWWso++p+X+n3FMIw/s0v87waa6V3oedQ+6X/F85PkooW1w U22pCx6GWjKrclFlZ9VqorNWilXcD99b1Q/H/b6qTJX+eXqs8n3yTzJaqV6vX+/ZULJNf61nH3nE kcGHWnq3JwEETVc1kKmhyePW4cs7PRHh/usnVO/xaPV6gwc3zbw6I/GBCv+iArzzzj6XPWALlYQD IQLKNFkDYtAL3jQuWREYJ6twk9U4OHrdgNtogP53hbwyAWrE3RsR0kFXligpTCRKTMQowsI2lrld hW63S48DakOJ24O8R6PVliSS6JR04ZsFlVji9eA2osatOQ+kmMBHDvy7BhMsAOO4UBAqLb6ZxYWL Ko4yrQb6LBhsgjURGQyvBXlxdOiwaKsW+Ykqu3jg29ijII/XPeL1jGGQYpLnzfI8Eq3jWITsdxCJ n3N/g1Hf5OBLVBSWhv8Djn0b4T7v3i7qmnTcvGyCk3MM7ZIhvbk6VDKGdrD7u/vw9RjUeMUbyTHv a+RTnFe0AMKMcwngJZd8BQV5TKzRfhKvLtQ05OYV5zK5W2K5tkm1MptxTnocNfwOt/NaW9it7UUO d9m//iSJ9bOAlUI0Ztr15f3CqrN3quY8MlkTizG49a8YWcPY7o2zoLtSgzbscG0cuYq1L2jzJ9Iw C4EVC0f/KbwrvIAbuE1smuzQiGKDKiQ2VMpNk6pvrLlNe0+N0MzF3OLpNYcb6FXah8ueaHqq7KWy t8Jvlr1V80GZvkbbrp1WMM01tWa+a7nuDnJPzUP4SPCwzlSF//Ggea/q7rJ7x6lIc2fzRc6e5nWu Ox0H6EONz9GTzQads7N5w3hhio457A42nr/lRVfDp+NpZRXO1rWp0pJUaSxVmmiqerzqaJWgqppQ 1VF1ZdXNVfdV/bjq2apfVf2parjK2IszofGFurBume4ynYrpxutm6Lboduju0z2se0X3B53eqPPp enVCoV0nuM3xYAojJpanx09hlXtIdzrN3HIiVW11B92L3Gvd97kPuJ9za0+4P3afhRx2yxax2s0g TIzW0mBpurSlVFU6KTHRGgvCm/k3QtL6Fv1W/XN6VQgJI3oRknyQHpVFubm/mcnNPc2seb+DOvh3 1HJJZ0nLqI/6UqROrGN1lWpZilWvhVnOKtSyulPdo1apPRPqzwODHLctf+6Je1d9p/tSP+uGwMd1 x3Vc8T7DtTCcbaXS4GiQXqf5scnI6VO4QcD1snXK+RfOlxUFTfyFTmzC3QF+v2pdHkkPmdwBNyPd 4IvcG1/f6JcMoqCywggOx4zxhrilyFZETCF9EbzUjUJdERH95iJqiCCqV40vGruvk5eAEJxX448C xxU874NLHnWxMT9tjOtrXNXgWh0srm8u9KCYl5V1Li4Z48U2LiYVdy6b+vgNnasGaY1LLmlNev3x qeNbzlv32ppt97gshkKzF/8T2OpJnQsMm8cXhz1llTv3rJy1+vFbLlxVlwjY3Y5gqmRc+4yqKddO 7mtL7sndIYfFmHvaxOl30IZzZtfWlUs4vGYkNXpK5QOHdpFiOlu22ifriEt0Mer22KJB3N/8RPZJ 8esEbVHcaLSss1pFo4sQERaVrPXaE4BmdnoNT+R63APuTBxPsIqEnOhM9Cb2JTKJoYQ2YcHFeU8Q 96mSNrss0grc5ukUh8TjsP48JTP7FDuqD46CI5zJDXjC3HUEtTKkpPjP6vilsC6u5MErDjckvwB6 hCTyXfmbeVdlImNdzyhXSaDPnOIOjpRgwQ0d2p2HsTemMqtj0Ti/kcU0+ngoFlNFimnA5CkiZkvQ gLykiRdTr7moiIR1RXCD4+38yAVJ/p4BHC/SlepefW9oa/RO3SPqh3VPqXTX6LbpGf5/MMPW4NbY neo9UY3i/uiiNqjnyk0RBbTQ3uHe4m6svH9TMb8gbSP0wMabeh7r2fLatTM2NtwT0RpSVfQ6jWHG +Kqp42qL26AEjYxs6Tt+w94vrq2oXaZ6aHaB38diIw/merZK46c2PnHyzc5Grv/MxN23ReBiEvmH fOnnGhrV0y79w0U/Zz+X3qJ/o39mWoOOlrJk4bzgcv3FwY36jYZ1RXsKnih4AhdHny48XPS09POi YzEboY4CIlj8x8lJ4MhxepLiSlYhLiWHC6AzuT+zUdvf3XGjNjxFZYRT05KiHBCVnhaeyj69rRpX effRDJ7wHoh9Ch5h9Qf9zF+pHevH08MlqerjOGPlj+hNlmqtJ1p/i+LdSkFjh5WlHHmCijpOrVOc VcN9Iq5swYju7mvgZpfrqwu7kCvr+mIK/cAiquN7nqexry59c+WGOzgEOdj287VHTy6/4q1bH2+v H9+h17hcwYpI9dypddPHzf+H+3ubqfel52498P0FDZNmLm3xeKo67rvuH+NTOHjGf6kFWmkHrRTB s7FFlu4y7zcfMT/lVNntdTrc6itirmCZXud+IFj0cymveYN+DtEH8D+qDdILntKlrjNBv4Thukj2 uDaH44VaDIX73FyjgGUjupk7qWygBTtpxX/pxjIwjrxpbBCojCcDIDKe4maCpbozfTzNetP70iwd hGdJ5nQjO/ijX1HZcVElesrrr1Y2FUwyv6egIfjwldJw3m7C5RvQy7Co3BzvzpPM10RTEkmaC6Ix KYbLrHF+Y4RpLLFIQbyYJM2IYrZwMS22phRS4R67JPc4gUrSvebegt5IbzKTHkprei1b7RtdW6Xe xBVl17t2lt1l3uO8p/RhJy6plVr6rTtsDO5C3LdSqDudp25lxaBuZQNA3Xx0fiFLIR4o4jV5U2Ls ZqRLoS2ppgD0pCgR+Wsmwm80urL63GXnrJ08sGLuiidXTFwxXm+qaNs+bXXMHUtXl7lK5s9Uz/jy tUsLw3B5d9x+fvO+a57d8+mW6lbqXe0M+JMj199SGLz3/oOPxQt25rFA6AaNOUiI1sjzNfbphd2F awtXOJa5NxdqY4ZH8AX2L2y/Zr8W3jK/5fin8G+zYasD/BIXSM8XlgtrI5uErZFrhestfzN/6NAn daNOqtPrUxwNQjpB160OOQmd7BykJYd88QKtGv8D1YDJqHdy6BoBXafsiVQ7V8KlPnSYAxtkj+yA 0VLNU9ltqyHedKQlsijyaUQVCSXyzqtKhauiv5IW2fNpvKJawRoT0Ok4dGBPeIwClVOD/HW97jOp FEcWuHgVKjyNj30gbLtPUfEXfQpbhZgMxPJuSL89WES8hU5cK7f5iqjLgWjMDcldwhCK3fhEI5yn xrzE41fE7aBYbbXi4oDwcwjdI6P6Be2Lm5bUR2YMbj6++vyRx2759SdSzCFVh8fTz5++ZM7Eec57 rt539XN/o46PHrj/8qC9quseCVvRhq8V2uB1KqMpeaGcppqCYJRZ8X1XUCNqVckULpQmbKLZZLKD 4adEqyka1P48QqNBDWgWh88tPuEAVJPK+DUOWma5thRdII8NaX5F2ZoOpk+khTR0dOrme13h8VW7 ixIRGWlkdyL9xxNltOz3hCTGNj1pOo7PNn5/HBzy92azPQF/99AABuKpnE5UVodMx00MKoapwtRv 2m3aZ8LdIRE+YZ49bvrMpDXhIlpFmpWnfxl+mi7F1SK4DPvgH8bBNtgiZFzfqT6oQkruA3zbc/pn 0Je4GYmtztuRMO9bhodB7il+dZLfVlWuUOZjLhdBUHmSqoNnGBf5bVJNVU3xV19WKYoKDuAgt7hP yuWoctAThaHzR/7QUlN4ww30jUNXbJo2oXoCDGHRFShmO4X2kU0XuqGGR6mvYgbbsaQ9vXtoYX1Z W21Y77dZHQZrRc2BTUsAJtKRmyy8DUqqIBPwv668Js+OiUZrS2lsu/6GstsST6qO6LOJw+WfRT+f ZDBU6Ws0DZrxoZlqHcg2oU8E64NTgjfptiXv0T9S9shEozwl2hY2J9z4j4kbtdHC5oQ5bVI0di+Q vVm2NzTL8eLqZvjMETnc1RXNlDcP2N3VzYOCSnYU5q/6B+r2mEyBNBPk9LhqYVDwy7j3lRq3J61t jwesU/gjOAbmqWzAbENT6JQp7sbB0eMK6zU30sZK9zp86rMuqKVpLt0EjZwobcPpRwsia0u6jVrb gm2sbUpY5JWIUClSqxiEc2hQUMuF8eoKECqrptbqYDWrlsPxVCl/XxC1pXJJorqUK8zW0rWlu0qF ztLjpax0UwfUZe6R5krnqSYOb9wcAhWPxSPdfWeBLcNKNb9xBNXodNNISrlwhA85UukxnbhQDoar U13DXATjL1+L/0kMy45h+zCNbCBYDT7MvZ6KoZhPed7WoGATNGDcg3ZIiudSYdHcmemsqsO1E+Ww ATjF7y7U5SMeV1Vq8334GURxXFAUZS6weSnOfkDHD4wrcK99bppmXdmEuuYf/2ZW34rzrt5/1fEF 7Rdes2r99ZefzHRPa+ycVdvUWRa6bHm4YeOPbrzP6rtUuHfNuJLa8Utvm6Men4jiaFvedt6N4XHj 5lWUT/XI69qvqRi3b+WOXzRfNnjH2jX3DbRWfPkPW7Cmas60iR5bkZNrVJNxHlQPmV9KTxzBf4n9 WdbYoByZp6fXVKsnM9bJT8y1arXGqYlrVHDkRkhp0CxGxFKN/YDlOQvDSW5BNGgZZG/LtkhxNBiR Ivpo0CxJ/mgwPMj+KF8klUSDpZJEcUJcStzLVdpIOGyxmA26IK7TJwsL5HBrS4Hcfk51gTyhpkCe iNDQiELFOETFJYhSZYgiUUTA7gIZjoJjBdRaQEMFxwqYWEALuClmHyqnwfJMOUuX9/KdaK7hCxnA UEqK0ZQUAyopRlLS0nIllS2QX+Ukr8YlS4o5Plowsc+Kabp4qPg4vlHmo9U1VispaEdJMSmlqz4Q ri72lM3MqyIcs4ChyhmXyAv4A0uDYcf52td/+RswimOSOyih+ilNAmdgNH8CEsY77caWMJ+OHtc1 LfzOplIqwOckFs61LfwLMQu/IGZBr2y4UPnKhI/Uxdkf7V4HDoiDE+jqXHFUzDHl+v5X1w7gdeca x7fqoMC/0NHfPv/KRMmEXLzSY7enfCUzSq0F43Px8R5bMQ6jR96fPXHp9n2521bXaKNRbdi7jN6/ YXy4rj1nXOqJ6KJRTci5Wji8qlrHT6WTUC8l3Jkz4iu7t2VnUb/N1WLlnxr74Rqyi36NKxq0c2Uy Yo4GbTwjuaNB/1HlP1XVYO226trqAxqqkXEm6dfYbQY93xE/avO2uCwkTKb8jdGk2yVjeH5JLttY o3waF5Lyn3QWuJRUTpdVVGdcdBfchtwYdF0hF3UWsWBRT9G+okyRKl3UUrQLmaGik0WawMwhMB4A 7gygp8CHgw3G+JgEakHm/yvs+mPbuO77vSN5lHgU73Q8/ibvSN6RFEnTlBTKkmw5PNmuJNuJpCSO Ztlwbdd12mZO4zjtNttL5cZet25dlGWNt9QYkmVFgwQY4pqJo24DoiBdfgwFLKxtsnZAK2we1jRd ly7G1m4Qvc/3HeXEXYHxj/veHd893r177/v9vs/7fL/Ehzd1la075hjzYUx7b27T4vi+/Y6zb9+3 Nm5v+2819I3bfMf4CcfZ396yljoy7LVtMR87IuaxW8DoRPyDaGN0qoj0SWvUaoc0ZHFkCOORBNXE +qKqSjKMO287WHl4U2g7GH0VO07UwpWSL9BZ4KsEZWoZoH7UMiRatUaDS7QQScdCE12U2SICHzny d9rUntIuap661tQWtWVtVfNpdN1Ao0Hycm1jo5c3EHXwm1qIm+f1hkHL0Yrdzc3R+qAZbvuf37jx 8J43PkYPj6fH/zFIn4X9nBCnHXNSZJpmOgFjuEsJC2PChBmGmzYhsU3DCdvE9O7tF/I120SO0Lcd PT9um2NWXrHNsGU5JZa3zdKS+A8vWc4WNmybW7DvVKxttjlhWf58bVPOz7zG2OA9XuOeQMDrFyak sS19JT0cmHJgk7gxvNvIN4Spp6YuTi1PeafgIoUUxVREpZJMQG0lSEc9mXg5cSXhcRKLQAPeyeUr G2v4qsa/qr1cu4LU1rXFmlh7R1CGTQBDlW3j1ObJTL5xaHx1XHxq/OL48rinjs3KuGc8MTm1JN7V ypFSIYrSOtmPG0FE93TkgTGOq6NvcmCUuEpNrH0ALFonQ1Pv5ARNWlvnuoW7tXZ9IJWRe3xSfzFd HPBtNJjkz8hJgwV76tIgaBFBw3Vu15dBCAASdu456Whmtqs7C/jAZ3bnSkI21+XHWgmKCQCJMDWy D02tTolS0A42gs7UW7JvxjfTNd09Iy9P+UbEGWkm+N/Ibwq/7IET7oRoCl0qmuEN3VIjTQR7/LwF Rccl1B/8yfdIDXKJxRN+HpIfK7J7DMmP1c51kHT8dfkDxgVBHXyGFeGqMPb/K0TyFzvIFpTkL3Xg N28/O73vVG72j2cPP1gr3drOjKY0vZqp7q31xsbbaUQI6fVUX64+hO8Mrjc9z5zes33P3L7Z+S+e b3/+WAN60ldKHWaPPbQj12y2A0cB4EAFWAN3sscWHDti7m4HjjQlrk2PiSrXpq7NHsa4qIpestk/ elEe7ZZYjfrSyO6h2RrzwV4XJM/3xLc83016ItIQLLnnLfbDlKgpIXB9q2ZIzanV55WXQQdPpXXb VFz7XYTNtvIB2HNuv5Fo5ftOxIJVryIOLptVlFAgcY/P4/WDZ3CwtYLZ+9L1F525+BA7CSRJCnCL jrgpMuk6+r6is6x+RRd1Mu86TLtOpl13hjZhA4us09jQycjrZN91su862XfQr3Qy6opZu1gT67Xj GDaw6PSMZNG5RCVcoh4uYcm5RG1coi6SjgLLjpgTTl6vlEpFOsdNO6J1i8uIrPPQKTLtXMK08yLd GbtRTGz4wKRzi84JEdwMYENY7fo+t/hVTpjAOFSvVR+ASR/70Lrj+tjjCEAWP4gOjYUX164rZNf5 Edl1hc/GyK4rZNcVlLrJrsMNPUHzTMCFRDXs9OZfYdn/b599dercbft/S1fRJUtDMVWrJud2lYba pU73PDk9eXT36NPtLx/jZr2QOMKeenAsd7otf2oEdh5Gfb0bwqpThoeX0A97hBzb48RfT7JSkGm/ 1hUq9iCUJFb0d2O10fHy9oYa9TpFAPBe5k3SAiIQHy4mXdHkojW6tUFnHRvY2bK1gghMy7EOWbQL FP1JEGBcCpizIoNfjEZEvVyiapKXMdGXsf4IstoLpaERoK+Er9OrcrGhjv9FuR94Egt6QWNuRocd DACyWDCNrCFKejiC+CGpmEon04m0h5hiJTxlxmDRbs0Q4v5MiZhiJWZ4QgZ4YjFDSPtiJUJT11li FQrbgjIc6GOjSDy5Uz0Z9B2XFoIL6vHEGWkxuKieSbwhvmYGFvxAkpSF+KL/TM8ZZTHeBWwVdAki hXUoLVaeQrtitO4MRw3zBuKRQi+Viqx96u/vO3rq7W9ffefKLTtjIXlqY80o9ejFQtLz6ud+9Puv f+Fp1vfqm6w6efs//92vH5jclchvPchyzy1kIoT4ldq7vCgIp77OPuMktHoXQQlCL4EJaq8UrgNy IASBnAm5gyJ0PDTg5rVzMX+vBm8Mkb+mLPlDapmVnRQyLrjvlwQheiSdfozC2YGVAbF/wBmYHTg+ 4B3QXOim0qNhDtofdIKzwWXAAr5gov8m3DyIaoCbQ5tzMJzkh3FzwKjkVfNxNeAW5b8MZI3fyDpu jh5ATgneOG1xBYfOb+CA2eKGuJEoVIsZRCxsiJdLrGhgU0nWSqwvXbiB/+FCbuS22E5zsmHRZiG+ YCwUFzZ4P6MvJI5nfhs08oXq7+hfss7rfxJ/wngif8H+mv5s/jn7sv43trYjwjgWiM4yX+BrIwAm OiRgWq3G7gegOhBe/r5dgMLPno/1T6y9y51H9nsDt+yc+8Sze/f/5b23bx8cnvvYJqsxWnSOjh9s f3WqEcfKYC52yPOP5EuensrWH/6Xc4+8ezqf/Oqp0T0/+Y/5LY+Rj7UbQMWn0QPKrIT5flEelfWg 6g4pKGQMqX9tpTAfpqaHzwd55pI5xA8zhntaUbl0Snq0oVbZefnRqignkL5BoWxBZTOjGmpZYhHw EYQ8sGPuqsZeM5H4Ba6qZZtl6l0ZKzCoOMYYNF56uKl8goyMUJaMTEA5ICDZw0FkyT340qP+Ff+q 34P++FeOLJSVmAnvvWIRQQf6hESrv8H5Oq1U1uXtIEKysZxnx0GgyKvIGvP9yrSLJLjePJz5a9cO ICIJ4ZrccxpDz6DOgd5MnG8CkOA7uZ4/XCwMb1fdrgPwBMYSphejkckdXGJzY1aPSdSbB740PrJ9 fOPQtD/Qk0mWI1nmD9ZH2v6t1a5Asd/zzHf+6OBHmtt37fBK0Xzz8GffHhlVUwlAS77RU6JvNppG DCje0R3Xr4rfwTsaFJ8DS7M/oja9ak9ZVzNlr6RH9dcKrxW/p/5Y/YXqL6uFyoi6qfK78uPW4/az 8l9YS/ILlgxGU09XORKclHcHJUdGaiBt0BQuiCZjZHeQVF9rPknGnH0EmZEuaHWcaNTfr8bNxIWU mUyiXS+jyKMg3eM/DhwjcSH6vqb5ilW/ZhQ1uTOOHaTqYPuJUb76Qrcu3U07yJWgi3e74fGoxZFl peEe5Wm26myG/jYBHyaVBqs3ZhoHG/c3FhrPN6SG1pWlSmgr3u1y1oAkNdy9fLLcRzeFqxXEoFFN tMLSl7iFVD5pfCC6oLNBkF54sSsLM9pFxWK4pMvRc82usYiFTbSAQzwb3jg+FLr7wH+eoIWE9Utz WXfGvep0o47cR3E9Hmy5hSq4RC1coiKSl27UVZ2/WqV1PyfBnL44GhnpIJijprAhTrjTE3V/dB5g Fd2jYRhK01i6/k+toO5KlKBjopDzm+PlviH44HJpKOszUNBnoJRPXy9CAVnw9d1w45/wZDJK3Qn0 NuuIVsYGz0KPSYXcUvTLhRpuDUN9peVKPCpcj0IN4ALOftvpxk6hBr+ksHT9Zy2oU8irYN40g2mo ZW7z6P7gWQMv56qNELIP0fy8hIthhZAwVr/lucHwo+Urjo7xxath8ctKfuvZ8fJmPcuKB6Yfmdt+ 3JBz0Zyar/3ZRP/WsU8+Udv2+B/eNpnq1aJxzyvtVx755LCdSpRf/4O56fOzFXmQzZ47t6XSPzF5 78idR449X1AUMGER53P9ffG8dw15zP4UCaPkxaDIN3JQSCyxy3g/Xl33RM6KTMrK/fgvIY98ovto SBaRxifkZHzy5WAyxbz4cyufiYQ+lXA0clLXww5aP0xdSsX8rR5eDq+EPeFEkrQLOiDaF5Owa9wf xMyIsgL8Gw6F5trVA5RPjFCfa2DzUUYeN5gx4nL3BrFqQMvkIJBZQ5RiYekHP1CK6vhm447L86d7 A6c+9/Vt3rX2c0fWXr6jnjkSXT6yNX+e/cKa/yZccEbZQbwDnmeEPHvsG4KNu/saZgT2ii12B1PB SnBn0Dsa/Er62fRS2vvv/p92iXnihOZoA0whDEQh7P2hn133MwITLMudQRsE61mIQg0kjnbLARlh 3WgASZAqHQtuSOTgS/D4JTj5Ejn5Evn3Ern2Ern2Enn6Evn3EsfvJKZILCtdkUTwpCURAMZfOwGb 5g02/HybRhgq4RL1cAn/nuSlivs1auanUSVJJwEHY9lmpn3RFuv2cVu0dROMjIpCiqaFirmEl88l vHySqIyEE4az/16I1UPLoZWQJ5SwOm5/R/G7SN6H0btfwvJgRpBByCUZcrefr6gT3RXvF2aD1v5O 3MBAaCy4DEHYe+4BkEdHDt2Q51uA3M5u/8JdM6crpVvZQ+Fyys70jZRu9TyzZhPW9tDszsMPP80e pLng2uc/vtkIJ2fYtc7MMAyP/Kd4+2l2zklqyF7DNEFj3n5jPjYfnzVeCq4a7xl+KJUzl3qGIJad YtpsNKMz0TnJ4w91mX4vAjZScTPmvhXmM6WoGjGxOPdF515FSGdT6fSEouogSoCQ+FElhL1QOoR/ KpHULDSEStqSKBCimoopKWS0Zb40DCOS10lpQU79l3qyX3GUWcWjHAj9mFFOHG6CslhNx/8GmewK 87BZurPW2EyD32HKKjUMp0dpqByfWzW8qsEu4jnEDHwJTyv3CkYcwavQQAgjqlbXEkisF3dT1BEq QSQxQvPxFZHEXLIhctdxsuE3qzdRDTu5T9YFf3luPp+IQTdrkAYV1d50k9EGfWf1kj7KRYTEzy9h tQMvnH/mfQzjmFw6lxgD0hdoMnQMPj5j77b/djQbq7Gf1XvjG75yeqg2ygY3jIy030iL3z1rJUE6 7I0ahXvaf87qD29CxpFCQdp0bi2PFXV47vxzPQd64K/6IHkD1p8on6MmUC5HyuSYQMxHGlEf6xka KTsj5Wasd/Iy3oKc95uQt3lEGBU2CzuQ/X4Cf8U5JewEJ3o3sLgZ5N+7A5ms70Ke5jlkndwrzONX GH4BPQEfSQDtcHb73um9u6p7PnXf0Qenj/7mnfffd/jTs3fVtt1/7OO37xH+F7BkHsUKZW5kc3Ry ZWFtCmVuZG9iagoxOSAwIG9iagoyMjI3NQplbmRvYmoKMTAgMCBvYmoKPDwgL1R5cGUgL0ZvbnQg L1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvQkVTUkhLK0FyaWFsTVQgL0ZvbnREZXNjcmlw dG9yCjIwIDAgUiAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcgL0ZpcnN0Q2hhciAzMiAvTGFz dENoYXIgMzIgL1dpZHRocyBbIDI3OApdID4+CmVuZG9iagoyMCAwIG9iago8PCAvVHlwZSAvRm9u dERlc2NyaXB0b3IgL0ZvbnROYW1lIC9CRVNSSEsrQXJpYWxNVCAvRmxhZ3MgMzIgL0ZvbnRCQm94 IFstNjY1IC0zMjUgMjAyOCAxMDA2XQovSXRhbGljQW5nbGUgMCAvQXNjZW50IDkwNSAvRGVzY2Vu dCAtMjEyIC9DYXBIZWlnaHQgNzI4IC9TdGVtViA5NSAvTGVhZGluZwozMyAvWEhlaWdodCA1MzAg L1N0ZW1IIDg0IC9BdmdXaWR0aCA0NDEgL01heFdpZHRoIDIwMDAgL0ZvbnRGaWxlMiAyMSAwIFIg Pj4KZW5kb2JqCjIxIDAgb2JqCjw8IC9MZW5ndGggMjIgMCBSIC9MZW5ndGgxIDY0NjAgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBhVkLeFTVtV57nzOPvMgkQDJJhswZhoySSQgEaCCJ ySSZCdgIBAg6Q4NMSCIBQSLhaRGGKqLDy3ItFbTioyrqVU4mkU4CXqKorShCleJbEOlV+xXBflXr g5z77zMDEuvXe3b+tdZea+3XOuvss89k2dLlrZRMIZLI07y4qZ30y9oClt28YpkSqyf7iYyjb2if vzhWT7+TyPDn+YtW3xCrW1GnRW2tTaKduL4HftYGhV4jNg58RNviZatidWsjuHnRkua43RpC3bi4 aVV8fHofdeWmpsWt4LiybCBK+5KOZXqVrP8Ev7J9aWvcn2F+iRp09VfuyH6b6O0qokFEDBoOUknN ZCBOFiqia4nkFPhKqAu7lHzk7atWH5+bWv6lOccMBdHDH1+RL3jvlIPrvt17Yb6l1JyMaoLuLwxo Z6ron0o1Fvp2b/9YS+kli7CKi3c2pFYNlzLpHKABEtlBi4BpwFxgG7AbMFJqXLMEfB1wEDgPGMkj ZUa2j/VEwTbprGvhomK92hSrNs7Rq13XBWJ8yvQY914dcyuNuY0ZF1OPqo7xKwpiPD2vOITOuxJT ivuqMqQMOgZwagdl/EVKZYzs9KA0lFSAS5iqrvFI6V0jXMW7D0oyMYlLjFrIrvVJLJKSVlyVyDV+ jtLJzj/nZ2MWfrZrUFrx7qqf89O0FzgISPw0ykf8I1rHTyGAFtBKYDdwEDgKnAOM/BTKSZQP+YeU yj+gIqASmAvsBg4C5wAT/wDUwt8Xt0OnQq4EOH8f1MLfw7LeA03l70J6l7+r9fE3IyUTi3t0wV0U F+x5cSEzJy6kZxRH+RuRb0bao/zjLsVtf7BqND9OKsAx2HF0fpwUoB4IAu2AEdIJSCcoBNwNPAio gBFtTqDNCbQ5DLwGnKDRgAeoB8z8WATDRPnRiKvaXpXBX+d/pEwE9Qj/k85f4y/r/FX+ks5fAc+F /TB/OZJrp6ok2AltLOAW8CLYDfz5rhHpdq0qjR9EkOygRUAlMA2YC2wDjPwgHx5psaejk/10GE+F nUfoM50/Rg+bybPQ7nHVIMcUQVylV0EC2a3sdnGPa8dOVAVxbd0OSRDX7ZshCeK6ZT0kQVyLVkAS xNWyEJIgrtlzIQnimtYACSTKH/jDiCvsJdNuZEpVKl+JKK1ElFYiSitJ5itFoW9kMcf7Ivn5iNgu j3tkvj3Uy0IHWGgGCz3MQq0stJaF1rNQOQtdz0JuFrKxUC4LeVhoP5uAUISYp3tAdaLHykKHWehp FupgIRcL5bHQCBZSWIknyh2Rq/Fggfl01lUlnivu6LqqojgVc3Qgog6ktQOP/UHQo4Cm1zxwUobH nLNyBR/elV8Zq48qLV5SNZkfQsNDuA2H6CQg4wYdQhodQieH0F0qaCUwF+gDzgEaYIT3cKxjm05T QYuASmAusA44Bxj16ZzDVDgtARVT3KtPrAi0EpgmavwQynAUB3d4hllsFrdlsrTNxlJz2bRcLZeX UEYGNrn0NHNalKXs+zrlX1+nUEJVAt/Kt9Ew3Ii743xb5Jth9ii7N+Lab68ayn5LuTKyjk0kF8sD n0Aden082cxCP45s/Cnw4ojtWjRLjbgK7L1skGi1z/6N7Yz9M1uUQ/zUtt/+lhKVWcT+F2ie2mc/ brvL/kpR1AzNAVeUgfUqumuPbYL96cO663oYdkXsawXbZ7/VNsl+o003tMYM13eg5km1z3DNtk9G f17bPLunA33us1farreXx7zGizb77KMxBXdMzMdkR9r0QZ25eoezSqKszVNg2mHym6aZfmYqNhWY HCa7aZgpxzTEnG62mAeZk82JZrPZaJbN3EzmIVHtlMct3ixDjBbBjEhoRrIuW7DDMLHNgOJ9Zub0 c1IHS3W8bmY1q1P7mqlunqJ+NdMZZYnTZ6sGZzVT0+uorqFaneCui5q0GWqJu0411f/C38nY1gC0 Kr8zyqjBH2WaUG3IUdNr/D3EWNqGLTmCX7lhSyBA1owVldbK9Iq0ibXenyBBXRn0un+4rD+Ibqt7 mLqjbqZffXJYQC0WgjYsUKf+10yl0d/D/sHO+7w97AvBAv4eqYL9wzdD6KUKbyBQF2XX6n6ksC/g h4wBg585lxThR4o5N+a3K+aXh/bwGyEY/BISKE/3y0tI0P1kJvw6O0b4vJ0jQOCTqVCH7tORqVzu czgPPnkg8MkI0WHd53BGSPioFXo3NhtcckHgwrLJprvYWLbuos+8U3cpirvcdcnlLn0kKTYb3UcQ dJNy6qJPyin4XBbI/yy2VrvdrKss0Nzoa3X6gk5fKxBUN61os6qheYrS2RwQBkWVXMF5zW2CN7Wq AWerV212epXOMr3dj8yNwlzm9HZSo6/B39noafVGyjxlPmeTN9A1qX5cyYCx7ro01rj6nxirXnQ2 Tow1SW/3o7FKhHmSGKtEjFUixprkmaSPRXqO1/s7zVQdqMH9E7yLJyUiX4M5jkB1hqW9Qk/eMod1 bU4vDiR7KMkdUJOd1WoKIPK6sKqwSpjwTAnTIKhT4ybr2jJHTi/bEzdZoE5zVpN72fKO5WT1LfDG /jpwQbVsubgVMeoWup+84OJTPU1ecVqtU/Nn1qmV02f7O00maIPeAHSlF3VJSb6o1hdTjoKyVDhK 0iVHoSsXuoSEuOO/54I+J6gRnR4cNPZ3MU8uW0YdAUnNrWvg2AoaZiMMjbP9vTguiZdERwAL7GBu 1nGxN7EON8VqhCV3XMSy5XEpHodlca67iiYdF8NxsSu3iBIZeikLyDY8Tlmyi6xE2ifAp4L3L9A+ FXbB+d+wrUXjINpDT7MF9DQdpBfYebTaSz3UTeLA46X7aQ3dQxvxEpsNzV00A8UA/T0sS+vGyf4h vB4foiPwvY7WUi9lMKv2Ga2jDdKbaLWBUmg4VVE9LaEt7BptOTXSSfk2KqFr6CZqZyHNr23Vtmu/ p0epR/qTdoGSKJuaUY5onxve1t6nQrT4De2kk2x7wrPkwSgheP6OltIuaY7MtPnat5iBg1ZiDjJN oSOsj7vReyt9wqxsjVSDXh7RVO1FeNloDrXRLupl49kk7jA0alO0I5SBMVah150UoX0oUXqO3mXJ hvPa77XzlEUFdDXW002vsz6p/8L6/krEzYAojaSJsCyh/6E/0jHmZM/zJYZkQ7HBY7hFO05DaAzN wmwfR8v/ZV/ztSjrpJflWq0aH0kb6Nci2vQSfcSyWRGbxq7lI/kS/oC0lMwYcQxKCy1AvO9F7x8i afbxZH5UekR+Sv7OOKz/lDYId8RF99Hv6HmWgpUqrIP9ip1gH/MaPpffx09L98hPyG+YmrDq62kx baGn6GuWziaw6ewXrI2tYRvZr9lOdoQdY5/yKt7Ab+TnpDbpZuk5uRplptwh32a4w7DJ+Gm/v//F /j/3f60Va3fQdOTDesz+N/QAVtZDR+kdlJN0mhlYEhuEojAHm8V+ibKWbWEPsz3sCdaNUY6x0+wz vIC+ZN9xvFe5kefgqCMOPE6+FOfJe/j9/CjKMf53/o2UKQ2X3NJ4qVwKSEswq43S3SjPSh/J2fJR WUOciw07DLsNewxPGV4wnDcmm36FN/pr3z9yIf/Ch/3Uf2f/jv5If7f2EQ3FPcS7At9U5Zh9E8pC 3O8dyLi99CZLRuyyWT6rYNcgMnPZQnYzW4VI3s52sUf1uT/DDiBKb7FzmHMKt+lzHsXH82o+DeV6 3spvxtFrO+/mJ/i3kklKklKloVK+NEmaI7VKy6TV0g5JlV6TPpBOS19J36NocqJsl4fLLtktT5Ln ysvlB+RP5E8MjYZXDX81JhoXG+8wRo1f4AxTYao3TTfNMW0z7TMdNweRnYfoWfoDMvDSxU5J6yWf 9Cxt5WPlLHywvI58nkst0hSOTOV72J38VtbNRxhWGct4GZtK52UXYv0y382/4mXSFFbHZtJCPibW oXGI/CSkcvkQnZUPYG2vo+dVxmS2lp8zJlMEJ6KJOBG9JI2W3dKr9K50kpnkh+g9OZFlsrP8cake WfCcXGHwk0O6n56Rbma30rPch18KvjNvRh5PZU9iX2hgxexfEn4P4FORRSXSx3Qb3cjfprN4ju+k 37IWeT5tpbFsDX1Cj+GpGGm4yZhvHMpe4QvkMB/MuonLT2B1E9kIJhmG0O1sjrTLeI6/Q8vpqJxI H0r/jdkf5c9IU+TzhhmsDU/ArXQH3aytp9UGv/wGm08Su5by5FPY3dZIxbIDfB12lUbsafvwdPdi H6iSpkBjReZcg7yYhR1iF8q92CdkZNACPOPXYRd7nbqNDTxK8w2DGHYd/NLxav8Mmq09Rju1+XST tp0KsR9s1Nagxz30V9pGe9iG/l9SOz4c38GzfY2hlh811GqFPMzf4TP5joH3F9HOY1b6G8ozVEsV hv0Ult+imVSpbdb+guy+EjvsTpqH4+kZrPJzjDBZ6qOx/VN5p1YrtWO9J2m69rhmZ4nUpi2iaXSA HjUZqMnk9tTMaqjyVFZcVV5WOnFCyfhxY4vHjC4aVVjgzh955RWuvBHO4Q7FnjvMlpOdZc3MGDpk cHqaJXVQSnJSYoLZZDTIEn7oKfA5a4OK6gqqsss5eXKhqDuboGi6TBFUFahqB/qoimjXBNMATw88 b/iRpyfm6bnkySxKOZUXFig+p6Ie8TqVKJs93Q95i9cZUNSzujxFl+/W5RTIDgcaKD5rm1dRWVDx qbUr2sK+oLewgHUmJdY4a1oTCwuoMzEJYhIkNdPZ3skyK5gu8ExfaScncwqWqGY7vT41y4mm6EbK 8zW1qPXT/T5vjsMRKCxQWU2zc55K4szj1l2oRh9GNdaoJn0YZQFOKyptUjoL+sKboxaaF3Qntzhb mhr9qtSEPnxqmhvjetXMW85Yf6iic5yuNl5uzZHCPusCRTiHwxsV9cHp/sva5jhED4EA+kBbnlcb DNdi6M24U3XiVK3yDQG/yjZgSBwR8/RVxdYXO7/mBRcqaoKz2tkWXhjErckOqzRjtSOSne3p0U5R tk8JN/idDrUyxxlo8to6h1B4xuquLI+SNdBSWNBpSYsFtnNQalxITrlcaEXQYzZd0t2FVDfjUmSZ mKPzapzpVKVZwUz8TqxpgiCtEyjcPAE3AFeAoZXagjuyQE2oCYYtpUKPJTLVkGdxKuEvCRngPPv3 gZqmuMaYZ/mShFHkyaVUU1nTRVl1u9X8fJEiphrcU8yxQq+PLyxYEeVOZ7sFX8Li+E/1iG1ToLQI 4Xc4xA3eFPXQPFTU0HR/rK7QvJwIeYpwSuZBYem7aBk6S1hCFy2XmgedyORu8WVKQ1Wz69JfqiVj sK+tVGUZ/8HcGrPXzXTW4ZCr+MLBeNbWNQyoxewioIgbbHFJHVzjl3I4dELiOZJujZ11L7rg4OtP VuU8/Bn1pG6JmszISl3DlFrVEpwco4FEhyP+zPx/jaLaedFKZz80iy9DLXXHJxqbtlo2oD5geslh qa4BWw7HGT0cThxgQ6rFZnl1nCHj8cnuUGpUmoUnMw9/+HiYIBDIUT0IGSwNeIp0dSAnXh3gmBNv FMAlsrOwoBZ7Zjhc61Rqw8FwU1QLzXMqFme4h7/AXwi3+7DbxRInqvVuylFrNwcQsTZWiseDU7V4 jGsa/PGV6zEX2Y3bhHwwil8t8I7GxfQEIfynwQgQKZc0+D8BivhdA8SAgtOxiaq7OTtjNEX5Ts9g MshnJEo0yWcYZZmNhjNcOoBDQgKOjKPI6rZ8VX6hfKrln+VTLpRTJWTL9yBjRjvSHGl5IPgVhb5X pL7vPQb6jhS5D2NhKFzaFTh7/dQl7JJuYJQen7lR/EOh2jdzxuQ6d9XSBU2LpjT8H8L6r4kKZW5k c3RyZWFtCmVuZG9iagoyMiAwIG9iago0MzYwCmVuZG9iagoyMyAwIG9iagooMjluMTMwNjYxKQpl bmRvYmoKMjQgMCBvYmoKKE1hYyBPUyBYIDEwLjguMiBRdWFydHogUERGQ29udGV4dCkKZW5kb2Jq CjI1IDAgb2JqCihDdWxsZW4gSmVubmluZ3MpCmVuZG9iagoyNiAwIG9iagooKQplbmRvYmoKMjcg MCBvYmoKKFdvcmQpCmVuZG9iagoyOCAwIG9iagooRDoyMDEyMTAyNDIxMTMxNlowMCcwMCcpCmVu ZG9iagoyOSAwIG9iagooKQplbmRvYmoKMzAgMCBvYmoKWyAoKSBdCmVuZG9iagoxIDAgb2JqCjw8 IC9UaXRsZSAyMyAwIFIgL0F1dGhvciAyNSAwIFIgL1N1YmplY3QgMjYgMCBSIC9Qcm9kdWNlciAy NCAwIFIgL0NyZWF0b3IKMjcgMCBSIC9DcmVhdGlvbkRhdGUgMjggMCBSIC9Nb2REYXRlIDI4IDAg UiAvS2V5d29yZHMgMjkgMCBSIC9BQVBMOktleXdvcmRzCjMwIDAgUiA+PgplbmRvYmoKeHJlZgow IDMxCjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDA2NDQ1NyAwMDAwMCBuIAowMDAwMDAzNjIwIDAw MDAwIG4gCjAwMDAwMDY2MzIgMDAwMDAgbiAKMDAwMDAwMDAyMiAwMDAwMCBuIAowMDAwMDAzNjAw IDAwMDAwIG4gCjAwMDAwMDM3MzQgMDAwMDAgbiAKMDAwMDAwNjU5NiAwMDAwMCBuIAowMDAwMDM2 MTkwIDAwMDAwIG4gCjAwMDAwMDY3NzUgMDAwMDAgbiAKMDAwMDA1OTMxMyAwMDAwMCBuIAowMDAw MDAzODYwIDAwMDAwIG4gCjAwMDAwMDY1NzUgMDAwMDAgbiAKMDAwMDAwNjcyNSAwMDAwMCBuIAow MDAwMDA3NDIyIDAwMDAwIG4gCjAwMDAwMDc2OTIgMDAwMDAgbiAKMDAwMDAzNjE2OCAwMDAwMCBu IAowMDAwMDM2NjQ5IDAwMDAwIG4gCjAwMDAwMzY5MjUgMDAwMDAgbiAKMDAwMDA1OTI5MSAwMDAw MCBuIAowMDAwMDU5NDg2IDAwMDAwIG4gCjAwMDAwNTk3NDYgMDAwMDAgbiAKMDAwMDA2NDE5NiAw MDAwMCBuIAowMDAwMDY0MjE3IDAwMDAwIG4gCjAwMDAwNjQyNDUgMDAwMDAgbiAKMDAwMDA2NDI5 NyAwMDAwMCBuIAowMDAwMDY0MzMxIDAwMDAwIG4gCjAwMDAwNjQzNTAgMDAwMDAgbiAKMDAwMDA2 NDM3MyAwMDAwMCBuIAowMDAwMDY0NDE1IDAwMDAwIG4gCjAwMDAwNjQ0MzQgMDAwMDAgbiAKdHJh aWxlcgo8PCAvU2l6ZSAzMSAvUm9vdCAxMyAwIFIgL0luZm8gMSAwIFIgL0lEIFsgPGRiZmZjOWQy MWUxM2JkNzEzZGY1NTQ4YzI4Mjk3NjJiPgo8ZGJmZmM5ZDIxZTEzYmQ3MTNkZjU1NDhjMjgyOTc2 MmI+IF0gPj4Kc3RhcnR4cmVmCjY0NjMyCiUlRU9GCg== --_002_C5E08FE080ACFD4DAE31E4BDBF944EB11189E17Bxmbalnx02ciscoc_-- From harald@alvestrand.no Wed Oct 24 23:24:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE5021F903D for ; Wed, 24 Oct 2012 23:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pR2x4tionNI2 for ; Wed, 24 Oct 2012 23:24:43 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1791C21F903B for ; Wed, 24 Oct 2012 23:24:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1265E39E129 for ; Thu, 25 Oct 2012 08:24:40 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qrsI9LjbTfj for ; Thu, 25 Oct 2012 08:24:38 +0200 (CEST) Received: from [172.30.42.70] (c-f8f1e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.241.248]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 4D7E339E029 for ; Thu, 25 Oct 2012 08:24:38 +0200 (CEST) Message-ID: <5088DB26.5020701@alvestrand.no> Date: Thu, 25 Oct 2012 08:24:38 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <0683D6CB32AC424D8AF52C0F660E5DC51509CFE0@xmb-aln-x10.cisco.com> In-Reply-To: <0683D6CB32AC424D8AF52C0F660E5DC51509CFE0@xmb-aln-x10.cisco.com> Content-Type: multipart/alternative; boundary="------------080009070402090307020009" Subject: Re: [rtcweb] Incoming liaison statement from MPEG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 25 Oct 2012 06:24:44 -0000 This is a multi-part message in MIME format. --------------080009070402090307020009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/24/2012 10:58 PM, David Benham (dbenham) wrote: > To further connect dots, this part 29 effort in MPEG/IEC/ISO towards a non-royalty bearing solution was mentioned in our draft below as a potential upside to selecting H264/AVC constrained baseline profile today. Unfortunately, the outcome will not be known soon enough, but to the extent future surprises weigh on our decision ... this one is positive! FWIW, there have been 11 IPR submissions into the ISO registry on MPEG-4 part 29 to date; 1 of them specifies that the IPR is available on a royalty free basis, 10 do not. Unless I miscounted. Apple deserves to be commended for making a royalty-free commitment, but it's a lonely position. The registry of IPR submissions is available at http://www.iso.org/iso/standards_development/patents > > > > http://tools.ietf.org/html/draft-dbenham-webrtc-videomti-00 > 6.4. Future IPR Status Consideration > For additional informative purposes, the MPEG/IEC/ISO made a call for > a royalty-free video coding solution for the Internet. As of its > 98th meeting, two tracks forward are being pursued; one of which is > based on the H.264/AVC constrained baseline profile [AVC06]. MPEG is > presently collecting patent licensing declarations that would include > patent holder's royalty expectations unbundled from other higher > profile mechanisms. Should this effort result in a royalty-free > constrained baseline profile, this would benefit RTCweb in the future > if H.264/AVC is selected as mandatory today. > > > > From: Stephan Wenger [mailto:stewe@stewe.org] > Sent: Wednesday, October 24, 2012 2:40 AM > To: video-codec@ietf.org; rtcweb@ietf.org > Subject: [rtcweb] Incoming liaison statement from MPEG > > Hi all, > Please find attached an incoming liaison statement from MPEG. It's short, and therefore attached. For those not familiar with MPEG's terminology: "AVC" stands for "Advanced Video Codec" and is used in certain circles for what other people know as H.264, and sometimes, depending on context, only for the non-scalable and non-multiview profiles of H.264. (H.264 is the ITU designation for the joint standard). MPEG-4 part 29, or WebVC is, as described in the statement, what most people know as "constrained baseline H.264", i.e. H.264 baseline without the rarely used tools known as Arbitrary Slice Order, Flexible Macroblock Order, and Redundant Slices. > Also, in order to avoid possible confusion, let me emphasize that this liaison statement comes from the standardization body known as MPEG (ISO/IEC JTC1/SC29/WG11 ) and not from the licensing administrator known as MPEG-LA. > Regards, > Stephan > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------080009070402090307020009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/24/2012 10:58 PM, David Benham (dbenham) wrote:
To further connect dots, this part 29 effort in MPEG/IEC/ISO towards a non-royalty bearing solution was mentioned in our draft below as a potential upside to selecting H264/AVC constrained baseline profile today.  Unfortunately, the outcome will not be known soon enough, but to the extent future surprises weigh on our decision ... this one is positive!
FWIW, there have been 11 IPR submissions into the ISO registry on MPEG-4 part 29 to date; 1 of them specifies that the IPR is available on a royalty free basis, 10 do not. Unless I miscounted.

Apple deserves to be commended for making a royalty-free commitment, but it's a lonely position.

The registry of IPR submissions is available at http://www.iso.org/iso/standards_development/patents




http://tools.ietf.org/html/draft-dbenham-webrtc-videomti-00
6.4.  Future IPR Status Consideration
   For additional informative purposes, the MPEG/IEC/ISO made a call for
   a royalty-free video coding solution for the Internet.  As of its
   98th meeting, two tracks forward are being pursued; one of which is
   based on the H.264/AVC constrained baseline profile [AVC06].  MPEG is
   presently collecting patent licensing declarations that would include
   patent holder's royalty expectations unbundled from other higher
   profile mechanisms.  Should this effort result in a royalty-free
   constrained baseline profile, this would benefit RTCweb in the future
   if H.264/AVC is selected as mandatory today.



From: Stephan Wenger [mailto:stewe@stewe.org] 
Sent: Wednesday, October 24, 2012 2:40 AM
To: video-codec@ietf.org; rtcweb@ietf.org
Subject: [rtcweb] Incoming liaison statement from MPEG

Hi all,
Please find attached an incoming liaison statement from MPEG.  It's short, and therefore attached.  For those not familiar with MPEG's terminology: "AVC" stands for "Advanced Video Codec" and is used in certain circles for what other people know as H.264, and sometimes, depending on context, only for the non-scalable and non-multiview profiles of H.264.  (H.264 is the ITU designation for the joint standard).  MPEG-4 part 29, or WebVC is, as described in the statement, what most people know as "constrained baseline H.264", i.e. H.264 baseline without the rarely used tools known as Arbitrary Slice Order, Flexible Macroblock Order, and Redundant Slices.
Also, in order to avoid possible confusion, let me emphasize that this liaison statement comes from the standardization body known as MPEG (ISO/IEC JTC1/SC29/WG11 ) and not from the licensing administrator known as MPEG-LA.
Regards,
Stephan



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

--------------080009070402090307020009-- From christer.holmberg@ericsson.com Thu Oct 25 06:50:49 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0594621F89B7 for ; Thu, 25 Oct 2012 06:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dCCa+vwfMII for ; Thu, 25 Oct 2012 06:50:48 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE9B21F89A4 for ; Thu, 25 Oct 2012 06:50:47 -0700 (PDT) X-AuditID: c1b4fb25-b7f926d00000661f-a6-508943b631ed Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B9.0E.26143.6B349805; Thu, 25 Oct 2012 15:50:46 +0200 (CEST) Received: from ESESSHC003.ericsson.se (153.88.183.27) by esessmw0191.eemea.ericsson.se (153.88.115.84) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 25 Oct 2012 15:50:46 +0200 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0318.001; Thu, 25 Oct 2012 15:50:45 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: JSEP-02 Comments Thread-Index: Ac2yt7t/ZNifzsQLTfGdplUZjCzVaA== Date: Thu, 25 Oct 2012 13:50:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B01E60F@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.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B01E60FESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvre42584Ag9m75SzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtMtBxgL3sRUnHrm2MA4O6CLkZNDQsBE4tXb10wQtpjEhXvr 2boYuTiEBE4xSnyf+hfK2ckosevZAzaQKiGBJYwSR5bmdzFycLAJWEh0/9MGCYsIqEtcfniB HcQWFpCU6Jo9nQ0iLifx7ekPJghbT2LlswWMIDaLgKrE3cWtrCA2r4C3xKMP95hBbEagI76f WgNWzywgLnHryXyo4wQkluw5zwxhi0q8fPyPFcJWlNh5tp0Zoj5fovnKLnaImYISJ2c+YYE4 WVuiZfEE9gmMIrOQjJ2FpGUWkhaIuI7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ipE9NzEz J73caBMjMEoObvmtuoPxzjmRQ4zSHCxK4rzWW/f4CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCU amBsLYkwkD2v8kb9UMSuuwu7BRREcmf+mfvuy/bIJrHvagcNS11zAg3+xqz54l26TWzKpYSi A+zxh+YyPr/36mRpXHb/hO2Kjz8HPf9XmJVh1nH6kGliQHjGy+tBP+cwTzbwFlq8415w82HB u/pWX1zEyrqZZjEtzOC8MEmr4f/tGQzRzF9Kwl4psRRnJBpqMRcVJwIAAP6Y+GACAAA= Subject: [rtcweb] JSEP-02 Comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 25 Oct 2012 13:50:49 -0000 --_000_7594FB04B1934943A5C02806D1A2204B01E60FESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Some comments on JSEP-02. Q1: Cloning I saw that you have removed the text about cloning from version -02. That is a rather fundamental change, so I think the change log should say a= little more than "Clarified section on forking.". Q2: Gone to W3C In the change log you say "Removed stuff that has moved to W3C specificaito= n". I think it would be good with a least some key words on exactly what ha= s been moved. I know I can do a diff with the previous version, but as one of the issues = have been what belongs to IETF and what belongs to W3C I don't think I shou= ld have to do that. Q3: Subsequent offer The text says: "In [RFC3264], the constraints at the signaling level is that only = one offer can be outstanding for a given session but from the media sta= ck level, a new offer can be generated at any point. For example, whe= n using SIP for signaling, if one offer is sent, then cancelled using= a SIP CANCEL, another offer can be generated even though no answer wa= s received for the first offer. To support this, the JSEP media laye= r can provide an offer whenever the Javascript application needs one for the signaling. The answerer can send back zero or more provisional answers, and finally end the offer-answer exchange by sending a final answer." This is one of the issues previously discussed, but IF we want support gene= rating a new offer while the previous one is still pending, then you need t= o state that only answers associated with the latest offer are provided bac= k to the browser. Q4: Remove offer This is related to the PRANSWER issue. Unless I've missed it, the draft does not address the issue raised on the l= ist, where an offer is received from the remote peer while in PRANSWER stat= e. (If you solved it on the list, I applogize for not having read it. I've had= a flu the whole week, so I am a little behind with my e-mails) Q5: Trickle ICE Don't get me wrong - I support the work on trickle ICE :) ' BUT, the trickle ICE draft is still "fresh from the owen", so I suggest to = e.g. add a note which says that the mechanism has still not been adopted, a= nd that people need to be aware that things may change. It may be clear to = people in IETF, but maybe not to others. Q6: ROAP Section A.1.1 shows a call flow example with ROAP. The latest version of draft-jennings-roap expired in may. Are we going to c= ontinue the work on ROAP? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B01E60FESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 <= /div>
Some comments on JSEP= -02.
 <= /div>
 <= /div>
Q1: Cloning
 <= /div>
I saw that you have r= emoved the text about cloning from version -02.
 <= /div>
That is a rather fund= amental change, so I think the change log should say a little more than &qu= ot;Clarified section on forking.".
 <= /div>
 <= /div>
Q2: Gone to W3C
 <= /div>
In the change log you= say "Removed stuff that has moved to W3C specificaiton". I think= it would be good with a least some key words on exactly what has been move= d.
 <= /div>
I know I can do a dif= f with the previous version, but as one of the issues have been what belong= s to IETF and what belongs to W3C I don't think I should have to do that.
 <= /div>
 <= /div>
Q3: Subsequent off= er
 <= /div>
The text says:=
   &nb= sp;   
   &nb= sp;    "In [RFC3264], the constraints at the signaling = level is that only one
   &nb= sp;     offer can be outstanding for a given session bu= t from the media stack
   &nb= sp;     level, a new offer can be generated at any poin= t.  For example, when
   &nb= sp;     using SIP for signaling, if one offer is sent, = then cancelled using a
   &nb= sp;     SIP CANCEL, another offer can be generated even= though no answer was
   &nb= sp;     received for the first offer.  To support = this, the JSEP media layer
   &nb= sp;     can provide an offer whenever the Javascript ap= plication needs one
   &nb= sp;     for the signaling.  The answerer can send = back zero or more
   &nb= sp;     provisional answers, and finally end the offer-= answer exchange by
   &nb= sp;     sending a final answer."
 <= /div>
This is one of the is= sues previously discussed, but IF we want support generating a new offer wh= ile the previous one is still pending, then you need to state that only ans= wers associated with the latest offer are provided back to the browser.
 <= /div>
 <= /div>
Q4: Remove offer
 <= /div>
This is related to th= e PRANSWER issue.
 <= /div>
Unless I've missed it= , the draft does not address the issue raised on the list, where an offer i= s received from the remote peer while in PRANSWER state.
 <= /div>
(If you solved it on = the list, I applogize for not having read it. I've had a flu the whole week= , so I am a little behind with my e-mails)
 <= /div>
 <= /div>
Q5: Trickle ICE
 <= /div>
Don't get me wrong - = I support the work on trickle ICE :) '
 <= /div>
BUT, the trickle ICE = draft is still "fresh from the owen", so I suggest to e.g. add a = note which says that the mechanism has still not been adopted, and that peo= ple need to be aware that things may change. It may be clear to people in IETF, but maybe not to others.
 <= /div>
 <= /div>
 <= /div>
Q6: ROAP
 <= /div>
Section A.1.1 shows a= call flow example with ROAP.
 <= /div>
The latest version of= draft-jennings-roap expired in may. Are we going to continue the work on R= OAP?
 <= /div>
 <= /div>
 <= /div>
Regards,
 <= /div>
Christer
 <= /div> --_000_7594FB04B1934943A5C02806D1A2204B01E60FESESSMB209ericsso_-- From matthew@matthew.at Thu Oct 25 15:26:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CD021F878B for ; Thu, 25 Oct 2012 15:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S53A7RIKsXLK for ; Thu, 25 Oct 2012 15:26:34 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74AEE21F8608 for ; Thu, 25 Oct 2012 15:26:34 -0700 (PDT) Received: from [10.80.68.50] (unknown [131.107.147.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 6D15D250021 for ; Thu, 25 Oct 2012 15:26:33 -0700 (PDT) Message-ID: <5089BC97.9000306@matthew.at> Date: Thu, 25 Oct 2012 15:26:31 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5082DE08.5040007@matthew.at> <20121021210147.GR6812@audi.shelbyville.oz> <5084C273.4070706@matthew.at> In-Reply-To: <5084C273.4070706@matthew.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] (resend) RE: Draft agenda for RTCWeb session 2 at IETF85 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 25 Oct 2012 22:26:35 -0000 Ok, so now that we've had one round of the usual debate that won't terminate, *how* much time on the agenda do we really want to spend debating the potential merits or flaws of codecs that some of us either will or will not use no matter what happens in the meeting? I really think there's more important things to discuss and specify. Matthew Kaufman From ted.ietf@gmail.com Thu Oct 25 16:14:20 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBAD21F84BB for ; Thu, 25 Oct 2012 16:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRwoDlXvPDsk for ; Thu, 25 Oct 2012 16:14:20 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9842A21F8476 for ; Thu, 25 Oct 2012 16:14:19 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so2709488vbb.31 for ; Thu, 25 Oct 2012 16:14: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=OgTeIBp9pAav0DsoPkByQV/kEXtZU7CTBfYgDjfSYok=; b=gRS7AKcM0W/XBKr26a68nNfOFFi4fhFHfKWnGjUK8uCo1nkJMgXFJeE7110bOamZxu yTTpG/q14PZf5IOhfWOjiAHPQiaqfvW2K5OkEZittIH1p6WfWbyAsMXS0dv9pqvdEaGH tfVj5sHiSPFappNLOc1sd17bls6GHCw/6hhgzmsR9aLQ96rITtB4w3hlxSBNieVxWdhe Tev2NTcm0bFkEY4PqlWDo80IExHVaUkV8aeBi6K6nCcT/c9ugDGuhyXcRsEaxRcrkeuS 5tu6CINqJQCq1vUk99f83D55AJIFw/OboQMzQgdE0ZfQV++wFh0YgvTN3z7lZ8P+c3yG VI9Q== MIME-Version: 1.0 Received: by 10.220.39.206 with SMTP id h14mr16909346vce.41.1351206858755; Thu, 25 Oct 2012 16:14:18 -0700 (PDT) Received: by 10.58.245.39 with HTTP; Thu, 25 Oct 2012 16:14:18 -0700 (PDT) In-Reply-To: <5089BC97.9000306@matthew.at> References: <5082DE08.5040007@matthew.at> <20121021210147.GR6812@audi.shelbyville.oz> <5084C273.4070706@matthew.at> <5089BC97.9000306@matthew.at> Date: Thu, 25 Oct 2012 16:14:18 -0700 Message-ID: From: Ted Hardie To: Matthew Kaufman Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] (resend) RE: Draft agenda for RTCWeb session 2 at IETF85 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 25 Oct 2012 23:14:20 -0000 On Thu, Oct 25, 2012 at 3:26 PM, Matthew Kaufman wrote: > Ok, so now that we've had one round of the usual debate that won't > terminate, *how* much time on the agenda do we really want The chairs are currently discussing how to compress the presentation time, and we hope to have a query to the authors very soon. That, presuming it works out, will regain some time. If there are short mic lines after the presentations, we will also gain time. We hope to have an update of the draft agenda that's currently update by early next week. Additional topics that you wish to see covered in any time we make available would be welcome. Ted From ron@debian.org Thu Oct 25 17:15:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F07721F8830 for ; Thu, 25 Oct 2012 17:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dq-crAl0tu0X for ; Thu, 25 Oct 2012 17:15:48 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC6021F881E for ; Thu, 25 Oct 2012 17:15:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGvViVB5LSaF/2dsb2JhbABEwjSBCYIeAQEEAQ4sHA8ZCwsYLhQYDYg1Bb4Oi2GDSYMkA44Lh2oBkD2DAg Received: from ppp121-45-38-133.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([121.45.38.133]) by ipmail04.adl6.internode.on.net with ESMTP; 26 Oct 2012 10:45:44 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 319ED4F8F3 for ; Fri, 26 Oct 2012 10:45:43 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Prtx5Ek+Nu75 for ; Fri, 26 Oct 2012 10:45:42 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 8E2F94F902; Fri, 26 Oct 2012 10:45:42 +1030 (CST) Date: Fri, 26 Oct 2012 10:45:42 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20121026001542.GG6812@audi.shelbyville.oz> References: <5082DE08.5040007@matthew.at> <20121021210147.GR6812@audi.shelbyville.oz> <5084C273.4070706@matthew.at> <5089BC97.9000306@matthew.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5089BC97.9000306@matthew.at> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] (resend) RE: Draft agenda for RTCWeb session 2 at IETF85 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 00:15:48 -0000 On Thu, Oct 25, 2012 at 03:26:31PM -0700, Matthew Kaufman wrote: > Ok, so now that we've had one round of the usual debate that won't > terminate, *how* much time on the agenda do we really want to spend > debating the potential merits or flaws of codecs that some of us > either will or will not use no matter what happens in the meeting? If you feel that the discussion has exhausted all the rationale that you have to offer, perhaps you'd like to summarise what you see as the potential merits and flaws of each candidate for us? "I will not use it no matter what", isn't much of a technical argument. "I cannot use it because people are still fighting in the courts over who actually has a licence and how much one should cost", is more than a technical problem, it's a real and present, and apparently quite enduring danger haunting H.264, and not just for the people otherwise ineligible to get a licence for it at all. Am I forgetting one, or is it really now the most litigated codec in the history of all codecs? But perhaps you have some other list of pros and cons that somehow changes that balance? I'd certainly like to see a concise summary of what I'm supposedly missing that means VP8 isn't technically the no-brainer choice to make here, in pretty much every respect that has been discussed. > I really think there's more important things to discuss and specify. I agree. But until we get past the question of MTI codecs that will ensure interoperability, the risk remains that those things will just be Rearranging The Deck Chairs. Again. So let's get some consensus on a summary of pros and cons for each, that will give us some reasoned basis to back whatever decision we do arrive at on this, and let us really move on. Double Hulled and Hopeful This Time, Ron From matthew@matthew.at Thu Oct 25 17:25:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E806021F8847 for ; Thu, 25 Oct 2012 17:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6mdr9bsDaPl for ; Thu, 25 Oct 2012 17:25:48 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A4121F8784 for ; Thu, 25 Oct 2012 17:25:48 -0700 (PDT) Received: from [10.80.68.50] (unknown [131.107.147.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 31062250021 for ; Thu, 25 Oct 2012 17:25:46 -0700 (PDT) Message-ID: <5089D888.5010600@matthew.at> Date: Thu, 25 Oct 2012 17:25:44 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5082DE08.5040007@matthew.at> <20121021210147.GR6812@audi.shelbyville.oz> <5084C273.4070706@matthew.at> <5089BC97.9000306@matthew.at> <20121026001542.GG6812@audi.shelbyville.oz> In-Reply-To: <20121026001542.GG6812@audi.shelbyville.oz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] (resend) RE: Draft agenda for RTCWeb session 2 at IETF85 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 00:25:49 -0000 On 10/25/2012 5:15 PM, Ron wrote: > On Thu, Oct 25, 2012 at 03:26:31PM -0700, Matthew Kaufman wrote: >> Ok, so now that we've had one round of the usual debate that won't >> terminate, *how* much time on the agenda do we really want to spend >> debating the potential merits or flaws of codecs that some of us >> either will or will not use no matter what happens in the meeting? > If you feel that the discussion has exhausted all the rationale > that you have to offer, perhaps you'd like to summarise what you > see as the potential merits and flaws of each candidate for us? > I think I made this clear in an earlier post. VP8 is not the product of a recognized standards body. This has negative technical implications and negative legal implications. I am not a lawyer, and this is an IETF list, so that's two reasons for me to not go into more detail on the latter. My employer happens to be a major browser vendor, has published blog postings that I've previously referenced on this topic, and nothing substantive has changed since those were posted as far as I can tell. As was pointed out by someone else, and quoted by me previously, the decision to include or not include a particular codec in a shipping product is not going to be made by any of the technical people on this list, and so discussing it here or at the meeting is pointless. And presenting *technical* arguments as to the superiority of one or another is likewise pointless. Matthew Kaufman From stewe@stewe.org Thu Oct 25 19:07:37 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B67321F8782 for ; Thu, 25 Oct 2012 19:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.421 X-Spam-Level: X-Spam-Status: No, score=-5.421 tagged_above=-999 required=5 tests=[AWL=1.178, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LE7prvmWLzFP for ; Thu, 25 Oct 2012 19:07:37 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id E34AE21F8758 for ; Thu, 25 Oct 2012 19:07:36 -0700 (PDT) Received: from mail249-tx2-R.bigfish.com (10.9.14.237) by TX2EHSOBE012.bigfish.com (10.9.40.32) with Microsoft SMTP Server id 14.1.225.23; Fri, 26 Oct 2012 02:07:36 +0000 Received: from mail249-tx2 (localhost [127.0.0.1]) by mail249-tx2-R.bigfish.com (Postfix) with ESMTP id 04AC21480129; Fri, 26 Oct 2012 02:07:36 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.133; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0710HT001.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: PS-19(zz98dI1432Izz1202h1d1ah1d2ah1082kzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received-SPF: pass (mail249-tx2: domain of stewe.org designates 157.56.236.133 as permitted sender) client-ip=157.56.236.133; envelope-from=stewe@stewe.org; helo=BY2PRD0710HT001.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail249-tx2 (localhost.localdomain [127.0.0.1]) by mail249-tx2 (MessageSwitch) id 135121725493745_1816; Fri, 26 Oct 2012 02:07:34 +0000 (UTC) Received: from TX2EHSMHS032.bigfish.com (unknown [10.9.14.238]) by mail249-tx2.bigfish.com (Postfix) with ESMTP id 0A84A94004D; Fri, 26 Oct 2012 02:07:34 +0000 (UTC) Received: from BY2PRD0710HT001.namprd07.prod.outlook.com (157.56.236.133) by TX2EHSMHS032.bigfish.com (10.9.99.132) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 26 Oct 2012 02:07:33 +0000 Received: from BY2PRD0710MB354.namprd07.prod.outlook.com ([169.254.11.195]) by BY2PRD0710HT001.namprd07.prod.outlook.com ([10.255.86.36]) with mapi id 14.16.0233.001; Fri, 26 Oct 2012 02:07:31 +0000 From: Stephan Wenger To: Ron , "rtcweb@ietf.org" Thread-Topic: [rtcweb] (resend) RE: Draft agenda for RTCWeb session 2 at IETF85 Thread-Index: AQHNsw8drh3MSFmwTke5aKMEz1Rnd5fLXUcA Date: Fri, 26 Oct 2012 02:07:31 +0000 Message-ID: In-Reply-To: <20121026001542.GG6812@audi.shelbyville.oz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.5] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [rtcweb] (resend) RE: Draft agenda for RTCWeb session 2 at IETF85 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 02:07:37 -0000 Hi Ron, A few comments inline. On 10.26.2012 08:15 , "Ron" wrote: [...] > >"I cannot use it because people are still fighting in the courts > over who actually has a licence and how much one should cost", >is more than a technical problem, it's a real and present, and >apparently quite enduring danger haunting H.264, and not just for >the people otherwise ineligible to get a licence for it at all. > >Am I forgetting one, or is it really now the most litigated codec >in the history of all codecs? Oh yes, you are forgetting MPEG-2. Out of the top of my head, I can recollect four high profile lawsuits regarding MPEG-2 video essential claims. I believe there have been several more, and enforcement is going on even in the most recent past (the Nero antitrust dispute being the most prominent one in the last three years). Many of those MPEG-2 related lawsuits were the result of enforcement action in an emerging licensing ecosystem that is based on royalties. I'm not aware of any video codec patent disputes, nor of any significant royalty-bearing licensing deals in the video codec space, before the advent of MPEG-2, formation of the related MPEG-LA pool, and the resulting wave of litigation. While there have been a few more, the single most prominent H.264 related lawsuit today is the action brought by Motorola/google against a number of companies that could be viewed as threatening the Android ecosystem. (Most of the older stuff is straightforward enforcement in a settled royalty-bearing ecosystem.) The Motorola lawsuits are IMO strategic disputes, and the use of video codec related patents is just a means to achieve a higher goal: keep the Android system competitive. Also, with respect to the Motorola lawsuits, it is my understanding that the patent claims being litigated are related to interlace technologies and, therefore, are not relevant to the practice of constrained baseline. I'm not going to discuss this further; those interested may want to consult the web or, much better, your trusted patent lawyer. [...] Stephan >But perhaps you have some other list of pros and cons that >somehow changes that balance? I'd certainly like to see a >concise summary of what I'm supposedly missing that means >VP8 isn't technically the no-brainer choice to make here, >in pretty much every respect that has been discussed. > > >> I really think there's more important things to discuss and specify. > >I agree. But until we get past the question of MTI codecs that >will ensure interoperability, the risk remains that those things >will just be Rearranging The Deck Chairs. Again. > >So let's get some consensus on a summary of pros and cons for >each, that will give us some reasoned basis to back whatever >decision we do arrive at on this, and let us really move on. > > Double Hulled and Hopeful This Time, > Ron > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb > From ron@debian.org Thu Oct 25 19:53:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAC721F8620 for ; Thu, 25 Oct 2012 19:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdH+qCJYFVVW for ; Thu, 25 Oct 2012 19:53:03 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAD721F84E0 for ; Thu, 25 Oct 2012 19:53:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAD76iVB5LSaF/2dsb2JhbABEwjSBCYIeAQEEATocFRMLCxguFBgNiDUFDL1mi2GGbQOOC4dqAYEXjyaDAg Received: from ppp121-45-38-133.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([121.45.38.133]) by ipmail04.adl6.internode.on.net with ESMTP; 26 Oct 2012 13:22:55 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id D03844F8F3 for ; Fri, 26 Oct 2012 13:22:54 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LW7g4kvOCvUE for ; Fri, 26 Oct 2012 13:22:53 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 5296E4F902; Fri, 26 Oct 2012 13:22:53 +1030 (CST) Date: Fri, 26 Oct 2012 13:22:53 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20121026025253.GH6812@audi.shelbyville.oz> References: <5082DE08.5040007@matthew.at> <20121021210147.GR6812@audi.shelbyville.oz> <5084C273.4070706@matthew.at> <5089BC97.9000306@matthew.at> <20121026001542.GG6812@audi.shelbyville.oz> <5089D888.5010600@matthew.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5089D888.5010600@matthew.at> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] (resend) RE: Draft agenda for RTCWeb session 2 at IETF85 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 02:53:04 -0000 On Thu, Oct 25, 2012 at 05:25:44PM -0700, Matthew Kaufman wrote: > On 10/25/2012 5:15 PM, Ron wrote: > >On Thu, Oct 25, 2012 at 03:26:31PM -0700, Matthew Kaufman wrote: > >>Ok, so now that we've had one round of the usual debate that won't > >>terminate, *how* much time on the agenda do we really want to spend > >>debating the potential merits or flaws of codecs that some of us > >>either will or will not use no matter what happens in the meeting? > >If you feel that the discussion has exhausted all the rationale > >that you have to offer, perhaps you'd like to summarise what you > >see as the potential merits and flaws of each candidate for us? > > > > I think I made this clear in an earlier post. VP8 is not the product > of a recognized standards body. This has negative technical > implications and negative legal implications. I am not a lawyer, and > this is an IETF list, so that's two reasons for me to not go into > more detail on the latter. > > As was pointed out by someone else, and quoted by me previously, the > decision to include or not include a particular codec in a shipping > product is not going to be made by any of the technical people on > this list, and so discussing it here or at the meeting is pointless. > And presenting *technical* arguments as to the superiority of one or > another is likewise pointless. That's a pretty good summary of the problems I'm seeing with the arguments against VP8 indeed. And exactly why I asked to see a more substantial summary of them. In the one breath you are saying "not the product of an SDO == Bad" is your only direct argument against it. And then you immediately follow that with "we should ignore anything this SDO has to say about it anyway". And then wonder why I'm more than a little bewildered about what exactly your argument is here? The decision of which codec should be MTI for this proposed standard not being the product of this recognised standards body, I completely agree would have negative technical and legal implications for it. Serious ones at that. It is far less clear in practice how much harm this does to a codec that was carefully designed by experts in that field though. It is clear that working within the IETF process did wonderful things for Opus -- but it is much less clear that the same people working together in the same way would have produced total crap if the efforts to oppose formation of the CODEC WG had been "successful" at that and they had done their work outside of an SDO instead. Where is the offensive patent pool against Theora that we've been hearing about for so many years? Or the single lawsuit against a user of it? What about Vorbis? Any problems it had were neither technical nor legal. Can nobody at all shed any light on the status of the mythical pool that wanted to attack VP8 which seems to have vanished in a whimper over a year ago? Did anyone sue Skype for SILK? How does the success of those compare to OOXML? I don't really see how your argument there is coherent with either itself or the observable reality. But you're insisting on it very strongly so I'm hoping you can clue us in on the missing link that makes it actually make some sense. > My employer happens to be a major browser vendor, has published blog > postings that I've previously referenced on this topic, and nothing > substantive has changed since those were posted as far as I can > tell. So that's the basis on which you think we should decide this? There are two other major browser vendors contributing here, and as I understand it, they both prefer VP8. Since they have the lion's share of users, why shouldn't their preference stand if this logic is applied? You say nothing substantive has changed since then. The slope on this graph looks like pretty substantive change to me: http://upload.wikimedia.org/wikipedia/commons/8/86/Usage_share_of_web_browsers_%28Source_StatCounter%29.svg The numbers here look pretty substantive too: http://www.w3schools.com/browsers/browsers_stats.asp But personally I'd still much rather see us build consensus around a clear list of agreed pros and cons, so that when people look back and wonder "how did the RTCWeb WG make that decision" we will have something a bit more substantive to show for it than "via a farce where industry heavyweights had their preference rubber-stamped without discussion or justification that held up to even the most casual scrutiny." I'm pretty sure this still is a technical standards group, and that technical arguments to back up its decisions mostly aren't pointless. Unabashedly, Ron From fluffy@cisco.com Thu Oct 25 20:51:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F00D21F84C7 for ; Thu, 25 Oct 2012 20:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.403 X-Spam-Level: X-Spam-Status: No, score=-110.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZI410+U0bGA for ; Thu, 25 Oct 2012 20:51:03 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB8521F84A2 for ; Thu, 25 Oct 2012 20:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4168; q=dns/txt; s=iport; t=1351223463; x=1352433063; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GUIOpw5W1NA7zxjDcNOd5BgKOt6vZRdGTSY6ApI2KyA=; b=g6HyAVASdUAPhmsJ7AknpiMe9+CiGnHRkLgQfX336hWmhbkosdTYZ0D3 TEMgYhgweZYhSiMyxGVG21gxXCpgxY7nuMxstWuh2c7vWWbTWHYNMmO6Q iJD75UkWJybe0wapLFxF21GAA7E3UBN8oltwm8uMcxNY/fV5TY8CQxfia Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMkHilCtJXHA/2dsb2JhbABEwjaBCIIeAQEBAwEBAQEPAVsLEAIBCCIkJwslAgQOBQgah1wGC50toBEEi2iGDWEDpEiBa4JvgVsEHB4 X-IronPort-AV: E=Sophos;i="4.80,652,1344211200"; d="scan'208";a="135546433" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 26 Oct 2012 03:51:02 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9Q3p2JX018164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Oct 2012 03:51:02 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Thu, 25 Oct 2012 22:51:02 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [rtcweb] JSEP-02 Comments Thread-Index: AQHNsy0de5cVNbEPzEepXAhnPxKyUQ== Date: Fri, 26 Oct 2012 03:51:01 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B01E60F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B01E60F@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19306.000 x-tm-as-result: No--47.282700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <411E94A2ED117449A0666409016B3F2E@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-02 Comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 03:51:04 -0000 Thanks for the review and suggestions, inline =85 On Oct 25, 2012, at 7:50 AM, Christer Holmberg wrote: > =20 > Hi, > =20 > Some comments on JSEP-02. > =20 > =20 > Q1: Cloning > =20 > I saw that you have removed the text about cloning from version -02. > =20 > That is a rather fundamental change, so I think the change log should say= a little more than "Clarified section on forking.". agree > =20 > =20 > Q2: Gone to W3C > =20 > In the change log you say "Removed stuff that has moved to W3C specificai= ton". I think it would be good with a least some key words on exactly what = has been moved. > =20 > I know I can do a diff with the previous version, but as one of the issue= s have been what belongs to IETF and what belongs to W3C I don't think I sh= ould have to do that. fair enough - to be honest, we ran out of time on some of this. You will no= tice the draft went in seconds before the deadline and the references are a= lso woefully inadequate.=20 > =20 > =20 > Q3: Subsequent offer > =20 > The text says: > =20 > "In [RFC3264], the constraints at the signaling level is that onl= y one > offer can be outstanding for a given session but from the media = stack > level, a new offer can be generated at any point. For example, = when > using SIP for signaling, if one offer is sent, then cancelled us= ing a > SIP CANCEL, another offer can be generated even though no answer= was > received for the first offer. To support this, the JSEP media l= ayer > can provide an offer whenever the Javascript application needs o= ne > for the signaling. The answerer can send back zero or more > provisional answers, and finally end the offer-answer exchange b= y > sending a final answer." > =20 > This is one of the issues previously discussed, but IF we want support ge= nerating a new offer while the previous one is still pending, then you need= to state that only answers associated with the latest offer are provided b= ack to the browser. I agree with what you are saying but I think it gets a little more complica= ted once we include the roll back. I hope to get the roll back in the next = version but yes, agree with this along with some exceptions to it when doin= g roll back.=20 > =20 > =20 > Q4: Remove offer > =20 > This is related to the PRANSWER issue. > =20 > Unless I've missed it, the draft does not address the issue raised on the= list, where an offer is received from the remote peer while in PRANSWER st= ate. > =20 > (If you solved it on the list, I applogize for not having read it. I've h= ad a flu the whole week, so I am a little behind with my e-mails)] that's a signaling problem. I doubt the draft should address it any more th= an there are a few ways of dealing with it and Javascript can do whatever i= t wants to choose which one it wants.=20 > =20 > =20 > Q5: Trickle ICE > =20 > Don't get me wrong - I support the work on trickle ICE :) ' > =20 > BUT, the trickle ICE draft is still "fresh from the owen", so I suggest t= o e.g. add a note which says that the mechanism has still not been adopted,= and that people need to be aware that things may change. It may be clear t= o people in IETF, but maybe not to others. > =20 agree - (actually, I think the ICE draft is still getting ready to go in th= e oven :-) > =20 > =20 > Q6: ROAP > =20 > Section A.1.1 shows a call flow example with ROAP. > =20 > The latest version of draft-jennings-roap expired in may. Are we going to= continue the work on ROAP? > =20 I really have no idea. At first I thought I should take this out. Then I wa= nted to show something that mapped to another signaling protocol. This shou= ld probably go, but something should be put there to help illustrate this t= ype of flow.=20 > =20 > =20 > Regards, > =20 > Christer > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Thu Oct 25 21:03:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F3C21F85AF for ; Thu, 25 Oct 2012 21:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.41 X-Spam-Level: X-Spam-Status: No, score=-110.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+xudjIDQaK1 for ; Thu, 25 Oct 2012 21:03:09 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 68E3721F85AC for ; Thu, 25 Oct 2012 21:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1448; q=dns/txt; s=iport; t=1351224189; x=1352433789; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SYDzWlg/4qW31g0+9JzOuds0IkfRS0gjdDIbmKusMFg=; b=O+7fnMjpnl1A7U0qNVwCaEKDk3s2DEJdaMtkoP0P5rqbrkmQZHnCxHXH BfH/0gz4hzSYYCoKbNv3IxgUH/9eZ3zP3ODPhTvXZRdyssxQ7txqoEHvQ hogmMWKR2+2gy8DpqOQoEFCH+iboxW47aFSKJ6+3lqDb7myXav37yD5hc c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAF0KilCtJXG9/2dsb2JhbABEwjaBCIIeAQEBAwESAWYQAgEIIiQyJQIEDgUIGodcBp07oBaLaIYNYQOIJ5whgWuCb4FbBBwe X-IronPort-AV: E=Sophos;i="4.80,652,1344211200"; d="scan'208";a="135546577" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 26 Oct 2012 04:03:09 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9Q438SZ008220 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Oct 2012 04:03:08 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Thu, 25 Oct 2012 23:03:08 -0500 From: "Cullen Jennings (fluffy)" To: "Hutton, Andrew" Thread-Topic: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) Thread-Index: AQHNsy7OJlblz8WGukqs9e6Gndepcg== Date: Fri, 26 Oct 2012 04:03:07 +0000 Message-ID: References: <201210182110.q9ILAq4K4836140@shell01.TheWorld.com> <5080F1E9.2050509@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF0130A101@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0130A101@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19306.000 x-tm-as-result: No--33.823400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 04:03:10 -0000 On Oct 19, 2012, at 3:23 AM, "Hutton, Andrew" wrote: >=20 > RFC3624 requires that the session reverts to the state prior to the offer= if the offer/answer exchange fails.=20 >=20 > If an applications attempts to modify a session but the updated offer is = rejected by the far end there should be no interruption to the existing ses= sion. Like Roman suggested I am also thinking it would be nice if the API p= rovided some way of cancelling an offer and reverting to the original state= but if this is putting too much state back in the browser we would need a = clearly documented mechanism. We talked about this before and I think just about everyone agrees that we = need rollback in JSEP. And it's not just needed for gatewaying with SIP, a= ny signaling protocol that wanted to allow simultaneous changes is likely n= eed it. It's not yet fully defined in the current draft because we need to= get stable on what we do the initial "O/A" pair before we step into the mo= difications of it. In SIP terms this would be let make sure we understand i= nitial INVITE before taking on UPDATE.=20 I agree this is 1) needed and 2) needs to be well defined in JSEP 3) it's n= ot well defined in current draft. The idea/hope is that the current API wil= l support rollback with no change to the API, we just have to write down th= e semantics and check all the details work. = From christer.holmberg@ericsson.com Mon Oct 29 05:44:07 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850DB21F85CD for ; Mon, 29 Oct 2012 05:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQBEFL-aqjTk for ; Mon, 29 Oct 2012 05:44:06 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 20C8E21F85C5 for ; Mon, 29 Oct 2012 05:44:05 -0700 (PDT) X-AuditID: c1b4fb25-b7f926d00000661f-c4-508e7a140ad1 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id FE.49.26143.41A7E805; Mon, 29 Oct 2012 13:44:04 +0100 (CET) Received: from ESESSHC016.ericsson.se (153.88.183.66) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 29 Oct 2012 13:44:04 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0318.001; Mon, 29 Oct 2012 13:44:03 +0100 From: Christer Holmberg To: "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] JSEP-02 Comments Thread-Index: Ac2yt7t/ZNifzsQLTfGdplUZjCzVaAAZJ5CAAK2UXaA= Date: Mon, 29 Oct 2012 12:44:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0206F0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B01E60F@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+Jvra5IVV+AwcfJGhYdk9ks1v5rZ3dg 8pjyeyOrx5IlP5kCmKK4bFJSczLLUov07RK4Mr69OMNcsJqj4to+8QbGrWxdjJwcEgImEkda P7ND2GISF+6tB4pzcQgJnGSUaL/8iAXC2ckosfL8LlYIZwmjxPUTzYxdjBwcbAIWEt3/tEG6 RQQMJZr2zGMCsZkF1CXuLD4HNlVYQE1i6/lLjBA16hK/Ly9jhrCtJLZMaWMFsVkEVCVuPlsL VsMr4C3xZvJlqMV9jBILH20AG8Qp4CvRtKEN7GxGoFO/n1oDtUxc4taT+UwQLwhILNlznhnC FpV4+fgfK4StKLHzbDszRL2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJC4gtBBRvWTyBfQKjxCwk K2YhaZ+FpH0WkvYFjCyrGNlzEzNz0suNNjECY+rglt+qOxjvnBM5xCjNwaIkzmu9dY+/kEB6 YklqdmpqQWpRfFFpTmrxIUYmDk6pBkbBf5qFOUaOf9rTLmRdL4qYWFNoPu2S9ZrPKq90T57Y U8t9rVTx4z8TlaZ5vGHr7pldmzGz6bhjYtfTKwGnGJepPCqo/xp4fuaGHpd13joPousWB+y0 12CxbnhzmKlCctentszazMKIEg7TXU6euQaiZgGe81V/cZyQ4i3e+H3JngoNaaEQRyWW4oxE Qy3mouJEALwGTEV3AgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-02 Comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Oct 2012 12:44:07 -0000 Hi, =20 >> Q1: Cloning >> =20 >> I saw that you have removed the text about cloning from version -02. >> =20 >> That is a rather fundamental change, so I think the change log should sa= y a little more than "Clarified section on forking.". > > agree And, do we have a WG concensus to remove cloning? >> Q4: Remove offer >> =20 >> This is related to the PRANSWER issue. >> =20 >> Unless I've missed it, the draft does not address the issue raised on th= e list, where an offer is received from the remote peer while in PRANSWER s= tate. >> =20 >> (If you solved it on the list, I applogize for not having read it. I've = had a flu the whole week, so I am a little behind with my e-mails)] > > that's a signaling problem. I doubt the draft should address it any more = than there are a few ways of dealing with it and Javascript can do whatever= it wants to choose which one it wants.=20 It's a use-case I'd like the API to support. But, even without PRANSWER it would be tricky, as you have removed cloning. Regards, Christer From magnus.westerlund@ericsson.com Mon Oct 29 08:12:47 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92F021F881A for ; Mon, 29 Oct 2012 08:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZjw1y-jRiU4 for ; Mon, 29 Oct 2012 08:12:46 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A5B5421F853E for ; Mon, 29 Oct 2012 08:12:44 -0700 (PDT) X-AuditID: c1b4fb25-b7f926d00000661f-d6-508e9ceb10d0 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 34.0F.26143.BEC9E805; Mon, 29 Oct 2012 16:12:43 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Mon, 29 Oct 2012 16:12:43 +0100 Message-ID: <508E9CEA.2060709@ericsson.com> Date: Mon, 29 Oct 2012 16:12:42 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEJMWRmVeSWpSXmKPExsUyM+Jvre7rOX0BBj/Pq1ms/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujN2LfzAVfBeomNbYwd7AeJSvi5GTQ0LARGLjpNtsELaYxIV7 64FsLg4hgZOMEus/PmOFcJYzSnze3s0EUsUroC2xqq2ZEcRmEVCV2L1pFTuIzSZgIXHzRyNQ NweHqECwxPOOYohyQYmTM5+wgNgiAuoSlx9eACsXFrCR+HDlBRPEYkmJt+9fMYPYzAJ6ElOu tjBC2PISzVtng8WFgNY2NHWwTmDkn4Vk7CwkLbOQtCxgZF7FyJ6bmJmTXm60iREYTge3/Fbd wXjnnMghRmkOFiVxXuute/yFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MHb2d9zg3LpYUT8y 3Cz4apbXLse2VpmvQR/8b+X+XJTwb08Ng2LXaUGL78HBD5KulOyK6JfinZm8eTnvlvjjgRZT A662sa3tUHQoT+69whYV/yQ4PCjz+5TDR7RmX1q6SUy38ad1Y7eTwca8v6npMjGKs/XyxDic DnplfZM6YPqYTXVL+gwNJZbijERDLeai4kQAqZDAPPUBAAA= Subject: [rtcweb] RTCWEB WG document's dependencies outside of the WG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Oct 2012 15:12:47 -0000 WG, I spent a little time reviewing what dependencies we have in our current set of WG drafts on I-Ds in other WGs. The below is the result of that analysis. I can't promise that all listed are actually still relevant normative references, they can equally be left overs. I for example found two reference issues in my own WG document on the RTP usage. But I think it gives us good indication that the WG memebers needs to be active and contribute to work in at least MMUSIC, AVTCORE and TSVWG to enable our WG to finish its work. There are more WGs where things goes on that are relevant, like the OPUS payload format in the PAYLOAD WG. draft-spittka-payload-rtp-opus-01 which wasn't referenced by either the audio-codec doc or the RTP usage one. Please review and comment on these documents so they make progress. MMUSIC draft-ietf-mmusic-sctp-sdp-02 draft-ietf-mmusic-traffic-class-for-sdp-02 draft-ietf-mmusic-sdp-bundle-negotiation-01 draft-alvestrand-mmusic-msid-01 draft-rescorla-mmusic-ice-trickle-00 AVTCORE draft-ietf-avtcore-rtp-circuit-breakers-00 draft-ietf-avtcore-srtp-encrypted-header-ext-02 draft-ietf-avtext-multiple-clock-rates-06 draft-rescorla-avtcore-6222bis-00 draft-terriberry-avp-codecs-00 draft-ietf-avtcore-multi-media-rtp-session-01 Potentially some of these: draft-lennox-avtcore-rtp-multi-stream-01 draft-westerlund-avtcore-transport-multiplexing-04 draft-westerlund-avtcore-rtp-topologies-update-01 draft-westerlund-avtcore-multiplex-architecture-02 draft-ietf-avt-srtp-ekt-03 TSVWG draft-tuexen-tsvwg-sctp-dtls-encaps-01 draft-ietf-tsvwg-sctp-udp-encaps-06 Behave draft-muthu-behave-consent-freshness-01 Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From petithug@acm.org Mon Oct 29 09:09:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8265821F86E7 for ; Mon, 29 Oct 2012 09:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCoNEo2+KxiI for ; Mon, 29 Oct 2012 09:09:33 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 55E6921F8724 for ; Mon, 29 Oct 2012 09:09:33 -0700 (PDT) Received: from [IPv6:2601:9:4b80:32:d167:5bc:8530:b7f7] (unknown [IPv6:2601:9:4b80:32:d167:5bc:8530:b7f7]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 591C920F19; Mon, 29 Oct 2012 16:09:31 +0000 (UTC) Message-ID: <508EAA3C.6040104@acm.org> Date: Mon, 29 Oct 2012 09:09:32 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.10) Gecko/20121027 Icedove/10.0.10 MIME-Version: 1.0 To: Magnus Westerlund References: <508E9CEA.2060709@ericsson.com> In-Reply-To: <508E9CEA.2060709@ericsson.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB WG document's dependencies outside of the WG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Oct 2012 16:09:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Please note that http://www.w3.org/TR/webrtc/ have normative references to: http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uris http://tools.ietf.org/html/draft-nandakumar-rtcweb-stun-uri On 10/29/2012 08:12 AM, Magnus Westerlund wrote: > WG, > > I spent a little time reviewing what dependencies we have in our current > set of WG drafts on I-Ds in other WGs. The below is the result of that > analysis. I can't promise that all listed are actually still relevant > normative references, they can equally be left overs. I for example found > two reference issues in my own WG document on the RTP usage. But I think it > gives us good indication that the WG memebers needs to be active and > contribute to work in at least MMUSIC, AVTCORE and TSVWG to enable our WG > to finish its work. > > There are more WGs where things goes on that are relevant, like the OPUS > payload format in the PAYLOAD WG. draft-spittka-payload-rtp-opus-01 which > wasn't referenced by either the audio-codec doc or the RTP usage one. > > Please review and comment on these documents so they make progress. > > MMUSIC draft-ietf-mmusic-sctp-sdp-02 > draft-ietf-mmusic-traffic-class-for-sdp-02 > draft-ietf-mmusic-sdp-bundle-negotiation-01 > draft-alvestrand-mmusic-msid-01 draft-rescorla-mmusic-ice-trickle-00 > > > AVTCORE draft-ietf-avtcore-rtp-circuit-breakers-00 > draft-ietf-avtcore-srtp-encrypted-header-ext-02 > draft-ietf-avtext-multiple-clock-rates-06 > draft-rescorla-avtcore-6222bis-00 draft-terriberry-avp-codecs-00 > draft-ietf-avtcore-multi-media-rtp-session-01 > > Potentially some of these: draft-lennox-avtcore-rtp-multi-stream-01 > draft-westerlund-avtcore-transport-multiplexing-04 > draft-westerlund-avtcore-rtp-topologies-update-01 > draft-westerlund-avtcore-multiplex-architecture-02 > draft-ietf-avt-srtp-ekt-03 > > TSVWG draft-tuexen-tsvwg-sctp-dtls-encaps-01 > draft-ietf-tsvwg-sctp-udp-encaps-06 > > Behave draft-muthu-behave-consent-freshness-01 > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 Färögatan 6 > | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: > magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQjqo0AAoJECnERZXWan7EoJ4P/3X/4MGkGtCSZaK9mTSRfU3u S8Tc9eMkuRH7TNQNuO8H752tBdxvJLhnfoT77NNhsOdkanMYGjDbR/9RPuRhQioq tecrX6sC7VLSnZAHPmUasAF4lJAHma6+ypuU/lxI7Ej3tw5ISCv03beVhhe7pMWC LIbW+Efq2HzjsW0UZb0xKl0oNBqI87E812k3r1ThHRC8I6LRzHipMpb2o0RDv0tU PbzCAVv9Xre7MPhhPxo+cbGFxZ8gX3xVRjYdlFrECmvVrCXdwmhNDG4yqe10Q5MX Qk+iamOGBZ0YCYoT83qJG534WOR0k4QEwFXV85I7ns9RpBmXITBhamGdDvxtujpX awYWSnkf7KVOBFMv+auCPKUTEZy/XfV5IjitumBm4pixKTz512uNckSUTLlJolAW 6QMWQjFsJPMd+xF6Qec2ihGR7mDER6Bsu1schshHfOLC+5HlQwXobWPVagOaou/Z ky/JnDaqA9VzzAn0JpjwQV21U9cmg0naDuKT0bi6BoBV3h2r8dN9pMqs6+K2ngoh aDwvOa+kutWF2l3P37FKNuP+bJVG5h8mMvn6++wWBO3zNQNYFGX+OcWGxifels01 G1dR6uEMldLN+b2jGr5Av2ekcgMBrDAw1UWEKnjMZMhFWWz9vjdjAH2jy1NtgsFK JUcmrNQ6ZSLZZeXBoYfI =1P4/ -----END PGP SIGNATURE----- From lars@netapp.com Mon Oct 29 10:17:10 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C34821F86E5 for ; Mon, 29 Oct 2012 10:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hi5sH4WQqcm for ; Mon, 29 Oct 2012 10:17:09 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id A2C2A21F86E1 for ; Mon, 29 Oct 2012 10:17:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,673,1344236400"; d="p7s'?scan'208";a="705028827" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 29 Oct 2012 10:17:08 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q9THH7fY001096; Mon, 29 Oct 2012 10:17:08 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.216]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0318.001; Mon, 29 Oct 2012 10:17:07 -0700 From: "Eggert, Lars" To: Magnus Westerlund Thread-Topic: [rtcweb] RTCWEB WG document's dependencies outside of the WG Thread-Index: AQHNtefdgy31qK6ElEe0UoGHCi0SwpfQ+/QA Date: Mon, 29 Oct 2012 17:16:53 +0000 Message-ID: References: <508E9CEA.2060709@ericsson.com> In-Reply-To: <508E9CEA.2060709@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/signed; boundary="Apple-Mail=_63176361-6DAD-417F-9643-46DEA22054CF"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWEB WG document's dependencies outside of the WG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Oct 2012 17:17:10 -0000 --Apple-Mail=_63176361-6DAD-417F-9643-46DEA22054CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Oct 29, 2012, at 16:12, Magnus Westerlund = wrote: > I spent a little time reviewing what dependencies we have in our = current > set of WG drafts on I-Ds in other WGs. The below is the result of that > analysis. Great overview! You will probably in the near future also grow some dependencies to = RMCAT documents, once we have started adopting some. Lars= --Apple-Mail=_63176361-6DAD-417F-9643-46DEA22054CF Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTAyOTE3MTcwM1owIwYJKoZIhvcNAQkEMRYEFJ36 nxjCsiLwvj3tIq/ObbPVx+A4MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAHhA8fxn z6x3oAb+41ohPsYENCm/JCbHGPLdrynzNoJKjWWDyC4t4cY1FJgVSYYPG+9GhlpCvRGZLY/09ytw 07PcE/7Dt41d+G8+1DhCQPukYJWl9UU2LQjUWOfnEAsfVfGEhH0AhnlhpRR2yeE94H1NkJxL3sFT joHb4joQ2OZ+/p/CX64u1UZiSbtkdIsAAKgtyH6fkHm6kRFPVOKnaBhQfLl0+1ncB4J3yaI6aw6P CeNrLSIYn+WMt4qMAt+Q/0QzCDdcVf9P+umnT99DNSRbufMlUfoaeE9h0tgE2j5LYSievFZFxIzt hy0QWuagToT5w2DPTeSSQsiqV3g4ZQQAAAAAAAA= --Apple-Mail=_63176361-6DAD-417F-9643-46DEA22054CF-- From stewe@stewe.org Mon Oct 29 10:50:57 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E6C21F86FC for ; Mon, 29 Oct 2012 10:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxlI7pYGJVTS for ; Mon, 29 Oct 2012 10:50:57 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEC221F86EA for ; Mon, 29 Oct 2012 10:50:56 -0700 (PDT) Received: from mail32-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.23; Mon, 29 Oct 2012 17:50:55 +0000 Received: from mail32-va3 (localhost [127.0.0.1]) by mail32-va3-R.bigfish.com (Postfix) with ESMTP id 2ED5E12023D; Mon, 29 Oct 2012 17:50:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.133; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0710HT001.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: PS-19(zz98dIc89bh1432Izz1202h1d1ah1d2ah1082kzz1033IL17326ah8275bh8275dhz2fh2a8h668h839hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received-SPF: pass (mail32-va3: domain of stewe.org designates 157.56.236.133 as permitted sender) client-ip=157.56.236.133; envelope-from=stewe@stewe.org; helo=BY2PRD0710HT001.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail32-va3 (localhost.localdomain [127.0.0.1]) by mail32-va3 (MessageSwitch) id 1351533053442227_13721; Mon, 29 Oct 2012 17:50:53 +0000 (UTC) Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.248]) by mail32-va3.bigfish.com (Postfix) with ESMTP id 5DBADE00D5; Mon, 29 Oct 2012 17:50:53 +0000 (UTC) Received: from BY2PRD0710HT001.namprd07.prod.outlook.com (157.56.236.133) by VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 29 Oct 2012 17:50:51 +0000 Received: from BY2PRD0710MB354.namprd07.prod.outlook.com ([169.254.11.195]) by BY2PRD0710HT001.namprd07.prod.outlook.com ([10.255.86.36]) with mapi id 14.16.0233.002; Mon, 29 Oct 2012 17:50:50 +0000 From: Stephan Wenger To: Magnus Westerlund , "rtcweb@ietf.org" Thread-Topic: [rtcweb] RTCWEB WG document's dependencies outside of the WG Thread-Index: AQHNtefn2rkrrTS91E6N+hhuLN5fnZfRFiaA Date: Mon, 29 Oct 2012 17:50:50 +0000 Message-ID: In-Reply-To: <508E9CEA.2060709@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.86.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <358EDECABE24C04EA509153417F37E76@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [rtcweb] RTCWEB WG document's dependencies outside of the WG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Oct 2012 17:50:58 -0000 If you are an VP8 fan, you may also want to add the VP8 payload format: http://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ This doc is currently in last call in the payload WG. Stephan On 10.29.2012 08:12 , "Magnus Westerlund" wrote: >WG, > >I spent a little time reviewing what dependencies we have in our current >set of WG drafts on I-Ds in other WGs. The below is the result of that >analysis. I can't promise that all listed are actually still relevant >normative references, they can equally be left overs. I for example >found two reference issues in my own WG document on the RTP usage. But I >think it gives us good indication that the WG memebers needs to be >active and contribute to work in at least MMUSIC, AVTCORE and TSVWG to >enable our WG to finish its work. > >There are more WGs where things goes on that are relevant, like the OPUS >payload format in the PAYLOAD WG. draft-spittka-payload-rtp-opus-01 >which wasn't referenced by either the audio-codec doc or the RTP usage >one. > >Please review and comment on these documents so they make progress. > >MMUSIC >draft-ietf-mmusic-sctp-sdp-02 >draft-ietf-mmusic-traffic-class-for-sdp-02 >draft-ietf-mmusic-sdp-bundle-negotiation-01 >draft-alvestrand-mmusic-msid-01 >draft-rescorla-mmusic-ice-trickle-00 > > >AVTCORE >draft-ietf-avtcore-rtp-circuit-breakers-00 >draft-ietf-avtcore-srtp-encrypted-header-ext-02 >draft-ietf-avtext-multiple-clock-rates-06 >draft-rescorla-avtcore-6222bis-00 >draft-terriberry-avp-codecs-00 >draft-ietf-avtcore-multi-media-rtp-session-01 > >Potentially some of these: >draft-lennox-avtcore-rtp-multi-stream-01 >draft-westerlund-avtcore-transport-multiplexing-04 >draft-westerlund-avtcore-rtp-topologies-update-01 >draft-westerlund-avtcore-multiplex-architecture-02 >draft-ietf-avt-srtp-ekt-03 > >TSVWG >draft-tuexen-tsvwg-sctp-dtls-encaps-01 >draft-ietf-tsvwg-sctp-udp-encaps-06 > >Behave >draft-muthu-behave-consent-freshness-01 > >Cheers > >Magnus Westerlund > >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb > From ted.ietf@gmail.com Mon Oct 29 11:08:19 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4AD421F84DD for ; Mon, 29 Oct 2012 11:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L540mb7RYhWf for ; Mon, 29 Oct 2012 11:08:19 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D924021F84CD for ; Mon, 29 Oct 2012 11:08:18 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so6080596vbb.31 for ; Mon, 29 Oct 2012 11:08:18 -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:cc:content-type; bh=rPZyVtC9eD9HQTONycS1RkwdPZM2j0l+Tpo7fYKO9vA=; b=PaeYIuDbPrF+IByfqfCEjs9sr9BJMdD5M0KxVvra+Vs2ftukIaZWt3RSqiZ4HZUOAn 0Na/xxVi5xTtlbu/a198Kehh4MuaEuDRq22GyxULjTDOJ4XaqOLNgxTo+jqCuT4X5HSx hyJ0t/qWOxT7BEmTIgaWuPsz2I+qVBup/A8qPP+nVoeOniOpXb+e9iV9D8UHLQFF8fhW jc5iHuggq2/Wd3XbQ3QMEdjffZ8H7ZVf5oCvg+3ScnZapyxqOYGn8UUBP8zjfD7sloFn ZNHgFaemIG2iftGvmp1el7QY0Qc/0pk5Cv5Cjp8sVNv8bWJ/PaFGEvdwkegxGx36+0ON 7NzA== MIME-Version: 1.0 Received: by 10.220.220.7 with SMTP id hw7mr9846139vcb.17.1351534098214; Mon, 29 Oct 2012 11:08:18 -0700 (PDT) Received: by 10.58.164.35 with HTTP; Mon, 29 Oct 2012 11:08:18 -0700 (PDT) Date: Mon, 29 Oct 2012 11:08:18 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Cullen Jennings Subject: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Oct 2012 18:08:19 -0000 We got feedback after the audio codec discussion that folks would have benefited from seeing the question we intended to ask before the meeting. In order to clarify that for this discussion, the chairs are putting forward this draft of the question which will be asked in the meeting (and then confirmed on the list). "1) If you support H.264 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now. 2) If you support VP8 as the mandatory to implement codec or are willing to live with it as the MTI, please raise your hand now. You may raise your hand more than once and we encourage you to do so if you can live with either, even if you have a preference for one over the other." Because all 3 chairs and our responsible AD could be perceived to have conflicts of interest here, we have asked Robert Sparks to judge the consensus of the room, and he has kindly agreed. If you have major heartburn about the form of the question, please let us know. regards, Ted Hardie, Cullen Jennings, Magnus Westerlund From stewe@stewe.org Mon Oct 29 11:51:53 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A68921F8734 for ; Mon, 29 Oct 2012 11:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYFGQcuLDlFQ for ; Mon, 29 Oct 2012 11:51:52 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 2C22F21F8733 for ; Mon, 29 Oct 2012 11:51:49 -0700 (PDT) Received: from mail81-am1-R.bigfish.com (10.3.201.231) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Mon, 29 Oct 2012 18:51:48 +0000 Received: from mail81-am1 (localhost [127.0.0.1]) by mail81-am1-R.bigfish.com (Postfix) with ESMTP id B229C3201D3; Mon, 29 Oct 2012 18:51:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.133; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0710HT004.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: PS-19(zz98dI1432Izz1202h1d1ah1d2ah1082kzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received-SPF: pass (mail81-am1: domain of stewe.org designates 157.56.236.133 as permitted sender) client-ip=157.56.236.133; envelope-from=stewe@stewe.org; helo=BY2PRD0710HT004.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail81-am1 (localhost.localdomain [127.0.0.1]) by mail81-am1 (MessageSwitch) id 135153670770807_7322; Mon, 29 Oct 2012 18:51:47 +0000 (UTC) Received: from AM1EHSMHS013.bigfish.com (unknown [10.3.201.254]) by mail81-am1.bigfish.com (Postfix) with ESMTP id 0586CA0049; Mon, 29 Oct 2012 18:51:47 +0000 (UTC) Received: from BY2PRD0710HT004.namprd07.prod.outlook.com (157.56.236.133) by AM1EHSMHS013.bigfish.com (10.3.207.151) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 29 Oct 2012 18:51:46 +0000 Received: from BY2PRD0710MB354.namprd07.prod.outlook.com ([169.254.11.195]) by BY2PRD0710HT004.namprd07.prod.outlook.com ([10.255.86.39]) with mapi id 14.16.0233.002; Mon, 29 Oct 2012 18:51:43 +0000 From: Stephan Wenger To: Ted Hardie , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Form of the video codec question Thread-Index: AQHNtgBnhFefoY+uxEeuadvRogjlhpfRJvUA Date: Mon, 29 Oct 2012 18:51:42 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.86.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <62744A84CC569F449C9A79C24A8F30BB@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: Cullen Jennings Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Oct 2012 18:51:53 -0000 Hi Ted, chairs, I think these are the wrong questions, as the result of such a poll is not going to solve anything. It's trivial to predict that there will be a significant show of hands in favor of each question. What does that tell you? Asking the questions as presented is going to be a waste of time. The more informative questions to as would be: 1) Do you object to H.264 as MTI, regardless of its technical and IPR merits (if any); and 2) Do you object to VP8 as MTI, regardless of its technical and IPR merits (if any) (both in more politically correct formulation, if you want.) If you chairs know that there are objections to both codecs by a significant number of people that cannot be swayed by technical or IPR arguments, a presentation of such technical and IPR merits can be omitted, and the WG can focus on stuff where progress is likely. Regards, Stephan On 10.29.2012 11:08 , "Ted Hardie" wrote: >We got feedback after the audio codec discussion that folks would have >benefited from seeing the question we intended to ask before the >meeting. In order to clarify that for this discussion, the chairs are >putting forward this draft of the question which will be asked in the >meeting (and then confirmed on the list). > >"1) If you support H.264 as the mandatory to implement codec or are >willing to live with it as the MTI, please raise your hand now. > >2) If you support VP8 as the mandatory to implement codec or are >willing to live with it as the MTI, please raise your hand now. > >You may raise your hand more than once and we encourage you to do so >if you can live with either, even if you have a preference for one >over the other." > >Because all 3 chairs and our responsible AD could be perceived to have >conflicts of interest here, we have asked Robert Sparks to judge the >consensus of the room, and he has kindly agreed. If you have major >heartburn about the form of the question, please let us know. > >regards, > >Ted Hardie, Cullen Jennings, Magnus Westerlund >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb > From ted.ietf@gmail.com Mon Oct 29 13:17:28 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DDF21F86C3 for ; Mon, 29 Oct 2012 13:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVGxomlk0Yoz for ; Mon, 29 Oct 2012 13:17:27 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE8721F86BE for ; Mon, 29 Oct 2012 13:17:27 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so6145814vcb.31 for ; Mon, 29 Oct 2012 13:17:26 -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=2Ow9yDhyg6TjumeB95819mO5VD8FCdRSAx0XSNSoO5Y=; b=oSZ1EcFKyzAoMtmbmUnt7diRnJfcSCNdGUZWXoCop1rGJxKOOtc0LRHSKjnv72P0O1 ZSom67Ck0S1+bE5mEviEG/qDS6AP8a094Wd5KqyJLiM62kjLBIJcc6cUneOaFhqII4Xs YKI2QXZECSdsumgvFd7OrjCz556BEfJglXw5lxYbQnEW7PGl2QL73Bua1o+tfKVFF+dl xWP+nycxl3C65h4ComFAUWN8aMqMsvz79hKx8DzlFndtvypzMCrCoBzsNF8CV6IycGw5 QCJS9OntNayo593kaTe6ahpMpI2l7nqg1bhXtIeRpwJ3r0lln7o0qI5O4J61c9gP8VfK 0QOg== MIME-Version: 1.0 Received: by 10.58.64.196 with SMTP id q4mr55292825ves.3.1351541846371; Mon, 29 Oct 2012 13:17:26 -0700 (PDT) Received: by 10.58.164.35 with HTTP; Mon, 29 Oct 2012 13:17:26 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Oct 2012 13:17:26 -0700 Message-ID: From: Ted Hardie To: Stephan Wenger Content-Type: text/plain; charset=ISO-8859-1 Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Oct 2012 20:17:28 -0000 Hi Stephan, On Mon, Oct 29, 2012 at 11:51 AM, Stephan Wenger wrote: > Hi Ted, chairs, > > I think these are the wrong questions, as the result of such a poll is not > going to solve anything. It's trivial to predict that there will be a > significant show of hands in favor of each question. What does that tell > you? It tells us whether there is rough consensus or not. Asking the questions as presented is going to be a waste of time. > > The more informative questions to as would be: > > 1) Do you object to H.264 as MTI, regardless of its technical and IPR > merits (if any); and > 2) Do you object to VP8 as MTI, regardless of its technical and IPR merits > (if any) > (both in more politically correct formulation, if you want.) > So, this seems to be the inverse ("Can you not live with X as MTI"). Why is asking this as the inverse going to give more information? We understand, of course, that the group has folks with strong opinions. They are vocal enough that no one is confused on this point. But we hope to understand, after a set of technical presentations, whether there is a sufficiently large group with a willingness to live with one or the other to create a rough consensus. regards, Ted Hardie > If you chairs know that there are objections to both codecs by a > significant number of people that cannot be swayed by technical or IPR > arguments, a presentation of such technical and IPR merits can be omitted, > and the WG can focus on stuff where progress is likely. > > Regards, > Stephan > > > On 10.29.2012 11:08 , "Ted Hardie" wrote: > >>We got feedback after the audio codec discussion that folks would have >>benefited from seeing the question we intended to ask before the >>meeting. In order to clarify that for this discussion, the chairs are >>putting forward this draft of the question which will be asked in the >>meeting (and then confirmed on the list). >> >>"1) If you support H.264 as the mandatory to implement codec or are >>willing to live with it as the MTI, please raise your hand now. >> >>2) If you support VP8 as the mandatory to implement codec or are >>willing to live with it as the MTI, please raise your hand now. >> >>You may raise your hand more than once and we encourage you to do so >>if you can live with either, even if you have a preference for one >>over the other." >> >>Because all 3 chairs and our responsible AD could be perceived to have >>conflicts of interest here, we have asked Robert Sparks to judge the >>consensus of the room, and he has kindly agreed. If you have major >>heartburn about the form of the question, please let us know. >> >>regards, >> >>Ted Hardie, Cullen Jennings, Magnus Westerlund >>_______________________________________________ >>rtcweb mailing list >>rtcweb@ietf.org >>https://www.ietf.org/mailman/listinfo/rtcweb >> > > From john@jlc.net Mon Oct 29 14:04:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5A421F8702 for ; Mon, 29 Oct 2012 14:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1P1wvANn2BBi for ; Mon, 29 Oct 2012 14:04:44 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDE421F86F0 for ; Mon, 29 Oct 2012 14:04:44 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id F401733C4F; Mon, 29 Oct 2012 17:04:43 -0400 (EDT) Date: Mon, 29 Oct 2012 17:04:43 -0400 From: John Leslie To: Ted Hardie Message-ID: <20121029210443.GB68232@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Oct 2012 21:04:44 -0000 Ted Hardie wrote: > > In order to clarify that for this discussion, the chairs are > putting forward this draft of the question which will be asked in the > meeting (and then confirmed on the list). > > "1) If you support H.264 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > 2) If you support VP8 as the mandatory to implement codec or are > willing to live with it as the MTI, please raise your hand now. > > You may raise your hand more than once and we encourage you to do so > if you can live with either, even if you have a preference for one > over the other." I find myself bothered (especially in a US election week) with the suggestion that there are only two possible outcomes. I view both being MTI as somewhat reasonable, and neither being MTI as a likely best-choice (assuming we don't get real consensus for either H.264 or VP8). I emphasize again that RTCWEB is designing for a long future, and that we're almost certain to find a better choice than either of these during that future. Thus I feel no obligation to choose the better technical choice as MTI. Clearly there are technical differences; and it's possible that a significant portion of the WG participants find a compelling argument among the technical issues. (It would be nice to learn whether that's true.) It's more obvious that there are IPR-related differences; and it seems there are folks that find compelling arguments among these. (It would be nice to learn whether clarifying any IPR issue would help.) If we in fact _do_ find near-consensus for one or the other, I'm happy to pursue consensus on the list -- but I'm led to doubt that will be the result of discussion during IETF-85. If we're not near consensus after the discussion, I'd _really_ like to have some direction to the WGCs of how to proceed. Simple-Majority-Vote is _not_ appropriate. Flipping a coin is not appropriate. I'm not fool enough to think my "something-like-H.261" suggestion is popular. But it _is_ a plausible way forward... > Because all 3 chairs and our responsible AD could be perceived to have > conflicts of interest here, we have asked Robert Sparks to judge the > consensus of the room, and he has kindly agreed. Clearly Robert should be empowered to ask follow-up questions if appropriate. I won't ask him to pre-determine what these might be, but I do hope he'll explore what might be an acceptable way forward. -- John Leslie From matthew.kaufman@skype.net Mon Oct 29 14:21:11 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8726721F8702 for ; Mon, 29 Oct 2012 14:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYr1OYeTyOlf for ; Mon, 29 Oct 2012 14:21:11 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.25]) by ietfa.amsl.com (Postfix) with ESMTP id A8FEE21F85EE for ; Mon, 29 Oct 2012 14:21:10 -0700 (PDT) Received: from BY2FFO11FD007.protection.gbl (10.1.15.203) by BY2FFO11HUB019.protection.gbl (10.1.14.178) with Microsoft SMTP Server (TLS) id 15.0.545.8; Mon, 29 Oct 2012 21:21:07 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD007.mail.protection.outlook.com (10.1.14.128) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Mon, 29 Oct 2012 21:21:07 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.52]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Mon, 29 Oct 2012 21:20:40 +0000 From: Matthew Kaufman To: Stephan Wenger , Ted Hardie , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Form of the video codec question Thread-Index: AQHNtgBjxnCRTWxEdEm8PEWsc927e5fQoN4AgAApCYA= Date: Mon, 29 Oct 2012 21:20:39 +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: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(13464001)(51704002)(31966008)(2666001)(4396001)(3846001)(20776001)(51856001)(50466001)(4196001)(1076001)(47776002)(46102001)(50986001)(8716001)(74502001)(53806001)(16696001)(49866001)(47446002)(47736001)(54356001)(54316001)(47976001)(44976002)(16406001)(48376001)(5343655001)(16826001)(74662001)(33656001)(3556001)(3746001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 064903DDDC Cc: Cullen Jennings Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Oct 2012 21:21:11 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Stephan Wenger > Sent: Monday, October 29, 2012 7:52 PM > To: Ted Hardie; rtcweb@ietf.org > Cc: Cullen Jennings > Subject: Re: [rtcweb] Form of the video codec question >=20 > Hi Ted, chairs, >=20 > I think these are the wrong questions, as the result of such a poll is no= t going > to solve anything. It's trivial to predict that there will be a signific= ant show of > hands in favor of each question. What does that tell you? Asking the > questions as presented is going to be a waste of time. >=20 > The more informative questions to as would be: >=20 > 1) Do you object to H.264 as MTI, regardless of its technical and IPR mer= its (if > any); and > 2) Do you object to VP8 as MTI, regardless of its technical and IPR merit= s (if > any) (both in more politically correct formulation, if you want.) > Agree. These are the questions I suggested originally. If the vast majority= of the people in the room raise their hands for *either one* of these, the= n we should spend the time on other topics instead. If one gets a significantly larger number than we can go on to whether or n= ot we might actually get consensus. Matthew Kaufman From matthew.kaufman@skype.net Mon Oct 29 14:23:57 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24DE21F86E5 for ; Mon, 29 Oct 2012 14:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SaPdsD0ygkp for ; Mon, 29 Oct 2012 14:23:56 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.23]) by ietfa.amsl.com (Postfix) with ESMTP id F1C4621F86EB for ; Mon, 29 Oct 2012 14:23:55 -0700 (PDT) Received: from BY2FFO11FD015.protection.gbl (10.1.15.201) by BY2FFO11HUB019.protection.gbl (10.1.14.178) with Microsoft SMTP Server (TLS) id 15.0.545.8; Mon, 29 Oct 2012 21:23:52 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD015.mail.protection.outlook.com (10.1.14.131) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Mon, 29 Oct 2012 21:23:52 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.52]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Mon, 29 Oct 2012 21:23:26 +0000 From: Matthew Kaufman To: Ted Hardie , Stephan Wenger Thread-Topic: [rtcweb] Form of the video codec question Thread-Index: AQHNtgBjxnCRTWxEdEm8PEWsc927e5fQoN4AgAAX9ACAABG+oA== Date: Mon, 29 Oct 2012 21:23:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464001)(51704002)(31966008)(2666001)(4396001)(3846001)(20776001)(51856001)(50466001)(4196001)(1076001)(47776002)(46102001)(50986001)(8716001)(74502001)(53806001)(16696001)(49866001)(47446002)(47736001)(54356001)(54316001)(47976001)(44976002)(16406001)(48376001)(5343655001)(16826001)(74662001)(33656001)(3556001)(3746001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 064903DDDC Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Oct 2012 21:23:57 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Ted Hardie >=20 >=20 > So, this seems to be the inverse ("Can you not live with X as MTI"). > Why is asking this as the inverse going to give more information? It isn't exactly the inverse. CANNOT is not the opposite of WOULD. >=20 > We understand, of course, that the group has folks with strong opinions. > They are vocal enough that no one is confused on this point. But we hope= to > understand, after a set of technical presentations, whether there is a > sufficiently large group with a willingness to live with one or the other= to > create a rough consensus. I hope to avoid the set of technical presentations altogether if spending t= ime on them is unlikely to change anyone's mind. Matthew Kaufman From ted.ietf@gmail.com Mon Oct 29 14:33:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F4521F86EE for ; Mon, 29 Oct 2012 14:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNPgh3VD6OnZ for ; Mon, 29 Oct 2012 14:33:56 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3879B21F86E7 for ; Mon, 29 Oct 2012 14:33:56 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so6219401vcb.31 for ; Mon, 29 Oct 2012 14:33: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=8SbAjtwdi1oLXWbJlF6l5MdbmjKfHpHEEOTpqgTmyA8=; b=XbwPWCSQ1/7oUkKWbt6rDZOaGd322sf/F7pMipMLBDwoiNqnwjlNEx+y4Q4isWhuf9 uvOGj08bdotkZchmIcyHaB4f0r9Nvugaod6KGsrhIVGcpAwl3ATqGX5Or31tK+ptanLp VGGZ3+ZmES7FMMfWOQHDjZJdqiiAyeKvU1FW4Vlp7Oo9F0D5aJTfFz5aBBoWOhD9wIFx d2zSJRlLZRBzas9s7EQgvQy6rFEx5SNxiPbDOiv69DlHB8yrRpgFsISuD8d2xfvbwtGv 2HDhOLRj73N1L2XtXw15cP4+LGVt8EhBzO39eVWr9Cepw0LXNRW3YR+kfnY+FxPgjXfK 2Nlw== MIME-Version: 1.0 Received: by 10.52.179.231 with SMTP id dj7mr40255989vdc.108.1351546435749; Mon, 29 Oct 2012 14:33:55 -0700 (PDT) Received: by 10.58.164.35 with HTTP; Mon, 29 Oct 2012 14:33:55 -0700 (PDT) In-Reply-To: <20121029210443.GB68232@verdi> References: <20121029210443.GB68232@verdi> Date: Mon, 29 Oct 2012 14:33:55 -0700 Message-ID: From: Ted Hardie To: John Leslie Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Oct 2012 21:33:56 -0000 On Mon, Oct 29, 2012 at 2:04 PM, John Leslie > I find myself bothered (especially in a US election week) with the > suggestion that there are only two possible outcomes. > These are the only two proposals for which we have drafts, which was noted before as a step along the path for this decision. We have previously established a consensus to have a mandatory-to-implement in order to avoid negotiation failure. > I view both being MTI as somewhat reasonable, and neither being MTI > as a likely best-choice (assuming we don't get real consensus for > either H.264 or VP8). > > I emphasize again that RTCWEB is designing for a long future, and > that we're almost certain to find a better choice than either of these > during that future. Thus I feel no obligation to choose the better > technical choice as MTI. > Clearly there are technical differences; and it's possible that a > significant portion of the WG participants find a compelling argument > among the technical issues. (It would be nice to learn whether that's > true.) > > It's more obvious that there are IPR-related differences; and it > seems there are folks that find compelling arguments among these. > (It would be nice to learn whether clarifying any IPR issue would > help.) > > If we in fact _do_ find near-consensus for one or the other, I'm > happy to pursue consensus on the list -- but I'm led to doubt that > will be the result of discussion during IETF-85. If we're not near > consensus after the discussion, I'd _really_ like to have some > direction to the WGCs of how to proceed. Simple-Majority-Vote is > _not_ appropriate. Flipping a coin is not appropriate. > We will discuss next steps after the result, whatever the result may be. Unless there is a long mic line advocating flipping a coin, I do not see it as a likely next step. > I'm not fool enough to think my "something-like-H.261" suggestion > is popular. But it _is_ a plausible way forward... > >> Because all 3 chairs and our responsible AD could be perceived to have >> conflicts of interest here, we have asked Robert Sparks to judge the >> consensus of the room, and he has kindly agreed. > > Clearly Robert should be empowered to ask follow-up questions if > appropriate. I won't ask him to pre-determine what these might be, > but I do hope he'll explore what might be an acceptable way forward. > Follow-up questions are, of course, a possibility, and we will obviously confirm anything on the list. regards, Ted Hardie > -- > John Leslie From sergio.garcia.murillo@gmail.com Mon Oct 29 15:40:19 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC1F21F8647 for ; Mon, 29 Oct 2012 15:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdeUhfmXee9S for ; Mon, 29 Oct 2012 15:40:19 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id CA64121F8645 for ; Mon, 29 Oct 2012 15:40:18 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so2198101wib.13 for ; Mon, 29 Oct 2012 15:40:16 -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=HHFTP6Rd9/ySBcEm2gzHvgXrptGEuHr2Wp86k27MJZM=; b=dcwgYSrYEUtdmS58zGyZMtXNROIcXdqQjP5/yfkdQu28lh8rHa4fRn+SrEFoN3U47b dZBINd2xWjCRmCoIkhrik1BzXflwhKCrlqOyFDy0DEomgBZp0NwOaP4IrKJA2rwIqXyi ju+ynM4KHK7VlpC4gXxg5MYkvxmtLmYAo7qgoaqPAgDj+xaq+jBd5ZR9pbQKzBWjBXAr 92DwWuFJ7zz6Oe4SIaglxjBFAAA8xMHWY/P7zR850nxZ87j3Hh3pmV1lrrWejSIr6N4F OKm3WxgMF7uBW7pWuwfJI6fxzrgHDkNl1KQjbpmxQFTI7AmiUccXswbq2lEysH3LlugN nO3A== Received: by 10.216.141.16 with SMTP id f16mr18255338wej.130.1351550416713; Mon, 29 Oct 2012 15:40:16 -0700 (PDT) Received: from [192.168.1.10] (242.pool62-36-35.dynamic.orange.es. [62.36.35.242]) by mx.google.com with ESMTPS id j8sm11674396wiy.9.2012.10.29.15.40.15 (version=SSLv3 cipher=OTHER); Mon, 29 Oct 2012 15:40:16 -0700 (PDT) Message-ID: <508F05CF.9080906@gmail.com> Date: Mon, 29 Oct 2012 23:40:15 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 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: 8bit Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Oct 2012 22:40:20 -0000 Hi Ted, Maybe I am completely wrong, but my understanding about the current situation is that there are two groups of people: Group A: H264 folks, that want to have H264 as MTI (mainly for compatibility with current deployed base) but won't oppose to have VP8 MTI in addition. Group B: VP8 folks, that want to have VP8 as MTI but will oppose H264 to be also MTI. So in the first sets of questions, A would raise the hands for both 1 and 2, and B only for 2, which would be considered as a consensus to go for VP8. In the second set of questions, A would not raise hands in neither 1 nor 2, and B would only rise hands for 1, which would be considered as a consensus to go for VP8. So at the end, both sets of question seems biased toward VP8 supporters. Best regards Sergio El 29/10/2012 19:51, Stephan Wenger escribi: > Hi Ted, chairs, > > I think these are the wrong questions, as the result of such a poll is not > going to solve anything. It's trivial to predict that there will be a > significant show of hands in favor of each question. What does that tell > you? Asking the questions as presented is going to be a waste of time. > > The more informative questions to as would be: > > 1) Do you object to H.264 as MTI, regardless of its technical and IPR > merits (if any); and > 2) Do you object to VP8 as MTI, regardless of its technical and IPR merits > (if any) > (both in more politically correct formulation, if you want.) > > If you chairs know that there are objections to both codecs by a > significant number of people that cannot be swayed by technical or IPR > arguments, a presentation of such technical and IPR merits can be omitted, > and the WG can focus on stuff where progress is likely. > > Regards, > Stephan > > > On 10.29.2012 11:08 , "Ted Hardie" wrote: > >> We got feedback after the audio codec discussion that folks would have >> benefited from seeing the question we intended to ask before the >> meeting. In order to clarify that for this discussion, the chairs are >> putting forward this draft of the question which will be asked in the >> meeting (and then confirmed on the list). >> >> "1) If you support H.264 as the mandatory to implement codec or are >> willing to live with it as the MTI, please raise your hand now. >> >> 2) If you support VP8 as the mandatory to implement codec or are >> willing to live with it as the MTI, please raise your hand now. >> >> You may raise your hand more than once and we encourage you to do so >> if you can live with either, even if you have a preference for one >> over the other." >> >> Because all 3 chairs and our responsible AD could be perceived to have >> conflicts of interest here, we have asked Robert Sparks to judge the >> consensus of the room, and he has kindly agreed. If you have major >> heartburn about the form of the question, please let us know. >> >> regards, >> >> Ted Hardie, Cullen Jennings, Magnus Westerlund >> _______________________________________________ >> 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 hangzhou.chenxin@huawei.com Mon Oct 29 21:14:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1151721F85A7 for ; Mon, 29 Oct 2012 21:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8y-RqfjbOplt for ; Mon, 29 Oct 2012 21:14:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6A621F853B for ; Mon, 29 Oct 2012 21:14:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALA97931; Tue, 30 Oct 2012 04:14:39 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 30 Oct 2012 04:14:14 +0000 Received: from SZXEML438-HUB.china.huawei.com (10.72.61.73) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 30 Oct 2012 04:14:37 +0000 Received: from SZXEML538-MBX.china.huawei.com ([169.254.4.17]) by szxeml438-hub.china.huawei.com ([10.72.61.73]) with mapi id 14.01.0323.003; Tue, 30 Oct 2012 12:14:31 +0800 From: Chenxin To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Form of the video codec question Thread-Index: AQHNtgBnin59gRDhPkaB5BDgzltnkpfQGsEAgAA/3ICAAOIKUA== Date: Tue, 30 Oct 2012 04:14:30 +0000 Message-ID: <9E34D50A21D1D1489134B4D770CE0397367E77C0@szxeml538-mbx.china.huawei.com> References: <508F05CF.9080906@gmail.com> In-Reply-To: <508F05CF.9080906@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.41.110] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Oct 2012 04:14:42 -0000 +1=20 option 3 should be added to the choice : support both H.264 and VP8 as the = mandatory to implement codec. Best Regards, Xin=20 >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf O= f >Sergio Garcia Murillo >Sent: Tuesday, October 30, 2012 6:40 AM >To: rtcweb@ietf.org >Subject: Re: [rtcweb] Form of the video codec question > >Hi Ted, > >Maybe I am completely wrong, but my understanding about the current >situation is that there are two groups of people: > >Group A: H264 folks, that want to have H264 as MTI (mainly for >compatibility with current deployed base) but won't oppose to have VP8 >MTI in addition. >Group B: VP8 folks, that want to have VP8 as MTI but will oppose H264 to >be also MTI. > >So in the first sets of questions, A would raise the hands for both 1 >and 2, and B only for 2, which would be considered as a consensus to go >for VP8. > >In the second set of questions, A would not raise hands in neither 1 nor >2, and B would only rise hands for 1, which would be considered as a >consensus to go for VP8. > >So at the end, both sets of question seems biased toward VP8 supporters. > >Best regards >Sergio > >El 29/10/2012 19:51, Stephan Wenger escribi=F3: >> Hi Ted, chairs, >> >> I think these are the wrong questions, as the result of such a poll is n= ot >> going to solve anything. It's trivial to predict that there will be a >> significant show of hands in favor of each question. What does that tel= l >> you? Asking the questions as presented is going to be a waste of time. >> >> The more informative questions to as would be: >> >> 1) Do you object to H.264 as MTI, regardless of its technical and IPR >> merits (if any); and >> 2) Do you object to VP8 as MTI, regardless of its technical and IPR meri= ts >> (if any) >> (both in more politically correct formulation, if you want.) >> >> If you chairs know that there are objections to both codecs by a >> significant number of people that cannot be swayed by technical or IPR >> arguments, a presentation of such technical and IPR merits can be omitte= d, >> and the WG can focus on stuff where progress is likely. >> >> Regards, >> Stephan >> >> >> On 10.29.2012 11:08 , "Ted Hardie" wrote: >> >>> We got feedback after the audio codec discussion that folks would have >>> benefited from seeing the question we intended to ask before the >>> meeting. In order to clarify that for this discussion, the chairs are >>> putting forward this draft of the question which will be asked in the >>> meeting (and then confirmed on the list). >>> >>> "1) If you support H.264 as the mandatory to implement codec or are >>> willing to live with it as the MTI, please raise your hand now. >>> >>> 2) If you support VP8 as the mandatory to implement codec or are >>> willing to live with it as the MTI, please raise your hand now. >>> >>> You may raise your hand more than once and we encourage you to do so >>> if you can live with either, even if you have a preference for one >>> over the other." >>> >>> Because all 3 chairs and our responsible AD could be perceived to have >>> conflicts of interest here, we have asked Robert Sparks to judge the >>> consensus of the room, and he has kindly agreed. If you have major >>> heartburn about the form of the question, please let us know. >>> >>> regards, >>> >>> Ted Hardie, Cullen Jennings, Magnus Westerlund >>> _______________________________________________ >>> 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 Markus.Isomaki@nokia.com Tue Oct 30 03:12:49 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965F121F843C for ; Tue, 30 Oct 2012 03:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0QK9X0iVkyH for ; Tue, 30 Oct 2012 03:12:49 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 343F521F842B for ; Tue, 30 Oct 2012 03:12:47 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q9UACjm8008146; Tue, 30 Oct 2012 12:12:45 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Oct 2012 12:12:45 +0200 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.221]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.02.0309.003; Tue, 30 Oct 2012 11:12:44 +0100 From: To: , Thread-Topic: [rtcweb] Form of the video codec question Thread-Index: AQHNtgBtbZy4pFD9XE+/lsp6cw4np5fQkBoAgAA/24CAANEo4A== Date: Tue, 30 Oct 2012 10:12:42 +0000 Message-ID: References: <508F05CF.9080906@gmail.com> In-Reply-To: <508F05CF.9080906@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.217.168.220] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Oct 2012 10:12:45.0177 (UTC) FILETIME=[1AE68E90:01CDB687] X-Nokia-AV: Clean Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Oct 2012 10:12:49 -0000 Hi, Sergio Garcia Murillo wrote: > >Hi Ted, > >Maybe I am completely wrong, but my understanding about the current >situation is that there are two groups of people: > >Group A: H264 folks, that want to have H264 as MTI (mainly for compatibili= ty >with current deployed base) but won't oppose to have VP8 MTI in addition. >Group B: VP8 folks, that want to have VP8 as MTI but will oppose H264 to b= e >also MTI. > I know that there are definitely people also in: Group C: H264 folks that want to have H264 as MTI and will oppose VP8 as MT= I. Otherwise the issue would be much easier. Markus From Markus.Isomaki@nokia.com Tue Oct 30 03:42:48 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5962D21F8473 for ; Tue, 30 Oct 2012 03:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeT4Uk6fiHBK for ; Tue, 30 Oct 2012 03:42:47 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 983B921F845A for ; Tue, 30 Oct 2012 03:42:46 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q9UAgPUx020288; Tue, 30 Oct 2012 12:42:35 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.49]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Oct 2012 12:42:31 +0200 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.221]) by 008-AM1MMR2-015.mgdnok.nokia.com ([65.54.30.49]) with mapi id 14.02.0309.003; Tue, 30 Oct 2012 11:42:30 +0100 From: To: , , Thread-Topic: [rtcweb] Form of the video codec question Thread-Index: AQHNtgBtbZy4pFD9XE+/lsp6cw4np5fQkBoAgAETAAA= Date: Tue, 30 Oct 2012 10:42:30 +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: [91.217.168.220] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Oct 2012 10:42:31.0455 (UTC) FILETIME=[439AF2F0:01CDB68B] X-Nokia-AV: Clean Cc: fluffy@cisco.com Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Oct 2012 10:42:48 -0000 Hi, I prefer Stephan's formulation of the questions. To me the main issue does = not seem to be the amount of people favoring a particular codec but objecti= ng one. In case both H.264 and VP8 will get a large number of objections, a= s I suspect, I think it is worhwhile also to ask once more something like: * Raise your hand if you think the WG must decide on at least one MTI video= codec (at this time) * Raise your hand if you think the WG should give up on MTI video codec (fo= r now) and focus on making progress in other areas =20 Markus=20 >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of ext Stephan Wenger >Sent: 29 October, 2012 20:52 >To: Ted Hardie; rtcweb@ietf.org >Cc: Cullen Jennings >Subject: Re: [rtcweb] Form of the video codec question > >Hi Ted, chairs, > >I think these are the wrong questions, as the result of such a poll is not= going >to solve anything. It's trivial to predict that there will be a significa= nt show of >hands in favor of each question. What does that tell you? Asking the >questions as presented is going to be a waste of time. > >The more informative questions to as would be: > >1) Do you object to H.264 as MTI, regardless of its technical and IPR meri= ts (if >any); and >2) Do you object to VP8 as MTI, regardless of its technical and IPR merits= (if >any) (both in more politically correct formulation, if you want.) > >If you chairs know that there are objections to both codecs by a significa= nt >number of people that cannot be swayed by technical or IPR arguments, a >presentation of such technical and IPR merits can be omitted, and the WG c= an >focus on stuff where progress is likely. > >Regards, >Stephan > > >On 10.29.2012 11:08 , "Ted Hardie" wrote: > >>We got feedback after the audio codec discussion that folks would have >>benefited from seeing the question we intended to ask before the >>meeting. In order to clarify that for this discussion, the chairs are >>putting forward this draft of the question which will be asked in the >>meeting (and then confirmed on the list). >> >>"1) If you support H.264 as the mandatory to implement codec or are >>willing to live with it as the MTI, please raise your hand now. >> >>2) If you support VP8 as the mandatory to implement codec or are >>willing to live with it as the MTI, please raise your hand now. >> >>You may raise your hand more than once and we encourage you to do so if >>you can live with either, even if you have a preference for one over >>the other." >> >>Because all 3 chairs and our responsible AD could be perceived to have >>conflicts of interest here, we have asked Robert Sparks to judge the >>consensus of the room, and he has kindly agreed. If you have major >>heartburn about the form of the question, please let us know. >> >>regards, >> >>Ted Hardie, Cullen Jennings, Magnus Westerlund >>_______________________________________________ >>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 fluffy@iii.ca Tue Oct 30 03:52:37 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405EB21F846A for ; Tue, 30 Oct 2012 03:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mdvBSiFC-wA for ; Tue, 30 Oct 2012 03:52:36 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDBF21F843E for ; Tue, 30 Oct 2012 03:52:36 -0700 (PDT) Received: from [172.19.1.223] (unknown [91.217.168.220]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5AFDA22E259; Tue, 30 Oct 2012 06:52:29 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Cullen Jennings In-Reply-To: Date: Tue, 30 Oct 2012 11:54:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <75DADF49-7E1D-4DE0-AF81-D44159C14E12@iii.ca> References: To: X-Mailer: Apple Mail (2.1499) Cc: fluffy@cisco.com, rtcweb@ietf.org Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Oct 2012 10:52:37 -0000 So lets say we got agreement on something qualified with "regardless of = its technical and IPR merits (if any)", I can't see how that helps us. = We need to get agreement without that sort of qualification.=20 Can folks walk me through how this questions is better? On Oct 30, 2012, at 11:42 , wrote: > Hi, >=20 > I prefer Stephan's formulation of the questions. To me the main issue = does not seem to be the amount of people favoring a particular codec but = objecting one. In case both H.264 and VP8 will get a large number of = objections, as I suspect, I think it is worhwhile also to ask once more = something like: >=20 > * Raise your hand if you think the WG must decide on at least one MTI = video codec (at this time) > * Raise your hand if you think the WG should give up on MTI video = codec (for now) and focus on making progress in other areas =20 >=20 > Markus=20 >=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf >> Of ext Stephan Wenger >> Sent: 29 October, 2012 20:52 >> To: Ted Hardie; rtcweb@ietf.org >> Cc: Cullen Jennings >> Subject: Re: [rtcweb] Form of the video codec question >>=20 >> Hi Ted, chairs, >>=20 >> I think these are the wrong questions, as the result of such a poll = is not going >> to solve anything. It's trivial to predict that there will be a = significant show of >> hands in favor of each question. What does that tell you? Asking = the >> questions as presented is going to be a waste of time. >>=20 >> The more informative questions to as would be: >>=20 >> 1) Do you object to H.264 as MTI, regardless of its technical and IPR = merits (if >> any); and >> 2) Do you object to VP8 as MTI, regardless of its technical and IPR = merits (if >> any) (both in more politically correct formulation, if you want.) >>=20 >> If you chairs know that there are objections to both codecs by a = significant >> number of people that cannot be swayed by technical or IPR arguments, = a >> presentation of such technical and IPR merits can be omitted, and the = WG can >> focus on stuff where progress is likely. >>=20 >> Regards, >> Stephan >>=20 >>=20 >> On 10.29.2012 11:08 , "Ted Hardie" wrote: >>=20 >>> We got feedback after the audio codec discussion that folks would = have >>> benefited from seeing the question we intended to ask before the >>> meeting. In order to clarify that for this discussion, the chairs = are >>> putting forward this draft of the question which will be asked in = the >>> meeting (and then confirmed on the list). >>>=20 >>> "1) If you support H.264 as the mandatory to implement codec or are >>> willing to live with it as the MTI, please raise your hand now. >>>=20 >>> 2) If you support VP8 as the mandatory to implement codec or are >>> willing to live with it as the MTI, please raise your hand now. >>>=20 >>> You may raise your hand more than once and we encourage you to do so = if >>> you can live with either, even if you have a preference for one over >>> the other." >>>=20 >>> Because all 3 chairs and our responsible AD could be perceived to = have >>> conflicts of interest here, we have asked Robert Sparks to judge the >>> consensus of the room, and he has kindly agreed. If you have major >>> heartburn about the form of the question, please let us know. >>>=20 >>> regards, >>>=20 >>> Ted Hardie, Cullen Jennings, Magnus Westerlund >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>=20 >>=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 matthew.kaufman@skype.net Tue Oct 30 05:31:07 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140CB21F8554 for ; Tue, 30 Oct 2012 05:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSVfN2Z9AtrJ for ; Tue, 30 Oct 2012 05:31:06 -0700 (PDT) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.24]) by ietfa.amsl.com (Postfix) with ESMTP id 25B6C21F852D for ; Tue, 30 Oct 2012 05:31:05 -0700 (PDT) Received: from BY2FFO11FD003.protection.gbl (10.1.15.203) by BY2FFO11HUB024.protection.gbl (10.1.14.138) with Microsoft SMTP Server (TLS) id 15.0.545.8; Tue, 30 Oct 2012 12:31:03 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD003.mail.protection.outlook.com (10.1.14.125) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Tue, 30 Oct 2012 12:31:03 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.52]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Tue, 30 Oct 2012 12:30:49 +0000 From: Matthew Kaufman To: Cullen Jennings , "Markus.Isomaki@nokia.com" Thread-Topic: [rtcweb] Form of the video codec question Thread-Index: AQHNtgBjxnCRTWxEdEm8PEWsc927e5fQoN4AgAEJpgCAAANbAIAAGgmA Date: Tue, 30 Oct 2012 12:30:48 +0000 Message-ID: References: <75DADF49-7E1D-4DE0-AF81-D44159C14E12@iii.ca> In-Reply-To: <75DADF49-7E1D-4DE0-AF81-D44159C14E12@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(20776001)(551984001)(74502001)(16696001)(46102001)(47976001)(54356001)(4196001)(47736001)(8716001)(1076001)(47446002)(44976002)(53806001)(50986001)(3846001)(50466001)(4396001)(2666001)(16826001)(48376001)(33656001)(54316001)(16406001)(47776002)(31966008)(51856001)(49866001)(74662001)(3746001)(3556001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0650714AAA Cc: "fluffy@cisco.com" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Oct 2012 12:31:07 -0000 Cullen Jennings: >=20 > So lets say we got agreement on something qualified with "regardless of i= ts > technical and IPR merits (if any)", I can't see how that helps us. We nee= d to > get agreement without that sort of qualification. >=20 > Can folks walk me through how this questions is better? > It doesn't hardly matter *why*... my point of a qualification was covered i= n my original questions: Raise your hand if you want only H.264 and no amount of presentation time w= ill change that to VP8 =09 Raise your hand if you want only VP8 and no amount of presentation time wil= l change that to H.264 If the sum of those hands is the majority, we have better ways to use our t= ime than presenting to people who won't change their mind. Matthew Kaufman =20 From ibc@aliax.net Tue Oct 30 06:02:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C4F21F8495 for ; Tue, 30 Oct 2012 06:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFuI658lifXl for ; Tue, 30 Oct 2012 06:02:52 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B949821F8476 for ; Tue, 30 Oct 2012 06:02:51 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so208227lam.31 for ; Tue, 30 Oct 2012 06:02:50 -0700 (PDT) X-Google-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:content-transfer-encoding:x-gm-message-state; bh=jfC6IszzMo/Zji+y6f8BWuaYt/G98kMb9wjZRGBj/nE=; b=TQRZAxwUtnJnycsHqgVUOH9jUX58I27uPb7Sba11wx7LwVssAhcIuUZQB01RNPIybq KewCi8Wn+jpJogJzUw8F/YRZqVHCGl5icRjBFI2MgYK9tXbYO+LHs15Ntn/f3/rFVwxz tMdiOfyMdikQ4rZt8fxqStAWSweUljgnliozFN7JtkboR8GixNSHgOiomPXj0Pv2TawR YA3Gy0yzi+SSp6Y9u+s+xH2N7zv1suDvs7Mobj6wFaIXTtl0Sw4woA03Q3qtQJvBOPdz UgVshyeAThbL10Tiq4V1HrhTfPHn9V80gzFH8jPSh70EXfjPD2HEhZIbCbHUTVZbkO/D OQoQ== Received: by 10.152.146.67 with SMTP id ta3mr30150355lab.23.1351602170526; Tue, 30 Oct 2012 06:02:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Tue, 30 Oct 2012 06:02:30 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B01E60F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B01E60F@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 30 Oct 2012 14:02:30 +0100 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk+dXeZK2GDE/Q5o2aUAJtULcV8K7GTsIRjb2I4KbpCLw64nZVTYpiRwhaIoKmY8IPg9uVp Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-02 Comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Oct 2012 13:02:55 -0000 2012/10/25 Christer Holmberg : > Some comments on JSEP-02. > > Q1: Cloning > > I saw that you have removed the text about cloning from version -02. So is it already decided that local PeerConnection cloning will not exist? --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Oct 30 06:06:55 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A049021F858E for ; Tue, 30 Oct 2012 06:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEMP0MwW8dkQ for ; Tue, 30 Oct 2012 06:06:55 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id BEBAE21F858B for ; Tue, 30 Oct 2012 06:06:54 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so231320lbo.31 for ; Tue, 30 Oct 2012 06:06:53 -0700 (PDT) X-Google-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 :content-type:content-transfer-encoding:x-gm-message-state; bh=b84IwJg2BjVliUSixdvqBMCsJHarhtWg3Fe5J3+fI7E=; b=Yc7QnCRBTpa+UONvwSzAaH9ugsnkRREZMNWOJtfSnKZdubWpvC7Zt8+Bhol/PT1h+q T+RRRx6D+MO4TW4xy6nqEeSsk5/7QSwRCrSKimrGATiyxLqnJOBHajjHyke4/TsLdarU C22oUFnz+6Pok52e/GvL02ccUqNaJbSdWi65ZCvg/vNz3QAZhgZVuiT6KeawHdZiUIH+ iY4k0qXcM3gDIoVIpi21jRvDetbuPBj0zz6ojAKRS7xJGbqHHQph0ZXEUQZG3/9hAQTr me7LTLMZwpFbxF+YT00AKiuZdAk1ir0G9EfSxcrqNo3SlbiKpUUfRWGB3mJw3Z4WVPp1 XpVw== Received: by 10.112.29.9 with SMTP id f9mr13413086lbh.22.1351602413708; Tue, 30 Oct 2012 06:06:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Tue, 30 Oct 2012 06:06:33 -0700 (PDT) In-Reply-To: <066.ee8d274029b0215df9ff464ea44b5fe7@trac.tools.ietf.org> References: <066.ee8d274029b0215df9ff464ea44b5fe7@trac.tools.ietf.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 30 Oct 2012 14:06:33 +0100 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlH1hMH/eGtqD8iYBPTYWR0qDeOPzPBLQpsty8auOYq922yLYnS/JnX1RFn3SRLS1Ptx2Rm Subject: Re: [rtcweb] #1: RFC 4734 citation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Oct 2012 13:06:55 -0000 2012/10/23 rtcweb issue tracker : > Telephone Event - [RFC4734] Could somebody give some points about why DTMFs over media are required in WWW? Isn't DTMF mechanism OLD enough to incorporate it into WebRTC? Autoanswer: interoperability with legacy telephony world. --=20 I=C3=B1aki Baz Castillo From fluffy@cisco.com Tue Oct 30 06:08:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B88521F8521 for ; Tue, 30 Oct 2012 06:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 051Mh36tdo8H for ; Tue, 30 Oct 2012 06:08:42 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7823C21F84DB for ; Tue, 30 Oct 2012 06:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=417; q=dns/txt; s=iport; t=1351602522; x=1352812122; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=F2FluWws5CxhaVH7c2AwhNnunZtIjFL8b7Oe7c+QsIg=; b=Y4mWxq6qJqokR/6Ou9/ui6JcJQ0jtuzwrV0DVXtg23DJtITi38zCsUi+ sjBnPz2U5eNqJTJX9FbJuFVH5Dx2XBJo8D70q7YunmmzpTJl12G2AaPFf RjLg7d11QffTPSH2qMp6Rd7HY67/lIPEJb2Vw1ZshQgu/ZJLwFjoQUiO0 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFABjRj1CtJV2d/2dsb2JhbABEhVG9ZIEIgh8BAQQSASc/EAIBCCIUEDIlAgQOBQgah2ScZI9nkDSLdYV8YQOkS4Frgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="136881255" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 30 Oct 2012 13:08:41 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9UD8fYR021062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Oct 2012 13:08:41 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.001; Tue, 30 Oct 2012 08:08:41 -0500 From: "Cullen Jennings (fluffy)" To: "Markus.Isomaki@nokia.com" Thread-Topic: [rtcweb] Form of the video codec question Thread-Index: AQHNtgBgustyiUGYLkmbajL4vzYFSpfQ9K8AgAEJpwCAAClpgA== Date: Tue, 30 Oct 2012 13:08:41 +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: [10.61.101.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19320.004 x-tm-as-result: No--29.494400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <481E76B3FB98B24F8A31096A7374A3B8@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Oct 2012 13:08:44 -0000 On Oct 30, 2012, at 11:42 , Markus.Isomaki@nokia.com wrote: >=20 > * Raise your hand if you think the WG must decide on at least one MTI vid= eo codec (at this time) > * Raise your hand if you think the WG should give up on MTI video codec (= for now) and focus on making progress in other areas =20 Agree this is critical but we took that previously and there was consensus = for a MTI video codec.=20 From matthew.kaufman@skype.net Tue Oct 30 06:20:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1AC21F850E for ; Tue, 30 Oct 2012 06:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.616 X-Spam-Level: X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[AWL=0.683, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvQnJk51DSJM for ; Tue, 30 Oct 2012 06:20:02 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2B29D21F8506 for ; Tue, 30 Oct 2012 06:20:01 -0700 (PDT) Received: from BY2FFO11FD005.protection.gbl (10.1.15.200) by BY2FFO11HUB022.protection.gbl (10.1.14.109) with Microsoft SMTP Server (TLS) id 15.0.545.8; Tue, 30 Oct 2012 13:19:53 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD005.mail.protection.outlook.com (10.1.14.126) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Tue, 30 Oct 2012 13:19:52 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.52]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Tue, 30 Oct 2012 13:19:30 +0000 From: Matthew Kaufman To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "rtcweb@ietf.org" Thread-Topic: [rtcweb] #1: RFC 4734 citation Thread-Index: AQHNtp90JEhPG6hSbEWr/n8AEbLdgpfR1KkA Date: Tue, 30 Oct 2012 13:19:29 +0000 Message-ID: References: <066.ee8d274029b0215df9ff464ea44b5fe7@trac.tools.ietf.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(54356001)(16406001)(16696001)(46102001)(50986001)(2666001)(51856001)(50466001)(8716001)(16826001)(47776002)(74662001)(54316001)(44976002)(4196001)(53806001)(33656001)(1076001)(3846001)(74502001)(31966008)(20776001)(47736001)(48376001)(5343655001)(49866001)(4396001)(47446002)(47976001)(17413002)(3746001)(3556001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0650714AAA Subject: Re: [rtcweb] #1: RFC 4734 citation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Oct 2012 13:20:03 -0000 PiBGcm9tOiBydGN3ZWItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGll dGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgScOxYWtpIEJheiBDYXN0aWxsbw0KPg0KPiBDb3VsZCBz b21lYm9keSBnaXZlIHNvbWUgcG9pbnRzIGFib3V0IHdoeSBEVE1GcyBvdmVyIG1lZGlhIGFyZQ0K PiByZXF1aXJlZCBpbiBXV1c/IElzbid0IERUTUYgbWVjaGFuaXNtIE9MRCBlbm91Z2ggdG8gaW5j b3Jwb3JhdGUgaXQgaW50bw0KPiBXZWJSVEM/DQo+IA0KPiBBdXRvYW5zd2VyOiBpbnRlcm9wZXJh YmlsaXR5IHdpdGggbGVnYWN5IHRlbGVwaG9ueSB3b3JsZC4NCg0KDQpUaGUgaXNzdWUgaXMgdGhh dCBiZWNhdXNlIHRoZSBEVE1GIGlzIG9uIHRoZSBSVFAgbWVkaWEgc3RyZWFtIChhbmQgbm90IHRo ZSBzaWduYWxpbmcgY2hhbm5lbCkgdGhlbiBmb3IgYW55IGludGVyd29ya2luZyB3aXRoIGxlZ2Fj eSB0ZWxlcGhvbnkgZXF1aXBtZW50LCByYWRpbyBzeXN0ZW1zLCBvciBvdGhlciB0aGluZ3MgdGhh dCB1c2UgRFRNRiBpdCBpcyBuZWNlc3NhcnkgZm9yIHRoZSBzZW5kaW5nIGJyb3dzZXIgdG8gZG8g dGhlIGluc2VydGlvbiBvZiBEVE1GLg0KDQpNYXR0aGV3IEthdWZtYW4NCg== From Markus.Isomaki@nokia.com Tue Oct 30 06:51:57 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B47121F8506 for ; Tue, 30 Oct 2012 06:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zkq1X-7YEiDM for ; Tue, 30 Oct 2012 06:51:55 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id E647421F84FB for ; Tue, 30 Oct 2012 06:51:54 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q9UDpmw9030496; Tue, 30 Oct 2012 15:51:49 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.47]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Oct 2012 15:51:48 +0200 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.221]) by 008-AM1MMR1-013.mgdnok.nokia.com ([2002:4136:1e2f::4136:1e2f]) with mapi id 14.02.0309.003; Tue, 30 Oct 2012 14:51:47 +0100 From: To: Thread-Topic: [rtcweb] Form of the video codec question Thread-Index: AQHNtgBtbZy4pFD9XE+/lsp6cw4np5fQkBoAgAETAACAAB9+gIAAFHTA Date: Tue, 30 Oct 2012 13:51:46 +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: [91.217.168.220] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Oct 2012 13:51:48.0069 (UTC) FILETIME=[B4ACB950:01CDB6A5] X-Nokia-AV: Clean Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Oct 2012 13:51:57 -0000 Hi, Cullen Jennings (fluffy) [mailto:fluffy@cisco.com] wrote: > >On Oct 30, 2012, at 11:42 , Markus.Isomaki@nokia.com wrote: > >> >> * Raise your hand if you think the WG must decide on at least one MTI vi= deo >codec (at this time) >> * Raise your hand if you think the WG should give up on MTI video codec >(for now) and focus on making progress in other areas > >Agree this is critical but we took that previously and there was consensus= for a >MTI video codec. > True. I would just note that if I recall correctly that took place 15 month= s ago, which is a long time. Not sure if it has been refreshed afterwards.= =20 Markus From trac+rtcweb@trac.tools.ietf.org Tue Oct 30 06:54:39 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC8521F84D8 for ; Tue, 30 Oct 2012 06:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxiALkS+SO19 for ; Tue, 30 Oct 2012 06:54:38 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 741AC21F84A8 for ; Tue, 30 Oct 2012 06:54:38 -0700 (PDT) Received: from localhost ([127.0.0.1]:43269 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTCGd-0001q8-Q2; Tue, 30 Oct 2012 14:54:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: jmvalin@jmvalin.ca, fluffy@cisco.com X-Trac-Project: rtcweb Date: Tue, 30 Oct 2012 13:54:07 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/1#comment:1 Message-ID: <081.61527caf7d7dffe6b85335dd1594219d@trac.tools.ietf.org> References: <066.ee8d274029b0215df9ff464ea44b5fe7@trac.tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <066.ee8d274029b0215df9ff464ea44b5fe7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jmvalin@jmvalin.ca, fluffy@cisco.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: rtcweb@ietf.org Subject: Re: [rtcweb] #1: RFC 4734 citation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 List-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, 30 Oct 2012 13:54:39 -0000 #1: RFC 4734 citation Comment (by fluffy@…): This is a bug on draft-ietf-rtcweb-audio-00.txt -- --------------------------------+------------------------- Reporter: bernard_aboba@… | Owner: jmvalin@… Type: defect | Status: new Priority: critical | Milestone: milestone1 Component: audio | Version: 1.0 Severity: Active WG Document | Resolution: Keywords: | --------------------------------+------------------------- Ticket URL: rtcweb From ted.ietf@gmail.com Tue Oct 30 07:14:04 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3FF21F8507 for ; Tue, 30 Oct 2012 07:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4+kxetqYwwb for ; Tue, 30 Oct 2012 07:14:03 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 683F121F84CD for ; Tue, 30 Oct 2012 07:14:03 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so395538vcb.31 for ; Tue, 30 Oct 2012 07:14: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=fwC4ZZKj6Y2LGhNFb9aCQj3LynX5bK65O6PIGfS/Tx4=; b=fSVQ8E6lITWlSbDumt4mh5ACEIm09JupYAa870L4Nf9FXgbyvKSGywxrjazDnhej7m J7hl167bd6ysVmm+mMwPW+stEwH6uR5VaXt+2BsnydLnoQFh6S4iMCUpFkUvK9wxq7Px c8tq/JBrLdCg4fPWKbzLM74JmZFGlcz+O8Om2rFJr4VdGmbzyNEldfo00CDr/060WnAr 9vIk5gMgfz05nOe9MhMP2msfWi/yD8FCza5vv6s1Cm2kXYyo+x3aORB0ZR/xKWOloOlD gj2YHoUfJb+JtNwEIAeb7lR+Semq3QMcvWT1JjoNffH5mfzVtFE8gOQ8E1jPvUA86IMm y67A== MIME-Version: 1.0 Received: by 10.220.223.13 with SMTP id ii13mr13466839vcb.2.1351606442446; Tue, 30 Oct 2012 07:14:02 -0700 (PDT) Received: by 10.58.164.35 with HTTP; Tue, 30 Oct 2012 07:14:02 -0700 (PDT) In-Reply-To: References: <75DADF49-7E1D-4DE0-AF81-D44159C14E12@iii.ca> Date: Tue, 30 Oct 2012 07:14:02 -0700 Message-ID: From: Ted Hardie To: Matthew Kaufman Content-Type: text/plain; charset=ISO-8859-1 Cc: "fluffy@cisco.com" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Oct 2012 14:14:04 -0000 On Tue, Oct 30, 2012 at 5:30 AM, Matthew Kaufman wrote: > If the sum of those hands is the majority, we have better ways to use our time than presenting to people who won't change their mind. > The problem in determining that is the baseline. If we have 10 people object to each in a room full at 150, it looks like things are actually fine for picking either. This is not true, however, if the total number of folks who would have raised their hand in support of anything was 30. By asking the positive question, we get a better shot at understanding what the baseline support is, which is critical. I also note that working in an SDO that requires consensus (even rough consensus) frequently requires compromise. There are lots of aspects of our work that cause us to put the goal of advancing the interoperable standard over advancing our own technical preferences. The form of your question would cause us to downplay both that need and the ability of our participants to take that step if needed. I certainly hope that each of our participants is considering that as they way their answers. regards, Ted From ron@debian.org Tue Oct 30 10:33:23 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3386021F866D for ; Tue, 30 Oct 2012 10:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.577 X-Spam-Level: *** X-Spam-Status: No, score=3.577 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, GB_SUMOF=5, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvqvNgNPvh99 for ; Tue, 30 Oct 2012 10:33:22 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 6637C21F8622 for ; Tue, 30 Oct 2012 10:33:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOINkFB20ird/2dsb2JhbABEw1uBCYIeAQEEATocKAsLGB0RFBgNiDcFrn+OJ4t3gzmDJAOOCYdrAZBCgmIg Received: from ppp118-210-42-221.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([118.210.42.221]) by ipmail06.adl2.internode.on.net with ESMTP; 31 Oct 2012 04:03:20 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id CD42D4F8F3 for ; Wed, 31 Oct 2012 03:56:24 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DKicVDlJ3C00 for ; Wed, 31 Oct 2012 03:56:24 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 65C094F902; Wed, 31 Oct 2012 03:56:24 +1030 (CST) Date: Wed, 31 Oct 2012 03:56:24 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20121030172624.GO6812@audi.shelbyville.oz> References: <75DADF49-7E1D-4DE0-AF81-D44159C14E12@iii.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Oct 2012 17:33:23 -0000 On Tue, Oct 30, 2012 at 12:30:48PM +0000, Matthew Kaufman wrote: > Cullen Jennings: > > > > So lets say we got agreement on something qualified with "regardless of its > > technical and IPR merits (if any)", I can't see how that helps us. We need to > > get agreement without that sort of qualification. > > > > Can folks walk me through how this questions is better? > > > > It doesn't hardly matter *why*... my point of a qualification was covered in > my original questions: It really does matter *why*. Probably even more so than what. > Raise your hand if you want only H.264 and no amount of presentation time > will change that to VP8 > > Raise your hand if you want only VP8 and no amount of presentation time will > change that to H.264 Giving weight to an objection that isn't required to come with any sort of justification whatsoever is not a good method of technical decision-making. Presupposing that objections simply attached to either of those questions should carry equal weight and/or be of equal merit would also seem to lack both engineering and statistical rigour. > If the sum of those hands is the majority, we have better ways to use our > time than presenting to people who won't change their mind. If the sum of those hands is a majority, we should have used our time to formulate more discriminating questions (and consensus answers) about the problem space. I agree that posing a question with one in a nonillion chance of arriving at a coherent answer is not a good use of time. From the discussion so far though, there does seem to be a reasonable amount of consensus about what the dilemmas of either choice are - so perhaps we should summarise that and make some analysis of the merits and problems that we *do* all seem to be in basic agreement about. We might be surprised at how easily an actual, rational, answer could become obviously apparent from that once we peel back the skin of simplistic Do Not Want objections. Cheers, Ron From martin.thomson@gmail.com Tue Oct 30 10:50:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D2721F870A for ; Tue, 30 Oct 2012 10:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrmThw5--39a for ; Tue, 30 Oct 2012 10:50:04 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA3AC21F86EC for ; Tue, 30 Oct 2012 10:50:03 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so475124lbo.31 for ; Tue, 30 Oct 2012 10:50: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=AmazUO6ThgWDRPnHRZU8TV9/pVzDAKPu8GnSJzAb0sM=; b=elraOrhIXRwFdQaQHrFU/YvqaYsxSYgA28Orz6uykktjoISWfEk20dof5Aeg8Q92mf qnRUQObWGlkS+2ZbIRnIAKxmj0GDM2psGYOJx5mqRRgUNPxlpYsRh7vw2ohu6a++Zmei Rzm0ZtSIx9SRA5BOP7NFmEhnzvxrpJw4tyCcMjSVVffx/ThTsP8/3Cd16b530UZePEAb 61M4WqND6dlimrXdf0yHzOC3Ae9/vLZKHB69jApshDFdnSgmHa2zkNSVHhocl4rWNMId VKTDGSA1ZWUW476aszAy7dKTbEK5vGS5vBJr2b6QxgCiYaEUtPhtQF/9Sfh6Gcfd3dXO 5JEA== MIME-Version: 1.0 Received: by 10.112.28.169 with SMTP id c9mr13317686lbh.59.1351619402729; Tue, 30 Oct 2012 10:50:02 -0700 (PDT) Received: by 10.112.83.2 with HTTP; Tue, 30 Oct 2012 10:50:02 -0700 (PDT) In-Reply-To: References: <75DADF49-7E1D-4DE0-AF81-D44159C14E12@iii.ca> Date: Tue, 30 Oct 2012 18:50:02 +0100 Message-ID: From: Martin Thomson To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Cc: "fluffy@cisco.com" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Oct 2012 17:50:05 -0000 On 30 October 2012 15:14, Ted Hardie wrote: > The problem in determining that is the baseline. If we have 10 people > object to each in a room full at 150, it looks like things are > actually fine for picking either. Not as much so if the 10 comprise the browser vendors. (Yes, we're all individuals...) From stewe@stewe.org Tue Oct 30 11:12:13 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099DD21F866D for ; Tue, 30 Oct 2012 11:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YYViz9jLeBD for ; Tue, 30 Oct 2012 11:12:11 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 33B1921F866B for ; Tue, 30 Oct 2012 11:12:10 -0700 (PDT) Received: from mail42-va3-R.bigfish.com (10.7.14.244) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Tue, 30 Oct 2012 18:12:10 +0000 Received: from mail42-va3 (localhost [127.0.0.1]) by mail42-va3-R.bigfish.com (Postfix) with ESMTP id 0DC224203C3; Tue, 30 Oct 2012 18:12:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.133; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0710HT002.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: PS1(zz98dI1432Izz1202h1d1ah1d2ah1082kzz8275bhz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received-SPF: pass (mail42-va3: domain of stewe.org designates 157.56.236.133 as permitted sender) client-ip=157.56.236.133; envelope-from=stewe@stewe.org; helo=BY2PRD0710HT002.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail42-va3 (localhost.localdomain [127.0.0.1]) by mail42-va3 (MessageSwitch) id 1351620728515483_16261; Tue, 30 Oct 2012 18:12:08 +0000 (UTC) Received: from VA3EHSMHS038.bigfish.com (unknown [10.7.14.254]) by mail42-va3.bigfish.com (Postfix) with ESMTP id 7908B40056; Tue, 30 Oct 2012 18:12:08 +0000 (UTC) Received: from BY2PRD0710HT002.namprd07.prod.outlook.com (157.56.236.133) by VA3EHSMHS038.bigfish.com (10.7.99.48) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 30 Oct 2012 18:12:07 +0000 Received: from BY2PRD0710MB354.namprd07.prod.outlook.com ([169.254.11.195]) by BY2PRD0710HT002.namprd07.prod.outlook.com ([10.255.86.37]) with mapi id 14.16.0233.002; Tue, 30 Oct 2012 18:12:05 +0000 From: Stephan Wenger To: "Markus.Isomaki@nokia.com" , "fluffy@cisco.com" Thread-Topic: [rtcweb] Form of the video codec question Thread-Index: AQHNtgBnhFefoY+uxEeuadvRogjlhpfRJvUAgACDjwCAACjYgIAADAoAgADO1YA= Date: Tue, 30 Oct 2012 18:12:05 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.86.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Oct 2012 18:12:13 -0000 Hi, please see inline. On 10.30.2012 06:51 , "Markus.Isomaki@nokia.com" wrote: >Hi, > >Cullen Jennings (fluffy) [mailto:fluffy@cisco.com] wrote: >> >>On Oct 30, 2012, at 11:42 , Markus.Isomaki@nokia.com wrote: >> >>> >>> * Raise your hand if you think the WG must decide on at least one MTI >>>video >>codec (at this time) >>> * Raise your hand if you think the WG should give up on MTI video codec >>(for now) and focus on making progress in other areas >> >>Agree this is critical but we took that previously and there was >>consensus for a >>MTI video codec. >> > >True. I would just note that if I recall correctly that took place 15 >months ago, which is a long time. Not sure if it has been refreshed >afterwards.=20 Yes. Even more importantly, arguments were exchanged for 15 months. Individuals had 15 months time to formulate their positions. More importantly for me (albeit moderately politically incorrect), the employers of those individual also have had 15 months time to formulate their positions, and advise their employees accordingly. I would hope we all understand that both individual positions and guidance are in most cases "hard". No half hour presentation will swing those positions. Stephan > >Markus > > From partha@parthasarathi.co.in Tue Oct 30 11:18:06 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16D121F84FD for ; Tue, 30 Oct 2012 11:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=-0.653, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X73Cq3ksfCVr for ; Tue, 30 Oct 2012 11:18:05 -0700 (PDT) Received: from outbound-us3.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.155]) by ietfa.amsl.com (Postfix) with ESMTP id 653A921F856E for ; Tue, 30 Oct 2012 11:18:05 -0700 (PDT) Received: from userPC (unknown [122.179.84.0]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us3.mailhostbox.com (Postfix) with ESMTPA id 8876C868A19; Tue, 30 Oct 2012 18:18:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1351621085; bh=qPThr0uMuQqyWUzkjRaTMjP3cwHYfuLQXz+1gjn0h8E=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=OpKv+xmHX+LREoRRkzZeFarnr2LIhllS3WcBtbhTfUyPT+P2kenVmGXk87Cp5VGVQ FWHAytjak90HmwxW366L6iKn7LHqwpsPYg7GK8QUvKw5ujQZT+UfC/23njRi+8SBpH nHFSlUfOkJdiVdbGnae7+KzFClGQeBzusq5Wi4F8= From: "Parthasarathi R" To: "'Christer Holmberg'" , "'Cullen Jennings \(fluffy\)'" References: <7594FB04B1934943A5C02806D1A2204B01E60F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B0206F0@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0206F0@ESESSMB209.ericsson.se> Date: Tue, 30 Oct 2012 23:47:56 +0530 Message-ID: <006401cdb6ca$e6102840$b23078c0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2yt7t/ZNifzsQLTfGdplUZjCzVaAAZJ5CAAK2UXaAAPZPxAA== Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0C0206.509019DC.011B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP-02 Comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Oct 2012 18:18:06 -0000 Cullen, PRANSWER open issue is related to JSEP State machine wherein PRANSWER state could not handle OFFER event. Offer event in PRANSWER state is required for the early-dialog UPDATE Offer and on the other hand, ANSWER event in PRANSWER state is required by SIP serial forking. Also, the issue is not related to signaling problem. Christer, IIRC, cloning is removed as there is a consensus not to have parallel forking in one of the earlier interim meeting. Thanks Partha -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Monday, October 29, 2012 6:14 PM To: Cullen Jennings (fluffy) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP-02 Comments Hi, >> Q1: Cloning >> >> I saw that you have removed the text about cloning from version -02. >> >> That is a rather fundamental change, so I think the change log should say a little more than "Clarified section on forking.". > > agree And, do we have a WG concensus to remove cloning? >> Q4: Remove offer >> >> This is related to the PRANSWER issue. >> >> Unless I've missed it, the draft does not address the issue raised on the list, where an offer is received from the remote peer while in PRANSWER state. >> >> (If you solved it on the list, I applogize for not having read it. I've had a flu the whole week, so I am a little behind with my e-mails)] > > that's a signaling problem. I doubt the draft should address it any more than there are a few ways of dealing with it and Javascript can do whatever it wants to choose which one it wants. It's a use-case I'd like the API to support. But, even without PRANSWER it would be tricky, as you have removed cloning. Regards, Christer _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From bernard_aboba@hotmail.com Tue Oct 30 11:47:16 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B872721F8582 for ; Tue, 30 Oct 2012 11:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPeZiu4j+7Wb for ; Tue, 30 Oct 2012 11:47:15 -0700 (PDT) Received: from blu0-omc3-s13.blu0.hotmail.com (blu0-omc3-s13.blu0.hotmail.com [65.55.116.88]) by ietfa.amsl.com (Postfix) with ESMTP id 9C54521F8581 for ; Tue, 30 Oct 2012 11:47:15 -0700 (PDT) Received: from BLU169-DS20 ([65.55.116.73]) by blu0-omc3-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Oct 2012 11:47:14 -0700 X-Originating-IP: [131.107.0.87] X-EIP: [PzK1cFqwpmrr+NbUfJY8g1gRRSuLlgh4] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: "'Parthasarathi R'" , "'Christer Holmberg'" References: <7594FB04B1934943A5C02806D1A2204B01E60F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B0206F0@ESESSMB209.ericsson.se> <006401cdb6ca$e6102840$b23078c0$@co.in> In-Reply-To: <006401cdb6ca$e6102840$b23078c0$@co.in> Date: Tue, 30 Oct 2012 11:47:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHtgAcS0iqZN3zymJMz9m5GtvpSPAGJl60EAYpr/qICBTQT35dp0zAw Content-Language: en-us X-OriginalArrivalTime: 30 Oct 2012 18:47:14.0830 (UTC) FILETIME=[FAA5CAE0:01CDB6CE] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP-02 Comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Oct 2012 18:47:16 -0000 Partha said: "Christer, IIRC, cloning is removed as there is a consensus not to have parallel forking in one of the earlier interim meeting. Thanks Partha" [BA] Can you send a pointer to the consensus determination you are referring to? Also, I cannot find a consensus call on this subject sent to the RTCWEB mailing list. If in fact a consensus determination has been made (either in IETF or W3C), can someone send a pointer to it? From christer.holmberg@ericsson.com Tue Oct 30 12:14:13 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F82521F8620 for ; Tue, 30 Oct 2012 12:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssMXKTH9jxw3 for ; Tue, 30 Oct 2012 12:14:00 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3BA21F8621 for ; Tue, 30 Oct 2012 12:13:59 -0700 (PDT) X-AuditID: c1b4fb25-b7f926d00000661f-40-509026f6f447 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 6E.55.26143.6F620905; Tue, 30 Oct 2012 20:13:58 +0100 (CET) Received: from ESESSHC014.ericsson.se (153.88.183.60) by esessmw0191.eemea.ericsson.se (153.88.115.84) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 30 Oct 2012 20:13:58 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0318.001; Tue, 30 Oct 2012 20:13:57 +0100 From: Christer Holmberg To: 'Bernard Aboba' , 'Parthasarathi R' Thread-Topic: [rtcweb] JSEP-02 Comments Thread-Index: Ac2yt7t/ZNifzsQLTfGdplUZjCzVaAAZJ5CAAK2UXaAAPZPxAP//+zoA///n8+A= Date: Tue, 30 Oct 2012 19:13:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B021AA4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B01E60F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B0206F0@ESESSMB209.ericsson.se> <006401cdb6ca$e6102840$b23078c0$@co.in> 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.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM+Jvre43tQkBBs/6jSz2L7nMbDH5Ux+r xdp/7ewOzB6Pe86weSxZ8pPJ48P8L+wBzFFcNimpOZllqUX6dglcGWtXT2AsOMJWMafLqIFx DmsXIyeHhICJxPuZ71kgbDGJC/fWs3UxcnEICZxklOj41QDl7GSUWHn8OhOEs4RRYv+MS4xd jBwcbAIWEt3/tEG6RQQSJY7dOcEGYjMLqEvcWXyOHcQWFlCT2HoepBykRl3i9+VlzBC2n8TL +e/BbBYBVYnX01aCXcQr4C2x5vRKqF2rmSTOdh0HK+IUsJb4+PQ2E4jNCHTq91NrmCCWiUvc ejKfCeIFAYkle84zQ9iiEi8f/4N6U1Hi46t9jBD1OhILdn+COlRbYtnC18wQiwUlTs58Ag4K IaB4y+IJ7BMYJWYhWTELSfssJO2zkLQvYGRZxciem5iZk15utIkRGGkHt/xW3cF455zIIUZp DhYlcV7rrXv8hQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBOSr1a/Ti0zPAm80SvN/FyPO67 HrSVhzM+VQpesOuzNMeM7Lbtc/sLjQs7wpf9SzGc4BjU1fP3jRpPtUa8Y5Q3l/Ghki/MuwwK VtReP72hVmdt3dIClkVRKeecnIV/vP9ZynbC2WBpa6X4XveLsb0rdm38If7l0lOmz4V7z+3b v2vrr2B5nmglluKMREMt5qLiRADTZTAMggIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-02 Comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Oct 2012 19:14:13 -0000 Hi, There has been discussions about using cloning for SERIAL forking, because = it would solve some issues. Regards, Christer=20 -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: 30. lokakuuta 2012 20:47 To: 'Parthasarathi R'; Christer Holmberg Cc: rtcweb@ietf.org Subject: RE: [rtcweb] JSEP-02 Comments Partha said:=20 "Christer, IIRC, cloning is removed as there is a consensus not to have parallel forki= ng in one of the earlier interim meeting. Thanks Partha" [BA] Can you send a pointer to the consensus determination you are referrin= g to? Also, I cannot find a consensus call on this subject sent to the RTC= WEB mailing list. If in fact a consensus determination has been made (either in IETF or W3C), can someone send a pointer to it?=20 From adam@nostrum.com Tue Oct 30 15:33:53 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E59521F85EB for ; Tue, 30 Oct 2012 15:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aT5jNjWjuFAR for ; Tue, 30 Oct 2012 15:33:52 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 646E521F873B for ; Tue, 30 Oct 2012 15:33:52 -0700 (PDT) Received: from hydra-en0.roach.at (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q9UMXeSt039873 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 30 Oct 2012 17:33:41 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <509055C4.6060500@nostrum.com> Date: Tue, 30 Oct 2012 17:33:40 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: John Leslie References: <20121029210443.GB68232@verdi> In-Reply-To: <20121029210443.GB68232@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Oct 2012 22:33:53 -0000 On 10/29/12 16:04, Oct 29, John Leslie wrote: > I view both being MTI as somewhat reasonable, and neither being MTI > as a likely best-choice That's an interesting set of assertions. I, for one, cannot see how you reached either conclusion. Selecting "both" solves none of the problems that have been raised to date. It takes on the entire union of disadvantages that have been raised about the candidate codecs, while providing the benefits of neither. Selecting "neither" is intentionally aiming the ship for the rocks: we guarantee failure. If we publish a specification to which two implementations can comply but cannot subsequently inter-operate, then the entire point of standardization is defeated. /a From adam@nostrum.com Tue Oct 30 15:42:38 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B233721F841C for ; Tue, 30 Oct 2012 15:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.1 X-Spam-Level: X-Spam-Status: No, score=-100.1 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUdSCoGaw3KK for ; Tue, 30 Oct 2012 15:42:38 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 17C5421F841B for ; Tue, 30 Oct 2012 15:42:37 -0700 (PDT) Received: from hydra-en0.roach.at (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q9UMgWpS041101 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 30 Oct 2012 17:42:33 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <509057D8.8000600@nostrum.com> Date: Tue, 30 Oct 2012 17:42:32 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Matthew Kaufman References: <75DADF49-7E1D-4DE0-AF81-D44159C14E12@iii.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: "fluffy@cisco.com" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Oct 2012 22:42:38 -0000 On 10/30/12 07:30, Oct 30, Matthew Kaufman wrote: > my point of a qualification was covered in my original questions: > > Raise your hand if you want only H.264 and no amount of presentation time will change that to VP8 > > Raise your hand if you want only VP8 and no amount of presentation time will change that to H.264 > > If the sum of those hands is the majority, we have better ways to use our time than presenting to people who won't change their mind. *If* those questions were asked (and I like Ted's formulation better), *and* the sum of the hands comprised the majority, then I would agree that we have better ways to use our time than presenting technical issues to the entire WG. In my opinion, foremost among those would be selecting which of the mechanisms in section 4 of RFC 3929 the WG thinks is most applicable. /a From stewe@stewe.org Tue Oct 30 18:41:24 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9256A21F8639 for ; Tue, 30 Oct 2012 18:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k49IP61Pkaru for ; Tue, 30 Oct 2012 18:41:20 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 13C9321F876C for ; Tue, 30 Oct 2012 18:41:19 -0700 (PDT) Received: from mail124-ch1-R.bigfish.com (10.43.68.230) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.23; Wed, 31 Oct 2012 01:41:14 +0000 Received: from mail124-ch1 (localhost [127.0.0.1]) by mail124-ch1-R.bigfish.com (Postfix) with ESMTP id E852E32006B; Wed, 31 Oct 2012 01:41:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.133; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0710HT001.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: PS-20(zzbb2dI98dI1432Izz1202h1d1ah1d2ah1082kzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received-SPF: pass (mail124-ch1: domain of stewe.org designates 157.56.236.133 as permitted sender) client-ip=157.56.236.133; envelope-from=stewe@stewe.org; helo=BY2PRD0710HT001.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail124-ch1 (localhost.localdomain [127.0.0.1]) by mail124-ch1 (MessageSwitch) id 135164767375841_23714; Wed, 31 Oct 2012 01:41:13 +0000 (UTC) Received: from CH1EHSMHS013.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail124-ch1.bigfish.com (Postfix) with ESMTP id 102FF220064; Wed, 31 Oct 2012 01:41:13 +0000 (UTC) Received: from BY2PRD0710HT001.namprd07.prod.outlook.com (157.56.236.133) by CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 31 Oct 2012 01:41:12 +0000 Received: from BY2PRD0710MB354.namprd07.prod.outlook.com ([169.254.11.195]) by BY2PRD0710HT001.namprd07.prod.outlook.com ([10.255.86.36]) with mapi id 14.16.0233.002; Wed, 31 Oct 2012 01:41:11 +0000 From: Stephan Wenger To: Adam Roach , John Leslie Thread-Topic: [rtcweb] Form of the video codec question Thread-Index: AQHNtgBnhFefoY+uxEeuadvRogjlhpfQxgiAgAGrLwCAALp9AA== Date: Wed, 31 Oct 2012 01:41:10 +0000 Message-ID: In-Reply-To: <509055C4.6060500@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.86.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <6EB661A70B79AF4CB6E8EF90621DA7E4@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 01:41:24 -0000 Hi Adam, On 10.30.2012 15:33 , "Adam Roach" wrote: >On 10/29/12 16:04, Oct 29, John Leslie wrote: >> I view both being MTI as somewhat reasonable, and neither being MTI >> as a likely best-choice > >That's an interesting set of assertions. I, for one, cannot see how you >reached either conclusion. > >Selecting "both" solves none of the problems that have been raised to >date. It takes on the entire union of disadvantages that have been >raised about the candidate codecs, while providing the benefits of >neither. > >Selecting "neither" is intentionally aiming the ship for the rocks: we >guarantee failure. If we publish a specification to which two >implementations can comply but cannot subsequently inter-operate, then >the entire point of standardization is defeated. I disagree. It just takes a commercial decision making process out of the hands of IETF geeks and into the hands of (hopefully) competent business people. Given the money and risk involved, that is sensible. SDOs can do wonderful things, but sorting out this dispute is not one of them. Stephan > >/a >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb > From ron@debian.org Tue Oct 30 21:43:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A144721F84A2 for ; Tue, 30 Oct 2012 21:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.077 X-Spam-Level: * X-Spam-Status: No, score=1.077 tagged_above=-999 required=5 tests=[AWL=2.500, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YRRwer2oiKp for ; Tue, 30 Oct 2012 21:43:42 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id CC0D821F849F for ; Tue, 30 Oct 2012 21:43:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAE6rkFB20ird/2dsb2JhbABEw3yBCYIeAQEFOhwzCxguFBgNNxuHarxXi3eDF4MkA44Jh2sBkEKDAg Received: from ppp118-210-42-221.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([118.210.42.221]) by ipmail06.adl6.internode.on.net with ESMTP; 31 Oct 2012 15:13:31 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 35E8B4F8F3 for ; Wed, 31 Oct 2012 15:13:30 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6MV02QSMApRh for ; Wed, 31 Oct 2012 15:13:28 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id A90514F902; Wed, 31 Oct 2012 15:13:28 +1030 (CST) Date: Wed, 31 Oct 2012 15:13:28 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20121031044328.GP6812@audi.shelbyville.oz> References: <509055C4.6060500@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 04:43:42 -0000 On Wed, Oct 31, 2012 at 01:41:10AM +0000, Stephan Wenger wrote: > On 10.30.2012 15:33 , "Adam Roach" wrote: > > >On 10/29/12 16:04, Oct 29, John Leslie wrote: > >> I view both being MTI as somewhat reasonable, and neither being MTI > >> as a likely best-choice > > > >That's an interesting set of assertions. I, for one, cannot see how you > >reached either conclusion. > > > >Selecting "both" solves none of the problems that have been raised to > >date. It takes on the entire union of disadvantages that have been > >raised about the candidate codecs, while providing the benefits of > >neither. > > > >Selecting "neither" is intentionally aiming the ship for the rocks: we > >guarantee failure. If we publish a specification to which two > >implementations can comply but cannot subsequently inter-operate, then > >the entire point of standardization is defeated. > > I disagree. It just takes a commercial decision making process out of the > hands of IETF geeks and into the hands of (hopefully) competent business > people. Didn't this group form precisely because the hopefully competent business people have so far only produced a diverse number of unacceptable solutions and people *really* wanted something better than that? The choice of MTI codec here isn't a commercial decision, it's a technical one. If we make the right choice, we will ensure the broadest number of implementors have the option to use it, and the broadest number of implementations will be interoperable. There are probably perfectly good "commercial decision making processes" which might arrive at the conclusion that this is not in their best interest and is something that should be opposed and stalled at every step of the way. That is their right. But it's not the charter of this group ... I think the concerns Adam voiced are both real and outcomes to be avoided. Ron From matthew.kaufman@skype.net Tue Oct 30 23:26:56 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34EA21F85C2 for ; Tue, 30 Oct 2012 23:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.937 X-Spam-Level: X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=0.663, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXJOaYMqBmFL for ; Tue, 30 Oct 2012 23:26:55 -0700 (PDT) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFE921F855F for ; Tue, 30 Oct 2012 23:26:55 -0700 (PDT) Received: from BY2FFO11FD016.protection.gbl (10.1.15.204) by BY2FFO11HUB027.protection.gbl (10.1.14.113) with Microsoft SMTP Server (TLS) id 15.0.545.8; Wed, 31 Oct 2012 06:26:53 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD016.mail.protection.outlook.com (10.1.14.132) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Wed, 31 Oct 2012 06:26:52 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.52]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Wed, 31 Oct 2012 06:26:26 +0000 From: Matthew Kaufman To: Ron , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Form of the video codec question Thread-Index: AQHNtgBjxnCRTWxEdEm8PEWsc927e5fQxgiAgAGrLwCAADRjAIAAMu8AgAAZufA= Date: Wed, 31 Oct 2012 06:26:26 +0000 Message-ID: References: <509055C4.6060500@nostrum.com> <20121031044328.GP6812@audi.shelbyville.oz> In-Reply-To: <20121031044328.GP6812@audi.shelbyville.oz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(377454001)(5343655001)(44976002)(50986001)(49866001)(74662001)(46102001)(4396001)(33656001)(47446002)(54316001)(54356001)(47776002)(31966008)(16406001)(47736001)(53806001)(74502001)(47976001)(48376001)(51856001)(50466001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 06515DA04B Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 06:26:56 -0000 > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Ron > Sent: Wednesday, October 31, 2012 5:43 AM > > Didn't this group form precisely because the hopefully competent business > people have so far only produced a diverse number of unacceptable > solutions and people *really* wanted something better than that? No, I don't believe that was the motivation for forming the RTCWEB working = group. =20 > The choice of MTI codec here isn't a commercial decision, it's a technica= l one. > If we make the right choice, we will ensure the broadest number of > implementors have the option to use it, and the broadest number of > implementations will be interoperable. No, we won't. No matter what this WG decides, people who are not in the roo= m will ultimately make the decision as to what business model they wish to = pursue and what business risks they are willing to take... and thus whether= or not their implementation will interoperate with others. =09 Matthew Kaufman From ron.even.tlv@gmail.com Tue Oct 30 23:38:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE7221F8206 for ; Tue, 30 Oct 2012 23:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIuhNrpz53E3 for ; Tue, 30 Oct 2012 23:38:41 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 580CA21F8200 for ; Tue, 30 Oct 2012 23:38:40 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so618950eek.31 for ; Tue, 30 Oct 2012 23:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=W/sJ8whwUlXKQgp9hzKANTav+iCIvBVnpBYQEVuxo5U=; b=Vx78LF7Vntm6YmLOY597srXjzOeTbVRFP3eI1dYgnGxlXbD+JDWfdxdeD083EtBwqj 4M5HKXJAjxacLFg5Q2N4louj5s4hDA4eiN5W5eHv8HKfMMRgSjyfS4B2ZPwyzs34i14/ UK8x15k0MHuNEg0XB6O9JRz1qR2yLvEjTW5na6xsLNeYrrwfzJ84ULpgqwpetoxtrCe5 ENW/QdZt57+A4OupYr+5Ha3aeTGivVG/l7BpIAhoEeIFJLbJyq8nghhsa28xgofCLkWR HFiHGqi7s66n+yoLAwGq5bKP5E4mpopsxv7oL5UtyYro4BzvxJgUy2tn9mWQa21evXki j0Ug== Received: by 10.14.178.195 with SMTP id f43mr82712282eem.44.1351665519376; Tue, 30 Oct 2012 23:38:39 -0700 (PDT) Received: from RoniE (bzq-79-182-208-105.red.bezeqint.net. [79.182.208.105]) by mx.google.com with ESMTPS id c6sm6025539eep.17.2012.10.30.23.38.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 30 Oct 2012 23:38:38 -0700 (PDT) From: "Roni Even" To: "'Adam Roach'" , "'John Leslie'" References: <20121029210443.GB68232@verdi> <509055C4.6060500@nostrum.com> In-Reply-To: <509055C4.6060500@nostrum.com> Date: Wed, 31 Oct 2012 08:36:26 +0200 Message-ID: <01c301cdb732$0fac72a0$2f0557e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHmVfERLT7WWl8bzf5GkI1RViuLmQGzTvaXAzILO9aXeo0HEA== Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 06:38:42 -0000 Hi, Just to be precise, if we do not chose a common video codec the interoperability point will be an audio call Roni -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Adam Roach Sent: 31 October, 2012 12:34 AM To: John Leslie Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Form of the video codec question On 10/29/12 16:04, Oct 29, John Leslie wrote: > I view both being MTI as somewhat reasonable, and neither being > MTI as a likely best-choice That's an interesting set of assertions. I, for one, cannot see how you reached either conclusion. Selecting "both" solves none of the problems that have been raised to date. It takes on the entire union of disadvantages that have been raised about the candidate codecs, while providing the benefits of neither. Selecting "neither" is intentionally aiming the ship for the rocks: we guarantee failure. If we publish a specification to which two implementations can comply but cannot subsequently inter-operate, then the entire point of standardization is defeated. /a _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From lorenzo@meetecho.com Tue Oct 30 23:56:32 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C5621F8654 for ; Tue, 30 Oct 2012 23:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VWEwLz9lwdf for ; Tue, 30 Oct 2012 23:56:32 -0700 (PDT) Received: from smtpdg3.aruba.it (smtpdg3.aruba.it [62.149.158.233]) by ietfa.amsl.com (Postfix) with ESMTP id BB0BF21F8540 for ; Tue, 30 Oct 2012 23:56:31 -0700 (PDT) Received: from rainpc ([79.49.159.202]) by smtpcmd01.ad.aruba.it with bizsmtp id HiwT1k00A4NJ6Ef01iwTtB; Wed, 31 Oct 2012 07:56:29 +0100 Date: Wed, 31 Oct 2012 07:56:26 +0100 From: Lorenzo Miniero To: "Roni Even" Message-ID: <20121031075626.6fbf6ea4@rainpc> In-Reply-To: <01c301cdb732$0fac72a0$2f0557e0$@gmail.com> References: <20121029210443.GB68232@verdi> <509055C4.6060500@nostrum.com> <01c301cdb732$0fac72a0$2f0557e0$@gmail.com> Organization: Meetecho X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 06:56:33 -0000 On Wed, 31 Oct 2012 08:36:26 +0200 "Roni Even" wrote: > Hi, > Just to be precise, if we do not chose a common video codec the > interoperability point will be an audio call > Roni > Not if we pick an "older" video codec as a MTI one as we did for G.711 (well maybe not *that* old). L. > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of > Adam Roach > Sent: 31 October, 2012 12:34 AM > To: John Leslie > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Form of the video codec question > > On 10/29/12 16:04, Oct 29, John Leslie wrote: > > I view both being MTI as somewhat reasonable, and neither being > > MTI as a likely best-choice > > That's an interesting set of assertions. I, for one, cannot see how you > reached either conclusion. > > Selecting "both" solves none of the problems that have been raised to date. > It takes on the entire union of disadvantages that have been raised about > the candidate codecs, while providing the benefits of neither. > > Selecting "neither" is intentionally aiming the ship for the rocks: we > guarantee failure. If we publish a specification to which two > implementations can comply but cannot subsequently inter-operate, then the > entire point of standardization is defeated. > > /a > _______________________________________________ > 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 -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From oej@edvina.net Wed Oct 31 00:23:33 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3100A21F84D6 for ; Wed, 31 Oct 2012 00:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4FEN+wYxSFw for ; Wed, 31 Oct 2012 00:23:32 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD2C21F8433 for ; Wed, 31 Oct 2012 00:23:25 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1003] (unknown [IPv6:2001:16d8:cc57:1000::42:1003]) by smtp7.webway.se (Postfix) with ESMTPA id 62BE1754A8A7; Wed, 31 Oct 2012 07:23:22 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: Date: Wed, 31 Oct 2012 08:23:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Stephan Wenger X-Mailer: Apple Mail (2.1499) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 07:23:33 -0000 31 okt 2012 kl. 02:41 skrev Stephan Wenger : > Hi Adam, >=20 > On 10.30.2012 15:33 , "Adam Roach" wrote: >=20 >> On 10/29/12 16:04, Oct 29, John Leslie wrote: >>> I view both being MTI as somewhat reasonable, and neither being = MTI >>> as a likely best-choice >>=20 >> That's an interesting set of assertions. I, for one, cannot see how = you >> reached either conclusion. >>=20 >> Selecting "both" solves none of the problems that have been raised to >> date. It takes on the entire union of disadvantages that have been >> raised about the candidate codecs, while providing the benefits of >> neither. >>=20 >> Selecting "neither" is intentionally aiming the ship for the rocks: = we >> guarantee failure. If we publish a specification to which two >> implementations can comply but cannot subsequently inter-operate, = then >> the entire point of standardization is defeated. >=20 > I disagree. It just takes a commercial decision making process out of = the > hands of IETF geeks and into the hands of (hopefully) competent = business > people. Given the money and risk involved, that is sensible. >=20 Ending up with a situation where users have to find out which browser to use in order to interoperate with one specific WebRTC application is a = big failure. Like in the days of web pages saying "Sorry, this web page only supports = on Huckzilla Explorer v5." I agree with Adam, that would defeat the point of standardization. We = have that mess with SIP SIMPLE - there are many implementations that fail to interoperate, thus SIP SIMPLE is not taking off outside of walled = gardens. We want interoperability, we don't want more plugins or having to select the right web browser to reach your application. /O= From ron@debian.org Wed Oct 31 01:15:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD51F21F8703 for ; Wed, 31 Oct 2012 01:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.173 X-Spam-Level: X-Spam-Status: No, score=-0.173 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0kE2A4xKrJj for ; Wed, 31 Oct 2012 01:14:58 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 3533C21F86FF for ; Wed, 31 Oct 2012 01:14:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABLdkFB20ird/2dsb2JhbABEw2uBCYIeAQEEATocMwsVAQIVEgcUGA0NKhuHZQUMu0+Ld4MLDIMkA44Jh2sBgRqPKIMC Received: from ppp118-210-42-221.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([118.210.42.221]) by ipmail07.adl2.internode.on.net with ESMTP; 31 Oct 2012 18:44:52 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 140A94F8F3 for ; Wed, 31 Oct 2012 18:44:51 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vU95fIiGYYcw for ; Wed, 31 Oct 2012 18:44:50 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 057884F902; Wed, 31 Oct 2012 18:44:50 +1030 (CST) Date: Wed, 31 Oct 2012 18:44:49 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20121031081449.GQ6812@audi.shelbyville.oz> References: <509055C4.6060500@nostrum.com> <20121031044328.GP6812@audi.shelbyville.oz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 08:15:03 -0000 On Wed, Oct 31, 2012 at 06:26:26AM +0000, Matthew Kaufman wrote: > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > Behalf Of Ron > > Sent: Wednesday, October 31, 2012 5:43 AM > > > > Didn't this group form precisely because the hopefully competent business > > people have so far only produced a diverse number of unacceptable > > solutions and people *really* wanted something better than that? > > No, I don't believe that was the motivation for forming the RTCWEB working group. "Description of Working Group: There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. ..." You can read the rest here: http://tools.ietf.org/wg/rtcweb/charters Which bit of that do you not believe, or think is unclear? > > The choice of MTI codec here isn't a commercial decision, it's a technical one. > > If we make the right choice, we will ensure the broadest number of > > implementors have the option to use it, and the broadest number of > > implementations will be interoperable. > > No, we won't. No matter what this WG decides, people who are not in the room > will ultimately make the decision as to what business model they wish to > pursue and what business risks they are willing to take... and thus whether > or not their implementation will interoperate with others. And that's fine, but totally irrelevant to the technical decisions of the working group. If those people want their opinions and technical arguments to be taken into account, then hiding in another room might not be the best strategy they could employ to air them. It would certainly be odd to abandon the charter because of rumours that people not here didn't want interoperability with others. Wouldn't it? We can't stop them from persisting with being part of the problem that the group was chartered to solve. But we likewise shouldn't let them stop us from solving it in the best and most broadly accessible way possible anyhow. There are always going to be business models that feel threatened by an open standard that can be freely implemented by anyone. That doesn't mean that people don't want and need them, or that we shouldn't make them and collaborate to make them the best they can be. Colloidially, Ron From ibc@aliax.net Wed Oct 31 03:42:42 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D4C21F86C7 for ; Wed, 31 Oct 2012 03:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64JnpJsmKrn5 for ; Wed, 31 Oct 2012 03:42:41 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3625B21F8660 for ; Wed, 31 Oct 2012 03:42:41 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so1024674lbo.31 for ; Wed, 31 Oct 2012 03:42:40 -0700 (PDT) X-Google-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:content-transfer-encoding:x-gm-message-state; bh=BkEeJhGOpRDX3o7SL+c2E88P/zKBoh6XGaUMEWukthw=; b=UJf0nEguKp9ISMkMk/fWfx+yE758l7liDbdiJATR0w/JfeCe0s5inpQPx7I5g5S+Ws G+fxtnV+osHqM2f2khehpXmYtnz0O8W+BaGzoRk/i6JI+NO4VKEPBRpNmeed3Wyhu9/X K/XLsv8SD434K8cnAgaZ2MAoOVUQd5ihGG9pDert9585RTY9te/RpPvNJB1BScZQ4d1F PaT+qQHsCAGoxBI+erxDMXSkbwGOEn1hZtLyyG1e0nL/GgmtAa7CFbAF1P6Bl8Jbek7k fUHpnZj2Iybu+SZ6GTl8zYGezWMCOJbZvwemr18Ra+VFX2F2g5pZH0pyzqI+4b9Sors8 HzTQ== Received: by 10.152.109.145 with SMTP id hs17mr33648984lab.5.1351680160156; Wed, 31 Oct 2012 03:42:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Wed, 31 Oct 2012 03:42:20 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B021AA4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B01E60F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B0206F0@ESESSMB209.ericsson.se> <006401cdb6ca$e6102840$b23078c0$@co.in> <7594FB04B1934943A5C02806D1A2204B021AA4@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 31 Oct 2012 11:42:20 +0100 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlfJ701gGFrT1+Mv8Yf5/S6MsaVwooIMuYpsKfkHlPNLp+/XBo/vXoZd3HNnL36vbnA0z4l Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-02 Comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 10:42:42 -0000 2012/10/30 Christer Holmberg : > There has been discussions about using cloning for SERIAL forking, becaus= e it would solve some issues. PRANSWER just solves a specific *SIP* usecase or need (but not all). Cloning would solve all the related problems and would allow implementing any kind of logic on top of WebRTC (including full SIP). So IMHO PRANSWER looks like a hack introduced by SIP guys into WebRTC, regardless it makes no sense at all in the WWW world. --=20 I=C3=B1aki Baz Castillo From matthew.kaufman@skype.net Wed Oct 31 03:58:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CD321F867D for ; Wed, 31 Oct 2012 03:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2B05bF7-j19 for ; Wed, 31 Oct 2012 03:58:35 -0700 (PDT) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.24]) by ietfa.amsl.com (Postfix) with ESMTP id 423ED21F865E for ; Wed, 31 Oct 2012 03:58:35 -0700 (PDT) Received: from BL2FFO11FD007.protection.gbl (10.173.161.202) by BL2FFO11HUB037.protection.gbl (10.173.160.241) with Microsoft SMTP Server (TLS) id 15.0.545.8; Wed, 31 Oct 2012 10:58:27 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD007.mail.protection.outlook.com (10.173.161.3) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Wed, 31 Oct 2012 10:58:26 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.52]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Wed, 31 Oct 2012 10:58:03 +0000 From: Matthew Kaufman To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "Christer Holmberg" Thread-Topic: [rtcweb] JSEP-02 Comments Thread-Index: Ac2yt7t/ZNifzsQLTfGdplUZjCzVaAAdWHOAAKl9f4AAPfPBAAABBfcAAADu3YAAIGxlAAAAcEhg Date: Wed, 31 Oct 2012 10:58:02 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B01E60F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B0206F0@ESESSMB209.ericsson.se> <006401cdb6ca$e6102840$b23078c0$@co.in> <7594FB04B1934943A5C02806D1A2204B021AA4@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(74662001)(47446002)(16406001)(46102001)(48376001)(74502001)(47736001)(31966008)(33656001)(50466001)(54356001)(53806001)(44976002)(51856001)(47776002)(5343655001)(4396001)(47976001)(54316001)(49866001)(50986001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 06515DA04B Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-02 Comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 10:58:35 -0000 PiBGcm9tOiBydGN3ZWItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGll dGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgScOxYWtpIEJheiBDYXN0aWxsbw0KPg0KPiBTbyBJTUhP IFBSQU5TV0VSIGxvb2tzIGxpa2UgYSBoYWNrIGludHJvZHVjZWQgYnkgU0lQIGd1eXMgaW50byBX ZWJSVEMsDQo+IHJlZ2FyZGxlc3MgaXQgbWFrZXMgbm8gc2Vuc2UgYXQgYWxsIGluIHRoZSBXV1cg d29ybGQuDQoNCldlbGwsIHNpbmNlIHVzaW5nIFNEUCBPZmZlci9BbnN3ZXIgYXMgdGhlIEFQSSBp cyBhICJoYWNrIGludHJvZHVjZWQgYnkgU0lQIGd1eXMgaW50byBXZWJSVEMiLCBJJ20gbm90IGF0 IGFsbCBzdXJwcmlzZWQgdG8gc2VlIHJlcXVpcmVtZW50cyBmb3IgdGhpbmdzIGxpa2UgUFJBTlNX RVIgc2hvd2luZyB1cC4NCg0KTmV4dCB5b3UncmUgZ29pbmcgdG8gd29uZGVyIHdoeSBhIHNpbmds ZSBSVENQZWVyQ29ubmVjdGlvbiBvYmplY3QgcmVwcmVzZW50cyBvcGVuIElDRSBzZXNzaW9ucyB3 aXRoIFJUUCBtZWRpYSBmbG93aW5nIGJldHdlZW4gdGhpcyBicm93c2VyIGFuZCAqYW55IG51bWJl ciogb2YgcmVtb3RlIHBlZXJzLg0KDQpNYXR0aGV3IEthdWZtYW4NCg0K From ibc@aliax.net Wed Oct 31 04:13:40 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D072121F86BE for ; Wed, 31 Oct 2012 04:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COd5xiIXvRHC for ; Wed, 31 Oct 2012 04:13:40 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id F259321F84C7 for ; Wed, 31 Oct 2012 04:13:39 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so1028518lam.31 for ; Wed, 31 Oct 2012 04:13:39 -0700 (PDT) X-Google-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:content-transfer-encoding:x-gm-message-state; bh=pO0WyP5mDPmg7bLngL/mBWUXhtcxJzzu6TuX8sNENIA=; b=C7BdeEpgwCsR+wb8+zCpu4tKlz/v04iAia5QPutk5FyRBGh4pcfNEPk4L7moVi5kEc H670NxsImj1jiRTmbGanLDOFxQl9aW7rldXWOVcvU8kR5gwvAuqn8LxbdZ2t5fyBnH0n v/eIVrO4xBovvMDD08p0Xs98zoQDPHJwNirISSF3wVcSd53z0vlSo6FcyLovMzWXO4j3 THc4YXeu0zbnm2pe2Wt2ZRS2xwNBCEaa63yy10GfV0J4oEvOHnmgSfPpIdAkrR2uAE8f sI4GtGIQaqO13LITIdKGdIb94wlnRix3K4kqldKrVibt8F6jW6fHXue9yzcX2wHK2xTA u76Q== Received: by 10.112.29.129 with SMTP id k1mr14644208lbh.102.1351682018928; Wed, 31 Oct 2012 04:13:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Wed, 31 Oct 2012 04:13:18 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B01E60F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B0206F0@ESESSMB209.ericsson.se> <006401cdb6ca$e6102840$b23078c0$@co.in> <7594FB04B1934943A5C02806D1A2204B021AA4@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 31 Oct 2012 12:13:18 +0100 Message-ID: To: Matthew Kaufman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl5B82l4qKYsTD8a/NR/vxf3R0mwR1I/1I8GxSOqGC8A8nCuzRgeith4SY2HO0iyHFZoOto Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-02 Comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 11:13:40 -0000 2012/10/31 Matthew Kaufman : > Well, since using SDP Offer/Answer as the API is a "hack introduced by SI= P guys into WebRTC", I'm not at all surprised to see requirements for thing= s like PRANSWER showing up. Yes, I understand, but the real requirement for really respecting RFC 3264 was implementing cloning (see below please), instead of PRANSWER which is a pseudo-hack for allowing some specific and existing use cases of SIP (but not all). If I make a call, receive two 183 with early media (different early-dialogs), and want to render both audio streams locally, how to do that with PRANSWER? Cloning was the key for that. > Next you're going to wonder why a single RTCPeerConnection object represe= nts open ICE sessions with RTP media flowing between this browser and *any = number* of remote peers. AFAIR the "cloning" proposal means that you end with N RTCPeerConnection instances, each of them having media with a single remote peer. The only they share is the same local SDP. --=20 I=C3=B1aki Baz Castillo From singer@apple.com Wed Oct 31 06:08:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A8721F846A for ; Wed, 31 Oct 2012 06:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEeYAzxySx2n for ; Wed, 31 Oct 2012 06:08:35 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF4A21F846D for ; Wed, 31 Oct 2012 06:08:35 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay17.apple.com ([17.128.113.18]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MCR00DOHDTZT530@mail-out.apple.com> for rtcweb@ietf.org; Wed, 31 Oct 2012 06:08:35 -0700 (PDT) X-AuditID: 11807112-b7f296d000001183-d6-509122d2e39c Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay17.apple.com (Apple SCV relay) with SMTP id 2F.B8.04483.2D221905; Wed, 31 Oct 2012 06:08:34 -0700 (PDT) Received: from [17.78.214.78] (unknown [17.78.214.78]) by chive.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MCR00KYEDU7OA00@chive.apple.com> for rtcweb@ietf.org; Wed, 31 Oct 2012 06:08:34 -0700 (PDT) From: David Singer In-reply-to: <20121031044328.GP6812@audi.shelbyville.oz> Date: Wed, 31 Oct 2012 14:08:31 +0100 Message-id: <64970915-B33A-4D6F-B440-14C62F9301A2@apple.com> References: <509055C4.6060500@nostrum.com> <20121031044328.GP6812@audi.shelbyville.oz> To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1499) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUi2FDMr3tJaWKAwdan1hZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEro/vmB+aCHq6K90tSGhi/sncxcnJICJhIzO87zAphi0lcuLee rYuRi0NIYAKTxNe5c5ghnJlMEm9e7mcCqWIW0JJYv/M4kM3BwSugJzFpfxBIWFjATGJX+xSw QWwCqhIP5hxjBLE5BSwknrfOYwOxWYDii3fPZIMYoy3x5N0FsHpeARuJXcdhFq9nlJh15TxY QkRAXeLywwtQl8pKrJjayzSBkX8WkjNmIZwxC8nYBYzMqxgFi1JzEisNzfUSCwpyUvWS83M3 MYIDrFBoB+P9XXqHGAU4GJV4eLW+9wcIsSaWFVfmHmKU4GBWEuGd/W1CgBBvSmJlVWpRfnxR aU5q8SFGaQ4WJXHer55AKYH0xJLU7NTUgtQimCwTB6dUA2P+095Cz6cONk2d/3OTWTw6HP23 vm2bv+eXSQLT7I0tfMYCnpxfcpdZ6aocTpecX5rxn21nJAd/qazwvN0X6lQKRBa7/Os7K2N2 x6JTXOtqa1Danwe8TU53VvZcSY8Pdq29Ws8t+qj0r6VhzNH8VyL1kQtK9WdFHOOUOvhNvcCM aVFZRZqZEktxRqKhFnNRcSIAAr37uCwCAAA= Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 13:08:35 -0000 On Oct 31, 2012, at 5:43 , Ron wrote: > > The choice of MTI codec here isn't a commercial decision, it's a technical > one. Not at all; there are any number of codecs which would be adequate as the catch-all 'fallback' codec. The willingness, or ability, to license, and implement, are key -- commercial -- questions, and the essence of the debate. > If we make the right choice, we will ensure the broadest number of > implementors have the option to use it, and the broadest number of > implementations will be interoperable. Our choice is only part of the solution; it has to be viable and actually implemented. I would hazard to guess that what most will implement is a choice made almost entirely indpendently of any MTI tag in the spec. > > There are probably perfectly good "commercial decision making processes" > which might arrive at the conclusion that this is not in their best > interest and is something that should be opposed and stalled at every > step of the way. That is their right. But it's not the charter of this > group ... > > > I think the concerns Adam voiced are both real and outcomes to be avoided. David Singer Multimedia and Software Standards, Apple Inc. From richard@shockey.us Wed Oct 31 06:27:50 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4429C21F84BC for ; Wed, 31 Oct 2012 06:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djOaV1mDOjFi for ; Wed, 31 Oct 2012 06:27:49 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 53EE221F849A for ; Wed, 31 Oct 2012 06:27:49 -0700 (PDT) Received: (qmail 10839 invoked by uid 0); 31 Oct 2012 13:27:20 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.bluehost.com with SMTP; 31 Oct 2012 13:27:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=0cEqS51R0NaCatjQczgSFJLVJJU1JRxpxHdzWXf7zpM=; b=kshyZ1M+6e6UxXKkiEDppk24oIT97+bKDKOUv9yZkWrv8VAfLendZFWJDNtKiRbSjl8uiPQeqAgPh7lS/E4ufSOcKsCr9x7cGxarGjGBwpv/T0X4vSISc7o3BRSe/RxG; Received: from [71.191.243.130] (port=50735 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TTYKF-0003XV-CE for rtcweb@ietf.org; Wed, 31 Oct 2012 07:27:19 -0600 From: "Richard Shockey" To: References: <509055C4.6060500@nostrum.com> <20121031044328.GP6812@audi.shelbyville.oz> In-Reply-To: Date: Wed, 31 Oct 2012 09:27:16 -0400 Message-ID: <000c01cdb76b$7307d810$59178830$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNtgBjxnCRTWxEdEm8PEWsc927e5fQxgiAgAGrLwCAADRjAIAAMu8AgAAZufCAAHdUsA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 13:27:50 -0000 -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Matthew Kaufman Sent: Wednesday, October 31, 2012 2:26 AM To: Ron; rtcweb@ietf.org Subject: Re: [rtcweb] Form of the video codec question > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Ron > Sent: Wednesday, October 31, 2012 5:43 AM > > Didn't this group form precisely because the hopefully competent > business people have so far only produced a diverse number of > unacceptable solutions and people *really* wanted something better than that? No, I don't believe that was the motivation for forming the RTCWEB working group. > The choice of MTI codec here isn't a commercial decision, it's a technical one. > If we make the right choice, we will ensure the broadest number of > implementors have the option to use it, and the broadest number of > implementations will be interoperable. No, we won't. No matter what this WG decides, people who are not in the room will ultimately make the decision as to what business model they wish to pursue and what business risks they are willing to take... and thus whether or not their implementation will interoperate with others. [RS> ] [RS> ] This is true of any technical/engineering specification. So what's your point. This particular line of objection is fundamentally irrelevant to the topic at hand. Adam is correct. Selecting "whatever you want to do" is not a option. Matthew Kaufman _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From ted.ietf@gmail.com Wed Oct 31 07:21:44 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92AC21F8716 for ; Wed, 31 Oct 2012 07:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIUKyHfj-xhn for ; Wed, 31 Oct 2012 07:21:43 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F012121F87D5 for ; Wed, 31 Oct 2012 07:21:31 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so1756329vbb.31 for ; Wed, 31 Oct 2012 07:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MDMFEUtR/n1vf4p7o4EOtIOoNMO2dhP9UKXCfK01uAw=; b=rGbiLb2NVSJvDU22vu0rMbej/zgLYI/3Jk+Wg2K2D4Usg2Bfj5LEnQ8ItX7soXFcDu FUc1n3yOhNMc5OUqtwV8RGA2XJiKx1WPMa0svszUkEt1iKE83QMJQEZJ1ePJ0nNMqe3r SwxgHbKi7STWL4YL0TeB3+6zGTSrJUgEo+yKdyebjpovFPV1IKETBnRnZJ4JXMy8YlvW uJ/Rsad7mvVsaraJkb/Y69HwjgkRVtCYfSi5kAnMOuL0BqPH06iwk59EgHoz43gV0Srt hfDlpBKfBzAol6FpjeJ0CcyeugoiGQRDXyu38xYWqxZOY3Ze8Y47jGmnA7YK0j3yQFXC 6gJQ== MIME-Version: 1.0 Received: by 10.52.99.103 with SMTP id ep7mr26867946vdb.17.1351693291245; Wed, 31 Oct 2012 07:21:31 -0700 (PDT) Received: by 10.58.164.35 with HTTP; Wed, 31 Oct 2012 07:21:31 -0700 (PDT) In-Reply-To: References: <509055C4.6060500@nostrum.com> <20121031044328.GP6812@audi.shelbyville.oz> Date: Wed, 31 Oct 2012 07:21:31 -0700 Message-ID: From: Ted Hardie To: Matthew Kaufman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 14:21:44 -0000 On Tue, Oct 30, 2012 at 11:26 PM, Matthew Kaufman wrote: > No, we won't. No matter what this WG decides, people who are not in the r= oom will ultimately make the decision as to what business model they wish t= o pursue and what business risks they are willing to take... and thus wheth= er or not their implementation will interoperate with others. Perhaps one way to recast this would be that the working group's decision will affect whether or not an implementation which decides not to interoperate can claim to support WebRTC or not. That may have an impact on the business decision; it may not. As you say, there are other forces. But I believe it is clear that if the working group decides to abandon the effort to achieve interoperability that the chances of the market producing it go down, not up. Speaking personally, neither as chair nor as company representative, Ted Hardie From harald@alvestrand.no Wed Oct 31 08:19:02 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D752221F874E for ; Wed, 31 Oct 2012 08:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yT15-NEUEPIJ for ; Wed, 31 Oct 2012 08:19:02 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD7421F872A for ; Wed, 31 Oct 2012 08:19:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 513A239E129 for ; Wed, 31 Oct 2012 16:18:59 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySqlJ-WirrDC for ; Wed, 31 Oct 2012 16:18:58 +0100 (CET) Received: from [10.216.8.97] (unknown [93.158.40.160]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8033039E062 for ; Wed, 31 Oct 2012 16:18:57 +0100 (CET) Message-ID: <5091415E.4030902@alvestrand.no> Date: Wed, 31 Oct 2012 16:18:54 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 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 Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 15:19:03 -0000 On 10/29/2012 07:51 PM, Stephan Wenger wrote: > Hi Ted, chairs, > > I think these are the wrong questions, as the result of such a poll is not > going to solve anything. It's trivial to predict that there will be a > significant show of hands in favor of each question. What does that tell > you? Asking the questions as presented is going to be a waste of time. > > The more informative questions to as would be: > > 1) Do you object to H.264 as MTI, regardless of its technical and IPR > merits (if any); and > 2) Do you object to VP8 as MTI, regardless of its technical and IPR merits > (if any) > (both in more politically correct formulation, if you want.) Stephan, I would not raise my hand on any of these questions, but would definitely protest a decision made based on the outcome of that question. All my objections to H.264 as MTI are based on its technical and IPR merits. If those change, my opinion may change. However, I believe that my opinion is based enough in facts that it's unlikely that I'll be swayed by a presentation given at the IETF; reading the drafts of the H.264 proponents certainly did not change it. From harald@alvestrand.no Wed Oct 31 08:23:34 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3371C21F8230 for ; Wed, 31 Oct 2012 08:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GK2RPGswRBbd for ; Wed, 31 Oct 2012 08:23:33 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2C021F8206 for ; Wed, 31 Oct 2012 08:23:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9CE2439E129 for ; Wed, 31 Oct 2012 16:23:32 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gk7ilKVZjywG for ; Wed, 31 Oct 2012 16:23:32 +0100 (CET) Received: from [10.216.8.97] (unknown [93.158.40.160]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id C9FEF39E062 for ; Wed, 31 Oct 2012 16:23:31 +0100 (CET) Message-ID: <50914270.9020907@alvestrand.no> Date: Wed, 31 Oct 2012 16:23:28 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <066.ee8d274029b0215df9ff464ea44b5fe7@trac.tools.ietf.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] #1: RFC 4734 citation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 15:23:34 -0000 On 10/30/2012 02:06 PM, Iñaki Baz Castillo wrote: > 2012/10/23 rtcweb issue tracker : >> Telephone Event - [RFC4734] > Could somebody give some points about why DTMFs over media are > required in WWW? Isn't DTMF mechanism OLD enough to incorporate it > into WebRTC? > > Autoanswer: interoperability with legacy telephony world. > Autoanswer (and you should know this by heart now, it's been said so many times): Use case 4.3.2 from draft-ietf-rtcweb-use-cases-and-requirements-09: 4.3.2. Fedex Call 4.3.2.1. Description Alice uses her web browser with a service something like Skype to be able to phone PSTN numbers. Alice calls 1-800-gofedex. Alice should be able to hear the initial prompts from the fedex IVR and when the IVR says press 1, there should be a way for Alice to navigate the IVR. If you want to argue for having that use case deleted from the requirements, start a debate on that topic. If you have an alternative solution, state that in the positive as what should go into the -audio- draft instead of RFC 4734. From matthew.kaufman@skype.net Wed Oct 31 09:25:51 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE9B21F8578 for ; Wed, 31 Oct 2012 09:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIZs2m3D63xd for ; Wed, 31 Oct 2012 09:25:51 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.26]) by ietfa.amsl.com (Postfix) with ESMTP id E6CB021F8567 for ; Wed, 31 Oct 2012 09:25:50 -0700 (PDT) Received: from BL2FFO11FD012.protection.gbl (10.173.161.200) by BL2FFO11HUB016.protection.gbl (10.173.160.108) with Microsoft SMTP Server (TLS) id 15.0.545.8; Wed, 31 Oct 2012 16:25:43 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD012.mail.protection.outlook.com (10.173.161.18) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Wed, 31 Oct 2012 16:25:43 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.52]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Wed, 31 Oct 2012 16:25:15 +0000 From: Matthew Kaufman To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Form of the video codec question Thread-Index: AQHNtgBjxnCRTWxEdEm8PEWsc927e5fQoN4AgALpNQCAABFhUA== Date: Wed, 31 Oct 2012 16:25:15 +0000 Message-ID: References: <5091415E.4030902@alvestrand.no> In-Reply-To: <5091415E.4030902@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(47736001)(48376001)(50986001)(4396001)(49866001)(44976002)(50466001)(53806001)(47976001)(54356001)(47776002)(74662001)(47446002)(54316001)(31966008)(46102001)(16406001)(74502001)(51856001)(33656001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 06515DA04B Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 16:25:51 -0000 Harald Alvestrand: > > However, I believe that my opinion is based enough in facts that it's unl= ikely > that I'll be swayed by a presentation given at the IETF; reading the draf= ts of > the H.264 proponents certainly did not change it. > Perfect. If everyone can read the drafts ahead of time and make up their mi= nd then we can spend valuable face-to-face time on the existing issues plus= the three (or more) new items that are coming out of W3C this week instead= of on the predetermined codec discussion. Matthew Kaufman From ibc@aliax.net Wed Oct 31 10:13:05 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F02321F864A for ; Wed, 31 Oct 2012 10:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NsCc5xmGpLT for ; Wed, 31 Oct 2012 10:13:04 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3661B21F861C for ; Wed, 31 Oct 2012 10:13:04 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so1360538lbo.31 for ; Wed, 31 Oct 2012 10:13:03 -0700 (PDT) X-Google-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:x-gm-message-state; bh=LJ+GWzEwli+r4pQzqqBEnZTa952T3JeOS5O1/vQ2uoA=; b=QF3lw0x3X5hWn1ZOLwTrgkO36QwdCMex7tBBe77/Fsithu4pwoYAZJR8SFy5IIAhle llWNKco9KNzPd5SgY8+CVLtzZO/TiML8II7VIITlqahPbhscnXYikkd0J4O4GXwLmGj+ 60HDXV92gLnj/2BUlZGUkc7Bbl1TAbc5jwWDulw+U7HbjfCxBrQG80+24mjS9ABrcqCC s2fVNcggbOFzOU20zSPfPob2sYFC99z1yj9Ub85Pq19MB5YjWTo+ofLOIAUFHtYJ67zi qscJqArKSOkxN3P9T3zHOaj7zfa5XOdOqS7jRX3bF9kzItmqRdY0RKMAQyTrDgnagElZ ounQ== Received: by 10.152.109.145 with SMTP id hs17mr34749626lab.5.1351703583205; Wed, 31 Oct 2012 10:13:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Wed, 31 Oct 2012 10:12:43 -0700 (PDT) In-Reply-To: <50914270.9020907@alvestrand.no> References: <066.ee8d274029b0215df9ff464ea44b5fe7@trac.tools.ietf.org> <50914270.9020907@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 31 Oct 2012 18:12:43 +0100 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=bcaec54ee77ceb279804cd5e0344 X-Gm-Message-State: ALoCoQkQVIWQOL7mLuddkDCItOdXcSpTp2IAOiXJLb1lHlXZW3Xa8aZ++vQ0eb9n4lsdDm7m74Be Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] #1: RFC 4734 citation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 17:13:05 -0000 --bcaec54ee77ceb279804cd5e0344 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2012/10/31 Harald Alvestrand > On 10/30/2012 02:06 PM, I=C3=B1aki Baz Castillo wrote: > >> 2012/10/23 rtcweb issue tracker >> >: >> >>> Telephone Event - [RFC4734] >>> >> Could somebody give some points about why DTMFs over media are >> required in WWW? Isn't DTMF mechanism OLD enough to incorporate it >> into WebRTC? >> >> Autoanswer: interoperability with legacy telephony world. >> >> Autoanswer (and you should know this by heart now, it's been said so > many times): > > Use case 4.3.2 from draft-ietf-rtcweb-use-cases-**and-requirements-09: > > 4.3.2. Fedex Call > > 4.3.2.1. Description > > Alice uses her web browser with a service something like Skype to be > able to phone PSTN numbers. Alice calls 1-800-gofedex. Alice should > be able to hear the initial prompts from the fedex IVR and when the > IVR says press 1, there should be a way for Alice to navigate the > IVR. > > If you want to argue for having that use case deleted from the > requirements, start a debate on that topic. If you have an alternative > solution, state that in the positive as what should go into the -audio- > draft instead of RFC 4734. Well, as we all assume that media gateways are requried for interoperability with other VoIP networks, I assume it would be not so hard that the gateway receives the "DTMF's" via WWW means (HTTP, WebSocket...) and generates RTP DTMF's in the legacy leg. Anyhow I expect that it's not so hard to implement RTP DTMF's in a media stack, but I would not like to hear about "my PBX's does not detect Chrome's DTMF's". :) --=20 I=C3=B1aki Baz Castillo --bcaec54ee77ceb279804cd5e0344 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2012/10/31 Harald Alvestrand <harald@alvestrand.no>
On 10/30/2012 02:06 PM, I=C3=B1aki Baz Castillo wrote:
2012/10/23 rtcweb issue tracker <trac+rtcweb@trac.tools.ietf.org&= gt;:
=C2=A0 Telephone Event - [RFC4734]
Could somebody give some points about why DTMFs over media are
required in WWW? Isn't DTMF mechanism OLD enough to incorporate it
into WebRTC?

Autoanswer: interoperability with legacy telephony world.

Autoanswer (and you should know this by heart now, it's been said so ma= ny times):

Use case 4.3.2 from draft-ietf-rtcweb-use-cases-and-requirements-09:=

4.3.2. =C2=A0Fedex Call

4.3.2.1. =C2=A0Description

=C2=A0 =C2=A0Alice uses her web browser with a service something like Skype= to be
=C2=A0 =C2=A0able to phone PSTN numbers. =C2=A0Alice calls 1-800-gofedex. = =C2=A0Alice should
=C2=A0 =C2=A0be able to hear the initial prompts from the fedex IVR and whe= n the
=C2=A0 =C2=A0IVR says press 1, there should be a way for Alice to navigate = the
=C2=A0 =C2=A0IVR.

If you want to argue for having that use case deleted from the requirements= , start a debate on that topic. If you have an alternative solution, state = that in the positive as what should go into the -audio- draft instead of RF= C 4734.


Well, as we all assume that media gatewa= ys are requried for interoperability with other VoIP networks, I assume it = would be not so hard that the gateway receives the "DTMF's" v= ia WWW means (HTTP, WebSocket...) and generates RTP DTMF's in the legac= y leg.

Anyhow I expect that it's not so hard to implement = RTP DTMF's in a media stack, but I would not like to hear about "m= y PBX's does not detect Chrome's DTMF's". :)


--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>
--bcaec54ee77ceb279804cd5e0344-- From bernard_aboba@hotmail.com Wed Oct 31 10:19:25 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3A921F878A for ; Wed, 31 Oct 2012 10:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNDkqCiY5SDa for ; Wed, 31 Oct 2012 10:19:24 -0700 (PDT) Received: from blu0-omc3-s31.blu0.hotmail.com (blu0-omc3-s31.blu0.hotmail.com [65.55.116.106]) by ietfa.amsl.com (Postfix) with ESMTP id ADF6621F8780 for ; Wed, 31 Oct 2012 10:19:24 -0700 (PDT) Received: from BLU404-EAS295 ([65.55.116.72]) by blu0-omc3-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 31 Oct 2012 10:19:23 -0700 X-Originating-IP: [72.11.69.66] X-EIP: [jpOVuc/2TjieYR5ksXF0syHXrf8yTZFT] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 References: <066.ee8d274029b0215df9ff464ea44b5fe7@trac.tools.ietf.org> <50914270.9020907@alvestrand.no> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <50914270.9020907@alvestrand.no> Date: Wed, 31 Oct 2012 10:20:46 -0700 To: Harald Alvestrand X-OriginalArrivalTime: 31 Oct 2012 17:19:23.0895 (UTC) FILETIME=[DF56B070:01CDB78B] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] #1: RFC 4734 citation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 17:19:25 -0000 UkZDIDQ3MzQgcmVsYXRlcyB0byBtb2RlbSBhbmQgZmF4IGV2ZW50cywgbm90IERUTUYuIGNpdGF0 aW9uIHNob3VsZCBoYXZlIGJlZW4gdG8gNDczMy4gDQoNCk9uIE9jdCAzMSwgMjAxMiwgYXQgODoy MywgIkhhcmFsZCBBbHZlc3RyYW5kIiA8aGFyYWxkQGFsdmVzdHJhbmQubm8+IHdyb3RlOg0KDQo+ IE9uIDEwLzMwLzIwMTIgMDI6MDYgUE0sIEnDsWFraSBCYXogQ2FzdGlsbG8gd3JvdGU6DQo+PiAy MDEyLzEwLzIzIHJ0Y3dlYiBpc3N1ZSB0cmFja2VyIDx0cmFjK3J0Y3dlYkB0cmFjLnRvb2xzLmll dGYub3JnPjoNCj4+PiAgVGVsZXBob25lIEV2ZW50IC0gW1JGQzQ3MzRdDQo+PiBDb3VsZCBzb21l Ym9keSBnaXZlIHNvbWUgcG9pbnRzIGFib3V0IHdoeSBEVE1GcyBvdmVyIG1lZGlhIGFyZQ0KPj4g cmVxdWlyZWQgaW4gV1dXPyBJc24ndCBEVE1GIG1lY2hhbmlzbSBPTEQgZW5vdWdoIHRvIGluY29y cG9yYXRlIGl0DQo+PiBpbnRvIFdlYlJUQz8NCj4+IA0KPj4gQXV0b2Fuc3dlcjogaW50ZXJvcGVy YWJpbGl0eSB3aXRoIGxlZ2FjeSB0ZWxlcGhvbnkgd29ybGQuDQo+IEF1dG9hbnN3ZXIgKGFuZCB5 b3Ugc2hvdWxkIGtub3cgdGhpcyBieSBoZWFydCBub3csIGl0J3MgYmVlbiBzYWlkIHNvIG1hbnkg dGltZXMpOg0KPiANCj4gVXNlIGNhc2UgNC4zLjIgZnJvbSBkcmFmdC1pZXRmLXJ0Y3dlYi11c2Ut Y2FzZXMtYW5kLXJlcXVpcmVtZW50cy0wOToNCj4gDQo+IDQuMy4yLiAgRmVkZXggQ2FsbA0KPiAN Cj4gNC4zLjIuMS4gIERlc2NyaXB0aW9uDQo+IA0KPiAgIEFsaWNlIHVzZXMgaGVyIHdlYiBicm93 c2VyIHdpdGggYSBzZXJ2aWNlIHNvbWV0aGluZyBsaWtlIFNreXBlIHRvIGJlDQo+ICAgYWJsZSB0 byBwaG9uZSBQU1ROIG51bWJlcnMuICBBbGljZSBjYWxscyAxLTgwMC1nb2ZlZGV4LiAgQWxpY2Ug c2hvdWxkDQo+ICAgYmUgYWJsZSB0byBoZWFyIHRoZSBpbml0aWFsIHByb21wdHMgZnJvbSB0aGUg ZmVkZXggSVZSIGFuZCB3aGVuIHRoZQ0KPiAgIElWUiBzYXlzIHByZXNzIDEsIHRoZXJlIHNob3Vs ZCBiZSBhIHdheSBmb3IgQWxpY2UgdG8gbmF2aWdhdGUgdGhlDQo+ICAgSVZSLg0KPiANCj4gSWYg eW91IHdhbnQgdG8gYXJndWUgZm9yIGhhdmluZyB0aGF0IHVzZSBjYXNlIGRlbGV0ZWQgZnJvbSB0 aGUgcmVxdWlyZW1lbnRzLCBzdGFydCBhIGRlYmF0ZSBvbiB0aGF0IHRvcGljLiBJZiB5b3UgaGF2 ZSBhbiBhbHRlcm5hdGl2ZSBzb2x1dGlvbiwgc3RhdGUgdGhhdCBpbiB0aGUgcG9zaXRpdmUgYXMg d2hhdCBzaG91bGQgZ28gaW50byB0aGUgLWF1ZGlvLSBkcmFmdCBpbnN0ZWFkIG9mIFJGQyA0NzM0 Lg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBy dGN3ZWIgbWFpbGluZyBsaXN0DQo+IHJ0Y3dlYkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0K From roman@telurix.com Wed Oct 31 10:41:49 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F1921F8854 for ; Wed, 31 Oct 2012 10:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gf5bp-blTXX for ; Wed, 31 Oct 2012 10:41:48 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D9F2521F8872 for ; Wed, 31 Oct 2012 10:41:48 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so1147918pbb.31 for ; Wed, 31 Oct 2012 10:41:48 -0700 (PDT) X-Google-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:x-gm-message-state; bh=8R+hselR587fO7QkADKLSa9A1S367bAJDGpwDxe1zJ8=; b=cDcX42Jlf+YjhVzUJaOitL24mZIJ8qer13ZjW0FsX4wSTlSrSeQIqvP45J9MB5yE/e mpz0AG2biiujVqYCPQULiCGJwGAlfFCLhO0VtaaNS4jZhBur74OK2QSM/n33tup6E0Ts NwAL6VwUraVqQSbSeSImJs/1+emDbgfSISqwZrusBlyMQY+jbh3wS8Gyv2L/8olcp/i7 GuImKKQtV4+rqx0KcC0vz40Dsh0J4bffX4lM6NmLsK2oIRjbssXaCe7wL8APrePbWZPO /Ew8Dyj+HMgU722/XZ2hL+C4oMkr9+zxNduChIUWLxywylE+YsJdrR0MT4zvfEjCiy50 KVpg== Received: by 10.68.235.71 with SMTP id uk7mr115450461pbc.10.1351705308417; Wed, 31 Oct 2012 10:41:48 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by mx.google.com with ESMTPS id qj6sm2591153pbb.69.2012.10.31.10.41.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 31 Oct 2012 10:41:47 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so1135487pad.31 for ; Wed, 31 Oct 2012 10:41:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.218.132 with SMTP id pg4mr115657493pbc.100.1351705306959; Wed, 31 Oct 2012 10:41:46 -0700 (PDT) Received: by 10.68.42.8 with HTTP; Wed, 31 Oct 2012 10:41:46 -0700 (PDT) In-Reply-To: References: <066.ee8d274029b0215df9ff464ea44b5fe7@trac.tools.ietf.org> <50914270.9020907@alvestrand.no> Date: Wed, 31 Oct 2012 13:41:46 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=e89a8ffbaaf5a990ee04cd5e6aac X-Gm-Message-State: ALoCoQlu5qdVLO2X4OLBnxQQi+5OSN3zEfVwhhbftkkpdW8Cp8N8iLpjxAm1LOi9/5hOD1+gocRj Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] #1: RFC 4734 citation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 17:41:49 -0000 --e89a8ffbaaf5a990ee04cd5e6aac Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 31, 2012 at 1:12 PM, I=F1aki Baz Castillo wrote= : > Well, as we all assume that media gateways are requried for > interoperability with other VoIP networks, I assume it would be not so ha= rd > that the gateway receives the "DTMF's" via WWW means (HTTP, WebSocket...) > and generates RTP DTMF's in the legacy leg. > > Anyhow I expect that it's not so hard to implement RTP DTMF's in a media > stack, but I would not like to hear about "my PBX's does not detect > Chrome's DTMF's". :) > We had an extensive discussion few months back on why RFC 4733 tones are required. The main reason is time synchronization of audio and DTMF. If you have an application which does something like "record your name and press pound", and DTMF is delivered over a separate path, you end up with name either truncated or padded with silence. In any case, I believe, there was a group consensus that RFC 4733 DTMF tones will be supported. _____________ Roman Shpount --e89a8ffbaaf5a990ee04cd5e6aac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 31, 2012 at 1:12 PM, I=F1aki Baz Castillo <ibc@a= liax.net> wrote:
Well, as we all = assume that media gateways are requried for interoperability with other VoI= P networks, I assume it would be not so hard that the gateway receives the = "DTMF's" via WWW means (HTTP, WebSocket...) and generates RTP= DTMF's in the legacy leg.

Anyhow I expect that it's not so hard to implement = RTP DTMF's in a media stack, but I would not like to hear about "m= y PBX's does not detect Chrome's DTMF's". :)

We had an extensive discussion few m= onths back on why RFC 4733 tones are required. The main reason is time=A0sy= nchronization=A0of audio and DTMF. If you have an application which does so= mething like "record your name and press pound", and DTMF is deli= vered over a separate path, you end up with name either truncated or padded= with silence. In any case, I believe, there was a group consensus that=A0R= FC 4733 DTMF tones will be supported.
_____________
Roman Shpount
=A0

--e89a8ffbaaf5a990ee04cd5e6aac-- From bernard_aboba@hotmail.com Wed Oct 31 10:48:53 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7D121F87E5 for ; Wed, 31 Oct 2012 10:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuBFI++UdNzq for ; Wed, 31 Oct 2012 10:48:52 -0700 (PDT) Received: from blu0-omc2-s18.blu0.hotmail.com (blu0-omc2-s18.blu0.hotmail.com [65.55.111.93]) by ietfa.amsl.com (Postfix) with ESMTP id 561BB21F87E9 for ; Wed, 31 Oct 2012 10:48:52 -0700 (PDT) Received: from BLU404-EAS228 ([65.55.111.72]) by blu0-omc2-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 31 Oct 2012 10:48:51 -0700 X-Originating-IP: [166.147.81.62] X-EIP: [JljaNkB/lTcqFlx59y+CWGAQhIO0oTXj] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/related; boundary="_f0aa9e85-0942-4327-8349-6e6d5d799997_" References: <066.ee8d274029b0215df9ff464ea44b5fe7@trac.tools.ietf.org> <50914270.9020907@alvestrand.no> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: Date: Wed, 31 Oct 2012 10:48:43 -0700 To: Roman Shpount X-OriginalArrivalTime: 31 Oct 2012 17:48:51.0707 (UTC) FILETIME=[FD0964B0:01CDB78F] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] #1: RFC 4734 citation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 17:48:53 -0000 --_f0aa9e85-0942-4327-8349-6e6d5d799997_ Content-Type: multipart/alternative; boundary="Apple-Mail-E0A393A5-E047-4B08-BAD0-52F9002E971B" Content-Transfer-Encoding: 7bit --Apple-Mail-E0A393A5-E047-4B08-BAD0-52F9002E971B Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmlnaHQuIEJ1dCBzb21laG93IFJGQyA0NzM0IHdhcyBjaXRlZCBpbnN0ZWFkLg0KDQpPbiBPY3Qg MzEsIDIwMTIsIGF0IDEwOjQxIEFNLCAiUm9tYW4gU2hwb3VudCIgPHJvbWFuQHRlbHVyaXguY29t PiB3cm90ZToNCg0KPiANCj4gT24gV2VkLCBPY3QgMzEsIDIwMTIgYXQgMToxMiBQTSwgScOxYWtp IEJheiBDYXN0aWxsbyA8aWJjQGFsaWF4Lm5ldD4gd3JvdGU6DQo+PiBXZWxsLCBhcyB3ZSBhbGwg YXNzdW1lIHRoYXQgbWVkaWEgZ2F0ZXdheXMgYXJlIHJlcXVyaWVkIGZvciBpbnRlcm9wZXJhYmls aXR5IHdpdGggb3RoZXIgVm9JUCBuZXR3b3JrcywgSSBhc3N1bWUgaXQgd291bGQgYmUgbm90IHNv IGhhcmQgdGhhdCB0aGUgZ2F0ZXdheSByZWNlaXZlcyB0aGUgIkRUTUYncyIgdmlhIFdXVyBtZWFu cyAoSFRUUCwgV2ViU29ja2V0Li4uKSBhbmQgZ2VuZXJhdGVzIFJUUCBEVE1GJ3MgaW4gdGhlIGxl Z2FjeSBsZWcuDQo+PiANCj4+IEFueWhvdyBJIGV4cGVjdCB0aGF0IGl0J3Mgbm90IHNvIGhhcmQg dG8gaW1wbGVtZW50IFJUUCBEVE1GJ3MgaW4gYSBtZWRpYSBzdGFjaywgYnV0IEkgd291bGQgbm90 IGxpa2UgdG8gaGVhciBhYm91dCAibXkgUEJYJ3MgZG9lcyBub3QgZGV0ZWN0IENocm9tZSdzIERU TUYncyIuIDopDQo+IA0KPiBXZSBoYWQgYW4gZXh0ZW5zaXZlIGRpc2N1c3Npb24gZmV3IG1vbnRo cyBiYWNrIG9uIHdoeSBSRkMgNDczMyB0b25lcyBhcmUgcmVxdWlyZWQuIFRoZSBtYWluIHJlYXNv biBpcyB0aW1lIHN5bmNocm9uaXphdGlvbiBvZiBhdWRpbyBhbmQgRFRNRi4gSWYgeW91IGhhdmUg YW4gYXBwbGljYXRpb24gd2hpY2ggZG9lcyBzb21ldGhpbmcgbGlrZSAicmVjb3JkIHlvdXIgbmFt ZSBhbmQgcHJlc3MgcG91bmQiLCBhbmQgRFRNRiBpcyBkZWxpdmVyZWQgb3ZlciBhIHNlcGFyYXRl IHBhdGgsIHlvdSBlbmQgdXAgd2l0aCBuYW1lIGVpdGhlciB0cnVuY2F0ZWQgb3IgcGFkZGVkIHdp dGggc2lsZW5jZS4gSW4gYW55IGNhc2UsIEkgYmVsaWV2ZSwgdGhlcmUgd2FzIGEgZ3JvdXAgY29u c2Vuc3VzIHRoYXQgUkZDIDQ3MzMgRFRNRiB0b25lcyB3aWxsIGJlIHN1cHBvcnRlZC4NCj4gX19f X19fX19fX19fXw0KPiBSb21hbiBTaHBvdW50DQo+ICANCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4g cnRjd2ViQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cnRjd2ViDQo= --Apple-Mail-E0A393A5-E047-4B08-BAD0-52F9002E971B Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+UmlnaHQu IEJ1dCBzb21laG93IFJGQyA0NzM0IHdhcyBjaXRlZCBpbnN0ZWFkLjxicj48YnI+T24gT2N0IDMx LCAyMDEyLCBhdCAxMDo0MSBBTSwgIlJvbWFuIFNocG91bnQiICZsdDs8YSBocmVmPSJtYWlsdG86 cm9tYW5AdGVsdXJpeC5jb20iPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDsgd3JvdGU6PGJyPjxi cj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxiciBjbGVhcj0iYWxsIj5PbiBX ZWQsIE9jdCAzMSwgMjAxMiBhdCAxOjEyIFBNLCBJw7Fha2kgQmF6IENhc3RpbGxvIDxzcGFuIGRp cj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmliY0BhbGlheC5uZXQiIHRhcmdldD0iX2JsYW5r Ij5pYmNAYWxpYXgubmV0PC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj48ZGl2IGNsYXNzPSJnbWFp bF9xdW90ZSI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAg MCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxkaXY+V2Vs bCwgYXMgd2UgYWxsIGFzc3VtZSB0aGF0IG1lZGlhIGdhdGV3YXlzIGFyZSByZXF1cmllZCBmb3Ig aW50ZXJvcGVyYWJpbGl0eSB3aXRoIG90aGVyIFZvSVAgbmV0d29ya3MsIEkgYXNzdW1lIGl0IHdv dWxkIGJlIG5vdCBzbyBoYXJkIHRoYXQgdGhlIGdhdGV3YXkgcmVjZWl2ZXMgdGhlICJEVE1GJ3Mi IHZpYSBXV1cgbWVhbnMgKEhUVFAsIFdlYlNvY2tldC4uLikgYW5kIGdlbmVyYXRlcyBSVFAgRFRN RidzIGluIHRoZSBsZWdhY3kgbGVnLjwvZGl2Pg0KDQoNCjxkaXY+PGJyPjwvZGl2PjxkaXY+QW55 aG93IEkgZXhwZWN0IHRoYXQgaXQncyBub3Qgc28gaGFyZCB0byBpbXBsZW1lbnQgUlRQIERUTUYn cyBpbiBhIG1lZGlhIHN0YWNrLCBidXQgSSB3b3VsZCBub3QgbGlrZSB0byBoZWFyIGFib3V0ICJt eSBQQlgncyBkb2VzIG5vdCBkZXRlY3QgQ2hyb21lJ3MgRFRNRidzIi4gOik8L2Rpdj48L2Rpdj4N CjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2PldlIGhhZCBhbiBleHRlbnNp dmUgZGlzY3Vzc2lvbiBmZXcgbW9udGhzIGJhY2sgb24gd2h5IFJGQyA0NzMzIHRvbmVzIGFyZSBy ZXF1aXJlZC4gVGhlIG1haW4gcmVhc29uIGlzIHRpbWUmbmJzcDtzeW5jaHJvbml6YXRpb24mbmJz cDtvZiBhdWRpbyBhbmQgRFRNRi4gSWYgeW91IGhhdmUgYW4gYXBwbGljYXRpb24gd2hpY2ggZG9l cyBzb21ldGhpbmcgbGlrZSAicmVjb3JkIHlvdXIgbmFtZSBhbmQgcHJlc3MgcG91bmQiLCBhbmQg RFRNRiBpcyBkZWxpdmVyZWQgb3ZlciBhIHNlcGFyYXRlIHBhdGgsIHlvdSBlbmQgdXAgd2l0aCBu YW1lIGVpdGhlciB0cnVuY2F0ZWQgb3IgcGFkZGVkIHdpdGggc2lsZW5jZS4gSW4gYW55IGNhc2Us IEkgYmVsaWV2ZSwgdGhlcmUgd2FzIGEgZ3JvdXAgY29uc2Vuc3VzIHRoYXQmbmJzcDtSRkMgNDcz MyBEVE1GIHRvbmVzIHdpbGwgYmUgc3VwcG9ydGVkLjwvZGl2Pg0KX19fX19fX19fX19fXzxicj5S b21hbiBTaHBvdW50PGJyPjxkaXY+Jm5ic3A7PC9kaXY+PC9kaXY+PGJyPg0KPC9kaXY+PC9ibG9j a3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PHNwYW4+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPjxzcGFuPnJ0Y3dlYiBt YWlsaW5nIGxpc3Q8L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5v cmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT48L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48L3NwYW4+PGJyPjwvZGl2PjwvYmxvY2txdW90 ZT48L2JvZHk+PC9odG1sPg== --Apple-Mail-E0A393A5-E047-4B08-BAD0-52F9002E971B-- --_f0aa9e85-0942-4327-8349-6e6d5d799997_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_f0aa9e85-0942-4327-8349-6e6d5d799997_-- From andrew.hutton@siemens-enterprise.com Wed Oct 31 15:39:09 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED93021F87BB for ; Wed, 31 Oct 2012 15:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRQG5dokYxz8 for ; Wed, 31 Oct 2012 15:39:09 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9642C21F87A9 for ; Wed, 31 Oct 2012 15:39:08 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 2684B23F05E6; Wed, 31 Oct 2012 23:39:07 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.76]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 23:38:55 +0100 From: "Hutton, Andrew" To: "rtcweb@ietf.org" , Cullen Jennings , "juberti@google.com" Thread-Topic: Comments on draft-ietf-rtcweb-jsep-02 Thread-Index: Ac23uIGvdmGIkB3RTWqxDYM5U5hRtQ== Date: Wed, 31 Oct 2012 22:38:55 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0131E1E3@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 Subject: [rtcweb] Comments on draft-ietf-rtcweb-jsep-02 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 22:39:10 -0000 SGksIA0KDQpJIGhhdmUgcmVhZCB0aHJvdWdoIHRoZSBsYXRlc3QganNlcC0wMiBkcmFmdCBhbmQg aGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRzL3F1ZXN0aW9ucy4NCg0KDQoxLiBTZWN0aW9uIDEg SW50cm9kdWN0aW9uIA0KDQpUaGUgaW50cm9kdWN0aW9uIG1ha2VzIHZhcmlvdXMgcmVmZXJlbmNl cyB0byBvZmZlci9hbnN3ZXIgYnV0IGRvZXMgbm90IG1lbnRpb24gUkZDIDMyNjQuICBJdCBuZWVk cyBzdWNoIGEgcmVmZXJlbmNlIGFuZCB0byBleHBsYWluIHRoZSByZWxldmFuY2Ugb2YgUkZDIDMy NjQgYW5kIGhvdyBKU0VQIHByb3ZpZGVzIHRoZSB0b29scyB0byBpbXBsZW1lbnQgYSBSRkMgMzI2 NCBjb25mb3JtYW50IGFwcGxpY2F0aW9uIGJ1dCBkb2VzIG5vdCBpdHNlbGYgaW1wbGVtZW50IFJG QyAzMjY0Lg0KDQoNCjIuIFNlY3Rpb24gMSBJbnRyb2R1Y3Rpb24gMm5kIFBhcmEgc3RhdGVzOg0K DQoiVGhlIGJyb3dzZXIgZW52aXJvbm1lbnQgYWxzbyBoYXMgaXRzIG93biBjaGFsbGVuZ2VzIHRo YXQgY2F1c2UgcHJvYmxlbXMgZm9yIGFuIGVtYmVkZGVkIHNpZ25hbGluZyBzdGF0ZSBtYWNoaW5l LiAgT25lIG9mIHRoZXNlIGlzIHRoYXQgdGhlIHVzZXIgbWF5IHJlbG9hZCB0aGUgd2ViIHBhZ2Ug YXQgYW55IHRpbWUuICBJZiB0aGlzIGhhcHBlbnMsIGFuZCB0aGUgc3RhdGUgbWFjaGluZSBpcyBi ZWluZyBydW4gYXQgYSBzZXJ2ZXIsIHRoZSBzZXJ2ZXIgY2FuIHNpbXBseSBwdXNoIHRoZSBjdXJy ZW50IHN0YXRlIGJhY2sgZG93biB0byB0aGUgcGFnZSBhbmQgcmVzdW1lIHRoZSBjYWxsIHdoZXJl IGl0IGxlZnQgb2ZmIi4NCg0KVGhlIGxhc3Qgc2VudGVuY2UgaXMgYW4gb3ZlciBzaW1wbGlmaWNh dGlvbiBhcyB0aGVyZSBhcmUgcHJvYmxlbXMgd2l0aCByZWdhcmQgdG8gcmVoeWRyYXRpb24gZXZl biB3aGVuIHRoZSBzaWduYWxpbmcgc3RhdGUgbWFjaGluZSBpcyBydW4gYXQgdGhlIHNlcnZlci4g QWxzbyB0aGUgc2VudGVuY2UgcmVmZXJzIHRvIHR3byBkaWZmZXJlbnQgdHlwZXMgb2Ygc3RhdGUg YXMgaXQgaXMgbm90IHRoZSBzaWduYWxpbmcgc3RhdGUgdGhhdCBpcyBwdXNoZWQgYmFjayB0byB0 aGUgYnJvd3Nlci4gIEkgc3VnZ2VzdCByZW1vdmluZyB0aGUgbGFzdCBzZW50ZW5jZSBvciByZWZl cnJpbmcgdG8gdGhlIHNlY3Rpb24gb24gaHlkcmF0aW9uLiANCg0KDQozLiBTZWN0aW9uIDEuIElu dHJvZHVjdGlvbiA3dGggUGFyYSBzdGF0ZXM6DQoNCiJUaGUgSlNFUCBhcHByb2FjaCBkb2VzIGNv bWUgd2l0aCBhIG1pbm9yIGRvd25zaWRlLiAgQXMgdGhlIGFwcGxpY2F0aW9uIG5vdyBpcyByZXNw b25zaWJsZSBmb3IgZHJpdmluZyB0aGUgc2lnbmFsaW5nIHN0YXRlICBtYWNoaW5lLCBzbGlnaHRs eSBtb3JlIGFwcGxpY2F0aW9uIGNvZGUgaXMgbmVjZXNzYXJ5IHRvIHBlcmZvcm0gY2FsbCBzZXR1 cDsgdGhlIGFwcGxpY2F0aW9uIG11c3QgY2FsbCB0aGUgcmlnaHQgQVBJcyBhdCB0aGUgcmlnaHQg dGltZXMsIGFuZCBjb252ZXJ0IHRoZSBzZXNzaW9uIGRlc2NyaXB0aW9ucyBhbmQgSUNFIGluZm9y bWF0aW9uIGludG8gdGhlICBkZWZpbmVkIG1lc3NhZ2VzIG9mIGl0cyBjaG9zZW4gc2lnbmFsaW5n IHByb3RvY29sLCBpbnN0ZWFkIG9mIHNpbXBseSBmb3J3YXJkaW5nIHRoZSBtZXNzYWdlcyBlbWl0 dGVkIGZyb20gdGhlIGJyb3dzZXIuIg0KDQpZZXMgYnV0IG1heWJlIHRoZSBpbnRyb2R1Y3Rpb24g c2hvdWxkIGV4cGxhaW4gdGhhdCB0aGUgQVBJIHdpbGwgcHJvdmlkZSB2YWxpZCBTRFAgdGhhdCBh biBhcHBsaWNhdGlvbiBjb3VsZCB1c2Ugd2l0aGluIGEgUkZDIDMyNjQgYmFzZWQgcHJvdG9jb2wg d2l0aG91dCB0aGUgYXBwbGljYXRpb24gbmVlZGluZyB0byB1bmRlcnN0YW5kIHRoZSBzeW50YXgg b2YgU0RQLg0KDQoNCjQuIFNlY3Rpb24gMS4gSW50b2R1Y3Rpb24gOHRoIFBhcmEgc3RhdGVzOg0K DQoiRm9yIGV4YW1wbGUsIHRoaXMgbGlicmFyeSBjb3VsZCBjb252ZXJ0IGVhc2lseSBhZGFwdCB0 aGUgSlNFUCBBUEkuLi4iDQoNClJlbW92ZSAiY29udmVydCIuDQoNCg0KNS4gU2VjdGlvbiA0LjEu IFNpZ25hbGluZyBtb2RlbCAxc3QgUGFyYSBzdGF0ZXM6DQoNCiJKU0VQIGRvZXMgbm90IHNwZWNp ZnkgYSBwYXJ0aWN1bGFyIHNpZ25hbGluZyBtb2RlbCBvciBzdGF0ZSBtYWNoaW5lLCBvdGhlciB0 aGFuIHRoZSBnZW5lcmljIG5lZWQgdG8gZXhjaGFuZ2UgUkZDIDMyNjQgb2ZmZXJzIGFuZCBhbnN3 ZXJzIGluIG9yZGVyIGZvciBib3RoIHNpZGVzIG9mIHRoZSBzZXNzaW9uIHRvIGtub3cgaG93IHRv IGNvbmR1Y3QgdGhlIHNlc3Npb24iLg0KDQpJIHRoaW5rIHRoaXMgbmVlZHMgcmV3b3JkaW5nIGFu ZCBzdWdnZXN0IHRoZSBmb2xsb3dpbmcg4oCcSlNFUCBkb2VzIG5vdCBzcGVjaWZ5IGEgcGFydGlj dWxhciBzaWduYWxpbmcgbW9kZWwgb3Igc2lnbmFsbGluZyBzdGF0ZSBtYWNoaW5lLiBKU0VQIHBy b3ZpZGVzIHRoZSBtZWFucyBmb3IgYW4gYXBwbGljYXRpb24gdG8gYnVpbGQgYSBzaWduYWxpbmcg c3RhdGUgbWFjaGluZSB3aGljaCBjb21wbGllcyB3aXRoIHRoZSByZXF1aXJlbWVudHMgZm9yIG9m ZmVyL2Fuc3dlcnMgYXMgc3BlY2lmaWVkIGluIFJGQyAzMjY0Ii4gIFRoaXMgZW1waGFzaXNlcyB0 aGF0IEpTRVAgaXMgcmVxdWlyZWQgdG8gcHJvdmlkZSB0aGUgdG9vbHMgdG8gZW5hYmxlIGNvbmZv cm1hbmNlIHRvIDMyNjQgZXZlbiBpZiBpdCBhbGxvd3Mgc29tZSBmbGV4aWJpbGl0eSB0byBkaXZl cmdlIGZyb20gMzI2NC4NCg0KDQo2LiBTZWN0aW9uIDQuMi4gU2Vzc2lvbiBEZXNjcmlwdGlvbnMg YW5kIFN0YXRlIE1hY2hpbmUgc3RhdGVzOg0KDQoiTGFzdGx5LCB3aGlsZSB0aGUgZXhhY3QgbWVk aWEgcGFyYW1ldGVycyBhcmUgb25seSBrbm93biBvbmx5IGFmdGVyIGEgb2ZmZXIgYW5kIGFuIGFu c3dlciBoYXZlIGJlZW4gZXhjaGFuZ2VkLCBpdCBpcyBwb3NzaWJsZSBmb3IgdGhlIG9mZmVyZXIg dG8gcmVjZWl2ZSBtZWRpYSBhZnRlciB0aGV5IGhhdmUgc2VudCBhbiBvZmZlciBhbmQgYmVmb3Jl IHRoZXkgaGF2ZSByZWNlaXZlZCBhbiBhbnN3ZXIuIFRvIHByb3Blcmx5IHByb2Nlc3MgaW5jb21p bmcgbWVkaWEgaW4gdGhpcyBjYXNlLCB0aGUgb2ZmZXJlcidzIG1lZGlhIGhhbmRsZXIgbXVzdCBi ZSBhd2FyZSBvZiB0aGUgZGV0YWlscyBvZiB0aGUgb2ZmZXJlciBiZWZvcmUgdGhlIGFuc3dlciBh cnJpdmVzLiINCg0KSSBkb24ndCBzZWUgdGhlIHJlbGV2YW5jZSBvZiB0aGUgc3RhdGVtZW50ICJp dCBpcyBwb3NzaWJsZSBmb3IgdGhlIG9mZmVyZXIgdG8gcmVjZWl2ZSBtZWRpYSBhZnRlciB0aGV5 IGhhdmUgc2VudCBhbiBvZmZlciBhbmQgYmVmb3JlIHRoZXkgaGF2ZSByZWNlaXZlZCBhbiBhbnN3 ZXIiLiBXaHkgaXMgdGhlIHB1cnBvc2Ugb2YgdGhpcyBzdGF0ZW1lbnQ/DQoNCg0KNy4gU2VjdGlv biA0LjIuIFNlc3Npb24gRGVzY3JpcHRpb25zIGFuZCBTdGF0ZSBNYWNoaW5lIHN0YXRlczoNCg0K IkluIFtSRkMzMjY0XSwgdGhlIGNvbnN0cmFpbnRzIGF0IHRoZSBzaWduYWxpbmcgbGV2ZWwgaXMg dGhhdCBvbmx5IG9uZSBvZmZlciBjYW4gYmUgb3V0c3RhbmRpbmcgZm9yIGEgZ2l2ZW4gc2Vzc2lv biBidXQgZnJvbSB0aGUgbWVkaWEgc3RhY2sgbGV2ZWwsIGEgbmV3IG9mZmVyIGNhbiBiZSBnZW5l cmF0ZWQgYXQgYW55IHBvaW50LiAgRm9yIGV4YW1wbGUsIHdoZW4gdXNpbmcgU0lQIGZvciBzaWdu YWxpbmcsIGlmIG9uZSBvZmZlciBpcyBzZW50LCB0aGVuIGNhbmNlbGxlZCB1c2luZyBhICBTSVAg Q0FOQ0VMLCBhbm90aGVyIG9mZmVyIGNhbiBiZSBnZW5lcmF0ZWQgZXZlbiB0aG91Z2ggbm8gYW5z d2VyIHdhcyAgcmVjZWl2ZWQgZm9yIHRoZSBmaXJzdCBvZmZlci4gVG8gc3VwcG9ydCB0aGlzLCB0 aGUgSlNFUCBtZWRpYSBsYXllciAgY2FuIHByb3ZpZGUgYW4gb2ZmZXIgd2hlbmV2ZXIgdGhlIEph dmFzY3JpcHQgYXBwbGljYXRpb24gbmVlZHMgb25lIGZvciB0aGUgc2lnbmFsaW5nLiIgICANCg0K UmVnYXJkaW5nIHRoZSBleGFtcGxlIFNJUCBzZXF1ZW5jZSBpbiB0aGlzIHNjZW5hcmlvIGlmIHRo ZSBDQU5DRUwgaXMgdXNlZCB0byB0ZXJtaW5hdGUgYSBTSVAgZGlhbG9nIGluaXRpYXRpbmcgSU5W SVRFIEkgd291bGQgYXNzdW1lIHRoYXQgbm9ybWFsbHkgdGhlIHBlZXIgY29ubmVjdGlvbiB3b3Vs ZCBiZSB0ZXJtaW5hdGVkIGFuZCBhIG5ldyBwZWVyIGNvbm5lY3Rpb24gdXNlZCBmb3IgYW55IHN1 YnNlcXVlbnQgY2FsbCBzbyBpdCBkb2VzIG5vdCBzZWVtIHRvIGJlIGEgZ29vZCBleGFtcGxlLiBJ ZiB0aGUgZXhhbXBsZSBpcyBtZWFudCB0byBpbmRpY2F0ZSB0aGF0IHN1Y2ggYSBzZXF1ZW5jZSBj b3VsZCBiZSB1c2VkIHdoaWxzdCBlc3RhYmxpc2hpbmcgYSBTSVAgZGlhbG9nIGl0IGlzIGEgcmVh bGx5IGhvcnJpYmxlIGV4YW1wbGUuIElmIGl0IGlzIGludGVuZGVkIHRvIGJlIGFuIGV4YW1wbGUg bWlkIGRpYWxvZyB0aGVuIHRoZSBvZmZlciBuZWVkcyB0byBiZSBjYW5jZWxsZWQgYW5kIHRoZSBt ZWRpYSBzdGF0ZSByZXZlcnRlZCB0byB3aGF0IGl0IHdhcyBwcmV2aW91c2x5Lg0KDQoNCjguIFNl Y3Rpb24gNC4yLiBTZXNzaW9uIERlc2NyaXB0aW9ucyBhbmQgU3RhdGUgTWFjaGluZS4NCg0KSSB0 aGluayB0aGF0IHNvbWUgdGV4dCBpcyBuZWVkZWQgdG8gZGVzY3JpYmUgaG93IHRoZSB2ZXJzaW9u IG51bWJlciBpbiB0aGUgU0RQIG8gbGluZSBpcyBtYW5hZ2VkIGFuZCB3aGV0aGVyIHRoZSBhcHBs aWNhdGlvbiBoYXMgcmVzcG9uc2liaWxpdHkgZm9yIGNoYW5naW5nIHRoZSB2ZXJzaW9uIG51bWJl ciBpZiBpdCBjaGFuZ2VzIHRoZSBTRFAgYmV0d2VlbiBjcmVhdGVPZmZlciBhbmQgc2V0TG9jYWxE ZXNjcmlwdGlvbiBldGMuDQoNCg0KOS4gU2VjdGlvbiA0LjYuIFNlc3Npb24gUmVoeWRyYXRpb24g c3RhdGVzOg0KDQoiQXQgdGhpcyBwb2ludCBhIG5ldyBvZmZlciBjYW4gYmUgZ2VuZXJhdGVkIGJ5 IHRoZSBuZXcgUGVlckNvbm5lY3Rpb24sIHdpdGggbmV3IElDRSBhbmQgU0RFUyAgY3JlZGVudGlh bHMuIFRoaXMgY2FuIHRoZW4gYmUgdXNlZCB0byByZS1pbml0aWF0ZSB0aGUgc2Vzc2lvbiB3aXRo IHRoZSBleGlzdGluZyByZW1vdGUgZW5kcG9pbnQsIHdobyBzaW1wbHkgc2VlcyB0aGUgbmV3IG9m ZmVyIGFzIGFuIGluLWNhbGwgcmVuZWdvdGlhdGlvbi4uLiINCg0KV2hldGhlciB0aGlzIGlzIHBv c3NpYmxlIGRlcGVuZHMgb24gdGhlIHNpZ25hbGxpbmcgc3lzdGVtIHVzZWQgYW5kIHRoZSBvZmZl ci9hbnN3ZXIgc3RhdGUgZm9yIGV4YW1wbGUgaXQgbWlnaHQgbm90IGJlIHBvc3NpYmxlIHRvIHNl bmQgYW5vdGhlciBvZmZlciBpZiB0aGVyZSBpcyBhbHJlYWR5IGFuIG91dHN0YW5kaW5nIG9mZmVy IHdhaXRpbmcgZm9yIGFuIGFuc3dlciBzbyBtYXliZSB0aGUgc2Vzc2lvbiB3b3VsZCBoYXZlIHRv IGJlIHRlcm1pbmF0ZWQuIFRoaXMgc2VlbXMgdG8gc3VnZ2VzdCB0aGF0IEVrcidzIGlkZWEgdG8g c29tZWhvdyBtYWludGFpbiB0aGUgUGVlckNvbm5lY3Rpb24gaXMgbW9yZSBhdHRyYWN0aXZlLg0K DQoNCjEwLiBTZWN0aW9uIDUuMSBTRFAgUmVxdWlyZW1lbnRzLg0KDQpJIG1pc3MgYSBzdGF0ZW1l bnQgcmVsYXRlZCB0byB0aGUgZGF0YSBjaGFubmVsLiBNYW5kYXRvcnkvb3B0aW9uYWw/IFtkcmFm dC1pZXRmLXJ0Y3dlYi1kYXRhLWNoYW5uZWxdDQoNCkJ1bmRsaW5nIG9mIG1lZGlhIHN0cmVhbXMg aXMgYWxzbyBub3QgbWVudGlvbmVkIGhlcmUgKGJ1bmRsZS9tbXQgZHJhZnRzKSBvbmx5IGlzIG1l bnRpb25lZCBmdXJ0aGVyIGRvd24gaW4gc2VjdGlvbiA2LiANCg0KRFRMUy1TUlRQIChSRkM1NzYz LzY0KT8gSXQncyBtZW50aW9uZWQgdGhyb3VnaG91dCB0aGUgdGV4dCwgYnV0IG5vdCBzcGVsbGVk IG91dCBoZXJlLiBEVExTLVNSVFAgd291bGQgdXNlIGFzIHRyYW5zcG9ydCBpbiB0aGUgbS1saW5l IERUTFMvVURQL1JUUC9TQVZQKEYpIGFzIHNwZWNpZmllZCBpbiBSRkMgNTc2NC4NCg0KDQoxMS4g U2VjdGlvbiA1LjIuMSBDcmVhdGUgT2ZmZXIgc3RhdGVzOg0KDQoiSW4gdGhlIGV2ZW50IGNyZWF0 ZU9mZmVyIGlzIGNhbGxlZCBhZnRlciB0aGUgc2Vzc2lvbiBpcyBlc3RhYmxpc2hlZCwgY3JlYXRl T2ZmZXIgd2lsbCBnZW5lcmF0ZSBhbiBvZmZlciB0aGF0IGlzIGNvbXBhdGlibGUgd2l0aCB0aGUg Y3VycmVudCBzZXNzaW9uLCBpbmNvcnBvcmF0aW5nIGFueSBjaGFuZ2VzIHRoYXQgaGF2ZSBiZWVu IG1hZGUgdG8gdGhlIHNlc3Npb24gc2luY2UgdGhlIGxhc3QgY29tcGxldGUgb2ZmZXItYW5zd2Vy IGV4Y2hhbmdlLCBzdWNoIGFzIGFkZGl0aW9uIG9yIHJlbW92YWwgb2Ygc3RyZWFtcy4gIElmIG5v IGNoYW5nZXMgaGF2ZSBiZWVuIG1hZGUsIHRoZSBvZmZlciB3aWxsIGJlIGlkZW50aWNhbCB0byB0 aGUgY3VycmVudCBsb2NhbCBkZXNjcmlwdGlvbiIuDQoNCldoYXQgaXMgbWVhbnQgYnkgImNvbXBh dGlibGUgd2l0aCB0aGUgY3VycmVudCBzZXNzaW9uIiBpbiB0aGVzZSBzZW50ZW5jZT8gIElmIGZv ciBleGFtcGxlIHRoZSBvZmZlciBpbmNsdWRlZCBHLjcxMSBhbmQgT1BVUyBhdWRpbyBjb2RlY3Mg YnV0IHRoZSBhbnN3ZXIgaGFkIG9ubHkgRy43MTEgZG9lcyB0aGlzIG1lYW4gdGhhdCBhbnkgc3Vi c2VxdWVudCBvZmZlciBvbmx5IGhhcyBHLjcxMSBpZiBzbyB0aGlzIEkgdGhpbmsgaXMgdGhlIHdy b25nIGFwcHJvYWNoIGFzIHRoZSBuZXcgb2ZmZXIgc2hvdWxkIHByb3ZpZGUgYWxsIHRoZSBjYXBh YmlsaXRpZXMuICBBbHNvIEkgYXNzdW1lIHRoYXQgYSBuZXcgc2V0IG9mIGNvbnN0cmFpbnRzIGNv dWxkIGJlIHVzZWQgb24gdGhlIGNyZWF0ZU9mZmVyIGZvciBleGFtcGxlIHRvIGNoYW5nZSB0aGUg bWVkaWEgZGlyZWN0aW9uIGV0Yy4NCg0KDQoxMi4gU2VjdGlvbiA1LjIuMSBDcmVhdGUgT2ZmZXIg c3RhdGVzOg0KDQoiQ2FsbGluZyB0aGlzIG1ldGhvZCBtYXkgZG8gdGhpbmdzIHN1Y2ggYXMgZ2Vu ZXJhdGUgbmV3IElDRSBjcmVkZW50aWFscywgYnV0IGRvZXMgbm90IGNoYW5nZSBtZWRpYSBzdGF0 ZS4iDQoNClNvIGFtIEkgY29ycmVjdCBpbiB0aGlua2luZyB0aGF0IHRoaXMgbWV0aG9kIE1VU1Qg YmUgY2FsbGVkLiBJZiBzbyBnaXZlbiB0aGUgc3RhdGVtZW50IGluIHByZXZpb3VzIGRyYWZ0cyB0 aGF0IGl0IGRvZXMgbm90IGhhdmUgdG8gYmUgdXNlZCBpdCB3b3VsZCBiZSBnb29kIHRvIG1ha2Ug YW4gZXhwbGljaXQgc3RhdGVtZW50IHRoYXQgaXQgbXVzdCBiZSB1c2VkLg0KDQoNCjEzLiBTZWN0 aW9uIDUuMi4yIGNyZWF0ZUFuc3dlci4gDQoNClByZXN1bWFibHkgY29uc3RyYWludHMgY2FuIGFs c28gYmUgc2V0IG9uIHRoZSBhbnN3ZXIgaW4gd2hpY2ggY2FzZSB0aGlzIHNob3VsZCBiZSBzdGF0 ZWQgbGlrZSBpbiB0aGUgY3JlYXRlT2ZmZXIgc2VjdGlvbi4NCg0KMTQuIFNlY3Rpb24gNS4yLjMg U2Vzc2lvbkRlc2NyaXB0aW9uVHlwZQ0KDQoiInByYW5zd2VyIiBpbmRpY2F0ZXMgdGhhdCBhIGRl c2NyaXB0aW9uIHNob3VsZCBiZSBwYXJzZWQgYXMgYW4gYW5zd2VyLCBidXQgbm90IGEgZmluYWwg YW5zd2VyLCBhbmQgc28gc2hvdWxkIG5vdCByZXN1bHQgaW4gdGhlIGZyZWVpbmcgb2YgYWxsb2Nh dGVkIHJlc291cmNlcy4gIEl0IG1heSByZXN1bHQgaW4gdGhlIHN0YXJ0IG9mIG1lZGlhICAgdHJh bnNtaXNzaW9uLCBpZiB0aGUgYW5zd2VyIGRvZXMgbm90IHNwZWNpZnkgYW4gaW5hY3RpdmUgbWVk aWEgZGlyZWN0aW9uIi4NCg0KUGxlYXNlIG5vdGUgdGhhdCAiaW5hY3RpdmUiIHN0aWxsIHJlc3Vs dHMgaW4gdGhlIGluaXRpYXRpbmcgdGhlIFJUUCBTZXNzaW9uIGFuZCB0aGUgdHJhbnNtaXNzaW9u IG9mIFJUQ1Agc28gaWYgeW91IGluY2x1ZGUgUlRDUCBhcyBtZWRpYSB0aGlzIHN0YXRlbWVudCBp cyBub3Qgc3RyaWN0bHkgY29ycmVjdC4NCg0KDQoxNS4gU2VjdGlvbiA1LjIuMy4xIGNyZWF0aW5n IEFuc3dlcnMgc3RhdGVzOg0KDQoiV2hlbiBhbiBlbmRwb2ludCByZWNlaXZlcyBhbiBvZmZlciB3 aXRoIHRoZXNlIGNoYW5uZWxzLCBpdCBjb3VsZCBzZW5kIGFuIGFuc3dlciBhY2NlcHRpbmcgdGhl IGRhdGEgY2hhbm5lbCBmb3IgdHdvLXdheSBkYXRhLCBhbmQgYWNjZXB0aW5nIHRoZSBhdWRpbyBh bmQgdmlkZW8gdHJhY2tzIGFzIHJlY2VpdmUtb25seSIuDQoNCldoZXRoZXIg4oCccmVjZWl2ZS1v bmx54oCdIGNhbiBiZSB1c2VkIGRlcGVuZHMgb24gdGhlIGRpcmVjdGlvbiBpbiB0aGUgaW5jb21p bmcgb2ZmZXIgYW5kIGl0IHNob3VsZCBiZSBub3RlZCB0aGF0IHNlbmRpbmcgYW4gYW5zd2VyIHdp dGggcmVjZWl2ZS1vbmx5IGNvbW1pdHMgdGhlIGxvY2FsIGJyb3dzZXIgdG8gc2VuZGluZyBSVENQ IHNvIEkgYW0gbm90IHN1cmUgdGhpcyByZWFsbHkgd29ya3MgYmVjYXVzZSB0aGUgYW5zd2VyIHdp dGggcmVjZWl2ZS1vbmx5IHN0aWxsIG5lZWRzIHRvIGNvbnRhaW4gYSB2YWxpZCB0cmFuc3BvcnQg YWRkcmVzcy4NCg0KDQoxNi4gU2VjdGlvbiA1LjIuNCBzZXRMb2NhbERlc2NyaXB0aW9uIHN0YXRl czoNCg0KIklmIHNldFJlbW90ZURlc2NyaXB0aW9uIHdhcyBwcmV2aW91cyBjYWxsZWQgd2l0aCBh biBvZmZlciwgYW5kIHNldExvY2FsRGVzY3JpcHRpb24gaXMgY2FsbGVkIHdpdGggYW4gYW5zd2Vy IChwcm92aXNpb25hbCBvciBmaW5hbCksIGFuZCB0aGUgbWVkaWEgZGlyZWN0aW9ucyBhcmUgY29t cGF0aWJsZSB0aGlzIHdpbGwgcmVzdWx0IGluIHRoZSBzdGFydGluZyBvZiBtZWRpYSB0cmFuc21p c3Npb24uIg0KDQpJIGFzc3VtZSBieSBjb21wYXRpYmxlIHRoYXQgaXQgaXMgbWVhbnQgdGhhdCB0 aGUgYnJvd3NlciB3aWxsIGVuZm9yY2UgdGhlIFJGQyAzMjY0IHJ1bGVzIGZvciBzZXR0aW5nIHRo ZSBkaXJlY3Rpb24gaW4gYW4gYW5zd2VyLiBJZiBzbyBwbGVhc2UgbWFrZSB0aGlzIGV4cGxpY2l0 IGlmIG5vdCB3aGF0IGlzIG1lYW50IGJ5IOKAnGNvbXBhdGlibGXigJ0/DQoNCg0KMTcuIFNlY3Rp b24gNS4yLjUgc2V0UmVtb3RlRGVzY3JpcHRpb24gLSBTYW1lIGNvbW1lbnQgYXMgYWJvdmUuDQoN Cg0KUmVnYXJkcw0KQW5keQ0KDQoNCg0KDQo= From trac+rtcweb@trac.tools.ietf.org Wed Oct 31 15:47:49 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D0221F8606 for ; Wed, 31 Oct 2012 15:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmcFCB-rmrMJ for ; Wed, 31 Oct 2012 15:47:48 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id E36D221F85ED for ; Wed, 31 Oct 2012 15:47:44 -0700 (PDT) Received: from localhost ([127.0.0.1]:36617 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTh4T-0007vE-FP; Wed, 31 Oct 2012 23:47:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "rtcweb issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-rtcweb-jsep@datatracker.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: rtcweb Date: Wed, 31 Oct 2012 22:47:37 -0000 X-URL: http://tools.ietf.org/rtcweb/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/3 Message-ID: <066.b5060d6f1c778a37ddaaeadfa120da84@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-jsep@datatracker.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: fluffy@iii.ca, justin@uberti.name Resent-Message-Id: <20121031224747.E36D221F85ED@ietfa.amsl.com> Resent-Date: Wed, 31 Oct 2012 15:47:44 -0700 (PDT) Resent-From: trac+rtcweb@trac.tools.ietf.org Cc: rtcweb@ietf.org Subject: [rtcweb] #3: JSEP-02 Review (from Andy Hutton) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 22:47:49 -0000 #3: JSEP-02 Review (from Andy Hutton) I have read through the latest jsep-02 draft and have the following comments/questions. 1. Section 1 Introduction The introduction makes various references to offer/answer but does not mention RFC 3264. It needs such a reference and to explain the relevance of RFC 3264 and how JSEP provides the tools to implement a RFC 3264 conformant application but does not itself implement RFC 3264. 2. Section 1 Introduction 2nd Para states: "The browser environment also has its own challenges that cause problems for an embedded signaling state machine. One of these is that the user may reload the web page at any time. If this happens, and the state machine is being run at a server, the server can simply push the current state back down to the page and resume the call where it left off". The last sentence is an over simplification as there are problems with regard to rehydration even when the signaling state machine is run at the server. Also the sentence refers to two different types of state as it is not the signaling state that is pushed back to the browser. I suggest removing the last sentence or referring to the section on hydration. 3. Section 1. Introduction 7th Para states: "The JSEP approach does come with a minor downside. As the application now is responsible for driving the signaling state machine, slightly more application code is necessary to perform call setup; the application must call the right APIs at the right times, and convert the session descriptions and ICE information into the defined messages of its chosen signaling protocol, instead of simply forwarding the messages emitted from the browser." Yes but maybe the introduction should explain that the API will provide valid SDP that an application could use within a RFC 3264 based protocol without the application needing to understand the syntax of SDP. 4. Section 1. Intoduction 8th Para states: "For example, this library could convert easily adapt the JSEP API..." Remove "convert". 5. Section 4.1. Signaling model 1st Para states: "JSEP does not specify a particular signaling model or state machine, other than the generic need to exchange RFC 3264 offers and answers in order for both sides of the session to know how to conduct the session". I think this needs rewording and suggest the following “JSEP does not specify a particular signaling model or signalling state machine. JSEP provides the means for an application to build a signaling state machine which complies with the requirements for offer/answers as specified in RFC 3264". This emphasises that JSEP is required to provide the tools to enable conformance to 3264 even if it allows some flexibility to diverge from 3264. 6. Section 4.2. Session Descriptions and State Machine states: "Lastly, while the exact media parameters are only known only after a offer and an answer have been exchanged, it is possible for the offerer to receive media after they have sent an offer and before they have received an answer. To properly process incoming media in this case, the offerer's media handler must be aware of the details of the offerer before the answer arrives." I don't see the relevance of the statement "it is possible for the offerer to receive media after they have sent an offer and before they have received an answer". Why is the purpose of this statement? 7. Section 4.2. Session Descriptions and State Machine states: "In [RFC3264], the constraints at the signaling level is that only one offer can be outstanding for a given session but from the media stack level, a new offer can be generated at any point. For example, when using SIP for signaling, if one offer is sent, then cancelled using a SIP CANCEL, another offer can be generated even though no answer was received for the first offer. To support this, the JSEP media layer can provide an offer whenever the Javascript application needs one for the signaling." Regarding the example SIP sequence in this scenario if the CANCEL is used to terminate a SIP dialog initiating INVITE I would assume that normally the peer connection would be terminated and a new peer connection used for any subsequent call so it does not seem to be a good example. If the example is meant to indicate that such a sequence could be used whilst establishing a SIP dialog it is a really horrible example. If it is intended to be an example mid dialog then the offer needs to be cancelled and the media state reverted to what it was previously. 8. Section 4.2. Session Descriptions and State Machine. I think that some text is needed to describe how the version number in the SDP o line is managed and whether the application has responsibility for changing the version number if it changes the SDP between createOffer and setLocalDescription etc. 9. Section 4.6. Session Rehydration states: "At this point a new offer can be generated by the new PeerConnection, with new ICE and SDES credentials. This can then be used to re-initiate the session with the existing remote endpoint, who simply sees the new offer as an in-call renegotiation..." Whether this is possible depends on the signalling system used and the offer/answer state for example it might not be possible to send another offer if there is already an outstanding offer waiting for an answer so maybe the session would have to be terminated. This seems to suggest that Ekr's idea to somehow maintain the PeerConnection is more attractive. 10. Section 5.1 SDP Requirements. I miss a statement related to the data channel. Mandatory/optional? [draft-ietf-rtcweb-data-channel] Bundling of media streams is also not mentioned here (bundle/mmt drafts) only is mentioned further down in section 6. DTLS-SRTP (RFC5763/64)? It's mentioned throughout the text, but not spelled out here. DTLS-SRTP would use as transport in the m-line DTLS/UDP/RTP/SAVP(F) as specified in RFC 5764. 11. Section 5.2.1 Create Offer states: "In the event createOffer is called after the session is established, createOffer will generate an offer that is compatible with the current session, incorporating any changes that have been made to the session since the last complete offer-answer exchange, such as addition or removal of streams. If no changes have been made, the offer will be identical to the current local description". What is meant by "compatible with the current session" in these sentence? If for example the offer included G.711 and OPUS audio codecs but the answer had only G.711 does this mean that any subsequent offer only has G.711 if so this I think is the wrong approach as the new offer should provide all the capabilities. Also I assume that a new set of constraints could be used on the createOffer for example to change the media direction etc. 12. Section 5.2.1 Create Offer states: "Calling this method may do things such as generate new ICE credentials, but does not change media state." So am I correct in thinking that this method MUST be called. If so given the statement in previous drafts that it does not have to be used it would be good to make an explicit statement that it must be used. 13. Section 5.2.2 createAnswer. Presumably constraints can also be set on the answer in which case this should be stated like in the createOffer section. 14. Section 5.2.3 SessionDescriptionType ""pranswer" indicates that a description should be parsed as an answer, but not a final answer, and so should not result in the freeing of allocated resources. It may result in the start of media transmission, if the answer does not specify an inactive media direction". Please note that "inactive" still results in the initiating the RTP Session and the transmission of RTCP so if you include RTCP as media this statement is not strictly correct. 15. Section 5.2.3.1 creating Answers states: "When an endpoint receives an offer with these channels, it could send an answer accepting the data channel for two-way data, and accepting the audio and video tracks as receive-only". Whether “receive-only” can be used depends on the direction in the incoming offer and it should be noted that sending an answer with receive- only commits the local browser to sending RTCP so I am not sure this really works because the answer with receive-only still needs to contain a valid transport address. 16. Section 5.2.4 setLocalDescription states: "If setRemoteDescription was previous called with an offer, and setLocalDescription is called with an answer (provisional or final), and the media directions are compatible this will result in the starting of media transmission." I assume by compatible that it is meant that the browser will enforce the RFC 3264 rules for setting the direction in an answer. If so please make this explicit if not what is meant by “compatible”? 17. Section 5.2.5 setRemoteDescription - Same comment as above. Regards Andy -- --------------------------------+-------------------------------------- Reporter: bernard_aboba@… | Owner: draft-ietf-rtcweb-jsep@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: jsep | Version: 1.0 Severity: Active WG Document | Keywords: --------------------------------+-------------------------------------- Ticket URL: rtcweb From pkyzivat@alum.mit.edu Wed Oct 31 18:58:35 2012 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF69721F8728 for ; Wed, 31 Oct 2012 18:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nw3A+LneyiVl for ; Wed, 31 Oct 2012 18:58:34 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id A695621F871D for ; Wed, 31 Oct 2012 18:58:34 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta03.westchester.pa.mail.comcast.net with comcast id HmWo1k00J0mv7h0531ye23; Thu, 01 Nov 2012 01:58:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id J1yK1k00A3ZTu2S3X1yKsD; Thu, 01 Nov 2012 01:58:19 +0000 Message-ID: <5091D747.4040301@alum.mit.edu> Date: Wed, 31 Oct 2012 21:58:31 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 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 Subject: Re: [rtcweb] Form of the video codec question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Nov 2012 01:58:35 -0000 On 10/29/12 2:51 PM, Stephan Wenger wrote: > Hi Ted, chairs, > > I think these are the wrong questions, as the result of such a poll is not > going to solve anything. It's trivial to predict that there will be a > significant show of hands in favor of each question. What does that tell > you? Asking the questions as presented is going to be a waste of time. > > The more informative questions to as would be: > > 1) Do you object to H.264 as MTI, regardless of its technical and IPR > merits (if any); and > 2) Do you object to VP8 as MTI, regardless of its technical and IPR merits > (if any) > (both in more politically correct formulation, if you want.) > > If you chairs know that there are objections to both codecs by a > significant number of people that cannot be swayed by technical or IPR > arguments, a presentation of such technical and IPR merits can be omitted, > and the WG can focus on stuff where progress is likely. Stephan, Maybe I am dense, but what arguments remain after you remove "technical" and "IPR"? Presumably what is left is "business". But don't business considerations in this case devolve to either technical or IPR ones? (E.g. "I favor X because I have a license for it and some potential competitors do not" is ultimately an IPR question.) Thanks, Paul > Regards, > Stephan > > > On 10.29.2012 11:08 , "Ted Hardie" wrote: > >> We got feedback after the audio codec discussion that folks would have >> benefited from seeing the question we intended to ask before the >> meeting. In order to clarify that for this discussion, the chairs are >> putting forward this draft of the question which will be asked in the >> meeting (and then confirmed on the list). >> >> "1) If you support H.264 as the mandatory to implement codec or are >> willing to live with it as the MTI, please raise your hand now. >> >> 2) If you support VP8 as the mandatory to implement codec or are >> willing to live with it as the MTI, please raise your hand now. >> >> You may raise your hand more than once and we encourage you to do so >> if you can live with either, even if you have a preference for one >> over the other." >> >> Because all 3 chairs and our responsible AD could be perceived to have >> conflicts of interest here, we have asked Robert Sparks to judge the >> consensus of the room, and he has kindly agreed. If you have major >> heartburn about the form of the question, please let us know. >> >> regards, >> >> Ted Hardie, Cullen Jennings, Magnus Westerlund >> _______________________________________________ >> 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 >